[Olsr-dev] Thoughts about an ETX-FF-Metric plugin
Thu Jun 19 19:31:08 CEST 2008
> sorry i of course meant the hello interval not the timeout,.
> and if its transmitted, everything is fine,..
Every hello contains the time (relative) when you can expect the next one.
> this is no problem, i only stated that some advanced parameters (targetet to
> the exponential history part) in extend to the dynamical hello interval are
> needed, but they will only rarely/never need to be changed by the end user,
> if we found good default values,..
> so it can configure itself based on the hello interval,..
> lq chart i made some months ago, to get real link (sesing) data from the
> router where it came from,..
> so it can be "installed" on fff routers to show a grpah of current lq/etx
> implementation and some graphs resulting from other interpretations of
> sensing the same link,..
> hmm, changeable behaviour?
> but, its dirty anyway, because what if a reboot happens just before the
> sequence numbers reach their upper limit
Maybe we can teach olsrd to send a "I'm switching off" packet before
it shuts down. This way the neighborhood has a chance to see the route
>> > the problem is that when the algorithm finds out it was a reboot he has
>> > already filled parts of the history with the low lq values, he generated
>> > with every lq timeout
>> yes, if the reboot happens fast enough this might be a problem.
> fast enough?
> you mean faster than the link timeout or what?
>> Not good... when the link times out the datastructure we are using to
>> store our information will be freed.
> it depends how long history is, whether i dislike this or not,..
> but imo its a good idea to completely stop routing over a link, much earlier
> than to drop any information about it,..
especially we don't need a second timer and a second database (we just
use an addition to the link database).
> yes, but i thin i want two timeouts, one to drop any routes over this link,
> and one to clear all information about this link
As long as the "clear information" timer is shorter than the "drop
route" timer this should be no problem.
> because a 30 second dead link, shouldn`t be used for routing, but if it
> comes up after 35 seconds, the link sensing should still have
> enough information to be at least as skeptic as if the link was down for 20
Which would be a problem for reboots.
> unidriectinoal or not was not my point, but a dead link`s etx drops slower
> than an 95% loss link, because its nlq is freezed, and i dislike this,..
> maybe it would be a good idea to lower the nlq with every hello timeout
> (only if no olsr packets from this node are received)
> the problem with this feature is, it just breaks anything, and creates loops
> for sure..
> (i will have to investigate a bit before writing any further on this point
At the moment we don't use any link for routing which LQ or NLQ
(neighbor linkquality) is below 0.1.
>> We will have to be careful with this...
> with what?
Careful with pushing out very different ETX values ;)
>> Difficult to use together with old routers.
> the resulting etx, will be stable, but lower,..
> but it`s true routes will more likely go over old routers which tend to
> generate too good values, ..
> so it`s of course a good idea to update old routers,..
"Wo kämen wir hin, wenn alle sagten, wo kämem wir hin, und niemand
ginge, um einmal zu schauen, wohin man käme, wenn man ginge." (Kurt
More information about the Olsr-dev