[Olsr-dev] Bug in function olsr_tc_update_edge ?
Tue Feb 19 17:01:20 CET 2008
> let me propose the following:
> 1. remove the "significant" change check at the receiver side
We will need some kind of criterion to determine if a node needs to do SPF.
If nothing changes at all in the TC database, it is pointless to do SPF. We
must all help in saving on CO2 :-)
> 2. mitigate SPF runtime going through the roof
> by adding a 1000ms inter-SPF backoff timer.
That seems a good idea. If 400 nodes are 'spamming' their TC data every 5
seconds, we don't want to end up doing SPF 80 times/second. It would be a
good strategy to save and record the TC data for a fixed amount of time,
then recalculate the routes. The interval may even be configurable so that
it can be set to a longer value for low-power / small-CPU nodes. I think
that a route update within a second is quite fast; it could be done as slow
as once every 10 seconds, about the same order of time needed to achieve a
link quality measurement.
> 3. get CSN into the field
Could you give some background into this 'periodic resync of the TC DB using
a protocol extension called "CSN" '?
> 4. move the "siginificant" change check to the sender before
> pesting the world with our TC updates.
Isn't there a fixed rate (TcInterval) at which a node sends its TC updates
into the world? Or does OLSRd have some mechanism that is used by a node to
immediately tell the world of any changes in the TC database?
More information about the Olsr-dev