[Olsr-dev] Bug in function olsr_tc_update_edge ?

[Erik Tromp]

> 
> 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?