[olsr-dev] olsrd profiling session

Andreas Tønnesen (spam-protected)
Mon Feb 28 10:51:10 CET 2005


Hi Sven-Ola,

Both the route add and delete functions totally depends on receiving sane
input data. In reallity the behaviour you saw "should not happen"[tm], but
I agree that an assertion here at least makes life easier for debugging
when stuff like this happens. There are probably other cases like this in
the code tough... but then again - garbage in, garbage out :)

- Andreas

> Hi Andreas,
>
> OLSR_PRINTF works fine. Many thanks. May I suggest to change the
> if(last_run) for stability? Its better to do a hard exit(1) here if
> last_run
> and different metic values are too illegal here. Better than hanging in an
> endless loop anyway.
>
> Heres my change (adapt manually):
>
> +++ olsrd-cvs-0.4.9/src/process_routes.c 2005-02-28 01:09:09.000000000
> +0100
>        for(destination_ptr = delete_kernel_list; destination_ptr != NULL;
> )
>   {
>
> +#ifdef SVEN_OLA
> +   if(last_run || (destination_ptr->destination->rt_metric ==
> metric_counter) &&
> +      ((
> +#else
>     if((destination_ptr->destination->rt_metric == metric_counter) &&
>        ((last_run ||
> +#endif
>          !COMP_IP(&destination_ptr->destination->rt_dst,
>                          &destination_ptr->destination->rt_router))))
>       {
>
> Regards,
> Sven-Ola
>
> ""Andreas Tønnesen"" <(spam-protected)> schrieb im Newsbeitrag
> news:(spam-protected)
>>
>> All files have now been converted to using OLSR_PRINTF. And one can
>> compile setting NODEBUG=1 (make NODEBUG=1) to not even include the
>> if statements in the debug output in the code.
>>
>> (as usual the CVS mirrors need a couple of hours to update)
>>
>> - Andreas
>>
>> Andreas Tønnesen wrote:
>>> Sven-Ola,
>>>
>>>> the profiling version was compiled without -DDEBUG. So I belive it's
>>>> the
>>>> olsr_printf("results %s", cpu_intensive_func_returns_string()) which
>>>> eats up
>>>> CPU time even of not -DDEBUG. So I suggest a change to:
>>>>
>>>> if(0<debuglev) {
>>>>   olsr_printf("results %s", cpu_intensive_func_returns_string());
>>>> }
>>>>
>>>
>>> I chacked in code using a macro OLSR_PRINTF last night. I have not
>>> updated all files yet but they will soon be all converted to using the
>>> macro. It is also possible to set NODEBUG causing the MACRO not to
>>> expand
>>> to anything. It would be interesting to se the overall effect of this
>>> on
>>> the WRT later on.
>>>
>>> - Andreas
>>>
>>
>> --
>> Andreas Tønnesen
>> http://www.olsr.org
>> _______________________________________________
>> olsr-dev mailing list
>> (spam-protected)
>> https://www.olsr.org/mailman/listinfo/olsr-dev
>
>
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
>


---------
Andreas Tønnesen
http://www.olsr.org



More information about the Olsr-dev mailing list