[Olsr-dev] LinkQualityMult support for olsrd development branch
David Murray
(spam-protected)
Thu Apr 24 09:45:39 CEST 2008
Quoting Henning Rogge <(spam-protected)>:
>> I am still noticing that the rewrite of the ETX metric is giving
>> different/higher costs. Do you know why this might be occurring? I
>> would have thought that they should give the same cost if they are both
>> based on [1].
> No, the new ETX metric is using a moving exponential average to calculate the
> ETX value. (ETX = 1 / LinkQuality)
>
> alpha = aging factor (default 0.1)
>
> for every received Hello:
> New LQ = Old LQ * (1-alpha) + alpha
> for every lost Hello (timer based):
> New LQ = Old LQ * (1-alpha)
>
> This formula has a similar behaviour than the old one, but don't need a
> bitarray to store which hellos got lost. In addition to this new hellos have
> a higher weight than old ones.
So because the new hello's have a higher weight, when they are lost,
does increase the cost more than in olsr5.5
One more question, it might seem strange but it's something I have
never understood, In 802.11 all frames are acknowledged at layer 2 and
retransmitted to ensure a reliable layer 2. How does OLSR count lost
frames when, in theory, 802.11 should be retransmitting them? Does it
look at the sequence numbers of the hello's?
>
>> Tomorrow morning I will load it onto the other three nodes and let you
>> know how I go.
> I'm looking forward to it.
>
I tested out the new metric this morning on 6 nodes with dual radios
and it is working fine for me. Like Mitar pointed out, it does take
slightly longer to install routes with the new metric but that is not
an issue for me. I guess it is a consequence of the new smoothed moving
average.
Dave
More information about the Olsr-dev
mailing list