[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