[Olsr-dev] Little change to olsr core

[Henning Rogge]

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.

Henning

On Fri, Jul 27, 2012 at 10:17 AM, ZioPRoTo (Saverio Proto)
<(spam-protected)> wrote:
>> @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
> LINK_COST_BROKEN
>
> Saverio



-- 
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."