[Olsr-dev] Seeking comments: OLSR+ETX v/s DSR+ETX
Wed Jan 23 19:35:31 CET 2008
Wed 23 Jan 2008 15:07, Henning Rogge wrote:
> The recent ETX system is a default ETX implementation
ACK, i never said anything different :)
> ( count(received Hellos) / count (expected Hellos) )
> with a special "slow start feature".
a "slow start feature" is certainly nice and useful, but it should not
ruin the link-quality concept.
> 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)
ok, your definitions pretty much render the current code-implementation,
but i'm a simple man, like simple definitions :)
e.g. for the fun of it..
int const lq_wsize:
some constant (*eg* may also be negative ;)
total received number of hellos
number of lost hellos
> so as you can see, the variable "total" is always smaller than "lq_wsize".
..a matter of definitions..
> So the value of the formula should be between zero and 1.
well, given the constraints you gave, i also never disagreed
> There are two "clean" options how to calculate the link quality:
> 1.) received hellos / lq_wsize
this would be better, but certainly isn't "clean", nor really advisable.
> 2.) received hellos / number of possible hellos up to this point
this the only "clean" option.
"slow start feature" could be to start with a small measurement
intervall in the beginning and gradually make it bigger.
e.g. with option #1 lq_wsize is initially small and increases after some
e.g. with option #2 the "number of possible hellos up to this point" is
initially small and increases after some time.
> That's a "builtin" problem of all distributed routing protocolls... if the
> local instances use different configurations you get "strange results".
no, the link-quality concept as proposed in the original MIT paper clearly
does not have this problem.
(what's also why the ETX path-metric has all this nice features, like
being monotonic, etc.)
More information about the Olsr-dev