[Olsr-dev] Bug in timing out stale TC entries
Erik Tromp
(spam-protected)
Sun Feb 24 17:03:17 CET 2008
> removing edge entries from the lsdb is not mandatory as long
> as we "do the right thing", which is to ignore this link
> during SPF computation.
OK.
> it would be interesting to see if the offending edges (or the inverse
> edges) are marked down using the OLSR_TC_EDGE_DOWN flag.
> (pls add some instrumentation code to verify).
OK.
By the way, according to the next constant I would expect the edges
to dissapear within 15 seconds:
/*
* Garbage collection time for downed edges
*/
#define OLSR_TC_EDGE_GC_TIME (15*1000) /* milliseconds */
> the reason we are just marking the edge as down and not
> immediately removing it is b/c of the TC fragmentation bug
> where a TC message spans across 2 packets. (if we would
> eliminate all TC edges immediately then you get a whole lot
> of malloc() churn.
> b/c a couple of ms later the next packet is being processed
> and then the tc_edge is reinserted again.
Sounds sensible.
If an edge is marked 'down' in some way or another, it would
be nice to see that in the debug info.
I guess I'll have to make an update in the bmf code now...
Erik
More information about the Olsr-dev
mailing list