[Olsr-dev] Seeking comments: OLSR+ETX v/s DSR+ETX
Wed Jan 23 15:07:45 CET 2008
Am Mittwoch 23 Januar 2008 14:38:47 schrieb sebastian:
> NAK. just do e.g. the algebraic proof to see that this is just wrong.
> ok, now you are no longer refering to the formula, but to the current code.
> infact the lq_wsize is a completely redundant variable.
The recent ETX system is a default ETX implementation
( count(received Hellos) / count (expected Hellos) )
with a special "slow start feature".
Configured maximumm size of the link quality window
total received number of hellos or lq_wsize (whichever is lower)
number of lost hellos or total (whichever is lower)
(so "total - lost" is the number of hellos we got)
so as you can see, the variable "total" is always smaller than "lq_wsize".
"lost" is a value between 0 (perfect link) and total-1 (got only 1 hello).
(all variables are >= 0 of course)
lq = (total - lost) * / ( (total + olsr_cnf->lq_wsize) / 2 );
total >= lost
=> total - lost >= 0
total <= lq_wsize
=> total + total <= total + lq_wsize
=> total <= (total + lq_wsize)/2
lost >= 0
=> total - lost <= total
=> total - lost <= total <= (total + lq_wsize)/2
=> total - lost <= (total + lq_wsize)/2
=> (total - lost) / ( (total + lq_wsize)/2 ) <= 1
So the value of the formula should be between zero and 1.
There are two "clean" options how to calculate the link quality:
1.) received hellos / lq_wsize
2.) received hellos / number of possible hellos up to this point
The first option has the problem that new links need a long time to get a good
LQ value (at least lq_wsize hellos !), the second one let a new link start
with quality 1 (one of one hello received).
The reason for the (total + lq_wsize)/2 part of the formula is a tradeof for
new links so that a new link starts with a value between 1/lq_wsize and 1.
The formula you find at the moment in the code has a similar effect, only a
little bit more complicated.
> also every node in the network can have a different lq_wsize, therefore a
> different bias in the lq meassurement. just the next ugly thing due to
That's a "builtin" problem of all distributed routing protocolls... if the
local instances use different configurations you get "strange results".
More information about the Olsr-dev