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

[Sven-Ola Tuecke]

Should not sent too fast. Did not mention *why* duplicate_set.c is the gprof 
winner: We have a pile of stuff, up to 2700 messages in that filter 
(sometimes, average ~ 1500). That's messages - not packets and a lot of 
filtering work until the 2seconds-cleansweeper get rid of them...

LG Sven-Ola

""Sven-Ola Tuecke"" <(spam-protected)> schrieb im Newsbeitrag 
news:dtusn4$j5c$(spam-protected)
> Hey :)
>
> besides that muscial comparative, there *is* a change (the peak in the 
> middle).
>
> 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