[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.
/hannes
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