[Olsr-users] [Olsr-dev] Broadcast Packets & Windows Routin

[Hannes Gredler]

On Mon, Feb 25, 2008 at 08:02:19AM +0100, Henning Rogge wrote:
| Am Samstag 23 Februar 2008 17:31:35 schrieb Hannes Gredler:
| > actually we do ... b/c the timer buckets in the new timer code
| > are not kept sorted ... so we really need to walk the timer slot
| > every scheduling interval b/c we do not know what is in the slot
| > and if a timer is about to fire.
| Could this become a problem because the timers are not fired in order (later 
| timers could be handled before earlier timers) ?
| > i have made some experiments with sorted timer trees and given
| > the frequent changes (read tc_edge updates) sorting timers did
| > cost a lot of performance.
| That would be bad, that's right.
| 
| > perhaps if we can invest some time in a rewrite that leads to lower
| > consumption of timers (today we have roughly 2000 timers
| > facing a network of 400 nodes), (and roughly 1200 are not really required
| > :-/)
| Sounds like a good idea.
| 
| > after that rewrite we might pick up the idea of keeping the timer list
| > sorted and passing the timestamp of the first timer to select().
| Maybe instead of a single timer tree we could keep a tree for each of your 
| buckets (1 second interval). This way the number of timestamps to be sorted 
| are lower than before.
| 
| > > 2.) olsrd can react to incoming network traffic at once, instead of
| > > waiting for x milliseconds, this might be useful for plugins
| >
| > just for I/O purposes that makes a lot of sense to me now.
| And maybe we prevent race conditions when some timers are fired in the wrong 
| order... don't know if it's possible at the moment, but if we don't do so we 
| have to document this behaviour somewhere...

it is possible and i think it does not matter to much as every client code
applies some degree of random jitter, so out of order firing does not do
much harm. - i'll add a note in the code that a strict temporal order is
not maintained ...

/hannes