[Olsr-dev] Bug in function olsr_tc_update_edge ?

Hannes Gredler (spam-protected)
Tue Feb 19 10:06:54 CET 2008

correct, periodical SPF is a sort of escape door -
worst case in the meantime we have a 10sec loop.


Sven-Ola Tücke wrote:
> Morning,
> the right time to ask. The majority of nodes uses 
> the "LinkQualityDijkstraLimit 0 10.0" setting. Wich means: start a new route 
> calculation every 10 seconds and ignore any "change now flags". Hence my 
> question: the behaviour of olsr_etx_significant_change() described by eric is 
> overruled by this 10-seconds "garbage collection"?
> // Sven-Ola
> Am Montag 18 Februar 2008 23:39:08 schrieb Hannes Gredler:
>> hi eric,
>> your observation is correct, now asking what is the right fix ?
>> we are getting in the waters of system design here.
>> the more interesting question to ask is why does a node
>> emit a less than 10 percent change and flood the TC throughout
>> the network in spite that everyone will not trigger a SPF
>> calculation ?
>> IMO the right thing to do, sender should hold-back the information
>> locally and once the change is significant enough, flood it
>> throughout the network.
>> /hannes

More information about the Olsr-dev mailing list