[Olsr-dev] Seeking comments: OLSR+ETX v/s DSR+ETX

Sven-Ola Tuecke (spam-protected)
Wed Dec 19 12:15:10 CET 2007


Hi Sebastian,

don't know, what parts of the current olsrd implementation you denote with 
the term "voodoo". Link quality is a number between 0.0 and 1.0 and it 
reflecs how many packages are lost between sender and receiver. How LQ is 
evaluated/measured may #include <voodoo.h> (especially the 128er bit mask 
array) but nothing that really deserves that term IMO.

The rest is a formula, commonly known as ETX. Which is optimized / meant for 
meshing with single interfaces. Because the plus operator in (1/LQ + 1/NLQ) 
it favors routes with less hops (theres a magic '2' in there ;-).

Current EXT overcomes a small weakness in LQ-only measurements: If a certain 
amount of links in a path do not have packet loss, the second-level criteria 
(Hops) works well for route decisions. Moreover - there where talks about 
exchaning that plus with a multiplication operator (hence something like 
1/LQ * 1/NLQ) or introducing some "voodoo factors" to have a 
seamless/tweakable transition between '+' and '*'. But I think that's 
another story...

// Sven-Ola

"sebastian sauer" <(spam-protected)> schrieb im Newsbeitrag 
news:(spam-protected)
> Wed 12 Dec 2007 23:17, Hannes Gredler wrote:
>> Sudheendra Murthy wrote:
>> > It is clear that OLSR+ETX has additional overhead of sending TC
>> > messages when compared with DSR+ETX. Does this overhead provide
>> > significant benefits? I am interested in knowing the pros and cons of
>> > the OLSR+ETX and DSR+ETX protocols.
>>
>> the overhead is next to nothing -
> ACK.
>
>> ans yes it provides significant benefits.
> ACK.
>
> further the ETX is the same in both OLSR and DSR.
>
> what differs greatly is the linkquality definition/implementation.
> this part is not properly implemented in OLSR at the moment, in fact
> the current implementation can only be explained by "voodoo-magic" but
> not on the grounds of rational thought.
>
> i already worked on a patch, but never found time for testing it properly
> or to bring this topic to this ML.
>
> cheers,
> s.
>
> -- 
> Olsr-dev mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-dev 





More information about the Olsr-dev mailing list