[olsr-dev] Re: [OLSR-users] Differing metrics for route decision

[Thomas Lopatic]

Hey Sven-Ola,

> Alone the dijstra algo is the most expensive part now -> will be very
> hairy to optimize that. Hence a question: Is it possible to slow down
> the "dijstra-rate"? E.g. a 10 seconds Net-Info-Collection phase followd
> by a single dijkstra calculation...? Or do OLSRd need to work on any
> single change here?

Ha! I've been hoping for a long time that somebody would finally ask
this question on the mailing list, as this gives me the chance to show
off our "LinkQualityDijkstraLimit" configuration directive. :-) It's
basically fish-eye in reverse. Let's look at an example.

  LinkQualityDijkstraLimit 5 10

olsrd will then collect TC information and update its internal data
structures just like before, but only TCs from nodes less than 5 hops
away will actually trigger a Dijkstra run.

In addition to the Dijkstra runs triggered by incoming TCs from nodes
less than 5 hops away, every 10 seconds an additional Dijkstra run will
be triggered. Just in case there haven't been any Dijkstra runs for 10
seconds.

So, to achieve the desired behaviour, simply say

  LinkQualityDijkstraLimit 0 10

This will switch off Dijkstra runs triggered by TC messages and only run
Dijkstra every 10 seconds.

Be aware, however, that this could lead to routing loops in a network
that frequently changes its topology.

-Thomas