[olsr-dev] Re: [OLSR-users] Differing metrics for route decision

Sven-Ola Tuecke (spam-protected)
Mon Feb 27 13:52:52 CET 2006

Hey :)

besides that muscial comparative, there *is* a change (the peak in the 

One more note: Because of the CPU load, I optimized some aspects using gprof 
(mainly to held that damn slow old WRTs in service). Biggest winner: the 
optimized duplicate_set.c. With a hash size of only 32 and most of the WRTs 
in the berlin mesh using an address of (IP & 0x1f == 1) it consumes too 
much. Changed to 128 hash size and a hashkey of ip0^ip1^ip2^ip3 - this calc 
is less expensive then ntohl() I think.

Alone the dijstra algo is the most expensive part now -> will be very hairy 
to optimize that. Hence a question: Is it possible to slow down the 
"dijstra-rate"? E.g. a 10 seconds Net-Info-Collection phase followd by a 
single dijkstra calculation...? Or do OLSRd need to work on any single 
change here?

LG Sven-Ola

Ah - forget the reference for the optimized stuff. It's here:

"Aaron Kaplan" <(spam-protected)> schrieb im Newsbeitrag 
> >
>> While I'am at it: Have a little patch for that ETX calculation  which 
>> seems to run well. Only meaningful when you use Windowsize >  HelloInt * 
>> HalloVal as with Freifunk/Berlin Mesh: WinSize is 100,  Hello is 5 sek, 
>> HelloVal is 90 sek. Patch is located here:
>> http://olsrexperiment.de/sven-ola/nylon/olsrd-bb-files-for-nylon/ 
>> files/olsrd-fixes.patch
>> (Ah - that will also change the Fish-Table. Changed table is  prepared 
>> for the forced fish since no ttl=0xff is used any more.  Makes it 
>> possible to put TTL=0xff into /dev/null one day. For the 
>> IPv6-Size-Change I'am not too sure...)
> Hi
> I looked at the patch. Well , it looks like you changed the ttl_list 
> (fisheye table) from walzer to 2^n rythm :)
> a.
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev 

More information about the Olsr-dev mailing list