[Olsr-dev] Thoughts about an ETX-FF-Metric plugin

Markus Kittenberger (spam-protected)
Thu Jun 19 20:33:57 CEST 2008


>
>
>
> 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
> loss coming.


a real packet special packet type, or just an hello with damn bad lq values
,..

>
>
> > 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.


i wanted it the other way round,..
do not use for routing fires earlier  (30 seconds after the last packet or
earlier (4x hello interval)) (it may also stop hello timeouts, and further
changes to the lq istory)
much later (5 minutes or later) the history is deleted

> 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
> > seconds,..
>
> Which would be a problem for reboots.


would be no problem if the device announces its reboot,.. (stopping all
neighbours from doing any further hello timeouts, modifing the history
without receiving packets)

how long does an started olsr needs currently before he has routes, 30
seconds?

> 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.


ok fine (i did forget this), replace 95% with 80% and think over it
again,..
but in fact its irrelevant that with 95% loss this link wouldn`t be used
sometimes (when its lq is low enough)

what disturbs me ist that it will take substantially more time for an dead
link to drop from ETX 1.0 to an e.g 4.0 (LQ 0.25 NLQ 1.0) (at >= 4 for
example an alternative route would be used)
than for an link with suddenly 85% loss, which can be nearly twice as fast
(#), because NLQ will drop too, so with an LQ of 0.5 and nlq of 0.5 ETX 4.0
is reached

# and maybe in relity more than twice as fast as it doesn`t have to wait on
hello timeouts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20080619/04c102cf/attachment.html>


More information about the Olsr-dev mailing list