[Olsr-dev] Little change to olsr core
Fri Jul 27 11:28:54 CEST 2012
The current core doesn't support asymmetric links. I am not even sure
the Dijkstra implementation can handle it.
Setting your local ETX to "a" but having your neighbor announcing an
ETX of "b" sounds like a lot of trouble. We should not implement
something like this before checking the Dijkstra very carefully.
Whats about this, instead of implementing a static LQ/ETX, we could
allow a user to define a maximum LQ for a link (between 0 and 1).
Calculation will be running as normal, just that it doesn't go higher
than a certain value.
On Fri, Jul 27, 2012 at 10:17 AM, ZioPRoTo (Saverio Proto)
>> @Saverio: why is the LQ multiplier not enough?
> 1) First problem is that I cannot configure asymetric cost:
> in the current implementation the ETX of the link is the same in both
> directions (you can have a little shift because cost from A to B is
> computed on A and cost from B to A is computed on B, but results
> should be the same).
> 2) Second problem is granular costs
> the ETX using multipliers will be
> ETX = 1 / ( LQa * multA * LQb * multB)
> when the link is perfect I can simplify in
> ETX = 1 / (multA * multB)
> But the is very tricky to configure ETX of 18,19,20,21,22,23 adjusting
> these two multipliers values on the two routers.
> Moreover a packet loss on the link will add a multiplicating factor to
> my link, that most of the time will go quickly above LINK_COST_BROKEN
> I would like to set ETX = 18, and then just delete the link if the
> normal computation of ETX without multiplier goes above
Steven Hawkings about cosmic inflation: "An increase of billions of
billions of percent in a tiny fraction of a second. Of course, that
was before the present government."
More information about the Olsr-dev