[Olsr-dev] Idea for small OLSR improvement

[Markus Kittenberger]

the point is, just keeping the last route "forever" sounds uhmmm .. not
desireable for me,..

as i prefer having no loop, or long route into nowhere, when trying to reach
a node that is actually down,..

and if the node is still active, and has any useable links (e.g. lq > 0.3)
than an bugfree, and wellconfigured olsrd mesh, will not drop route to it,..

(based on about how much the lq values are changing over time on typical bad
links i know)

especially your usually 1.0 links would never drop wihtout misoncifguration
or a bug, so lets find out why they do!!!

but anyways it might be useful to allow somewhat a hysteresis on the
"linktoobad" decision (which ist at 0.1)

e.g. on lower threshold like 0.05 to stop announcing it, and one
significantly higher one like 0.2 to enable it again.
this should reduce fluctuations on bad or gone links,..
(afaik we already had this idea months ago, and maybe it already in !? *G)

btw i doubt that wind & tree effects really cause such fluctuation often,..

usually a tree moves only for some seconds into a link, not enough to reduce
the lq very much,..

of course if the link was already very bad, it might make the difference,
but i think we are not talking about very bad links here,..

regards Markus


On Sat, Apr 24, 2010 at 1:47 PM, Mitar <(spam-protected)> wrote:

> Hi!
>
> On Sat, Apr 24, 2010 at 1:08 PM, Markus Kittenberger
> <(spam-protected)> wrote:
> > the problem is that links that are regarded as too bad, are currently not
> > used anywhere in the mesh,..
>
> I am not talking just about really bad links but also about very good
> links which get temporary (maybe because of the bug in OLSR of WiFi
> driver) removed. Like this node:
>
> https://nodes.wlan-lj.net/nodes/node/a9c18585-0fc3-47ac-a0d1-a24b8fafe1c4
>
> It has almost all the time ETX 1.0 link to peering node (you can also
> check the graph bellow).
>
> But then the link really fluctuates:
>
> https://nodes.wlan-lj.net/nodes/events/a9c18585-0fc3-47ac-a0d1-a24b8fafe1c4
>
> (Down/up events are events of removing a node from the mesh and back
> as reported by OLSR.)
>
> We check topology in 5 minutes intervals but I have reports from users
> of that node that there are also many shorter removals from the mesh.
> I have wrote about this some time ago and then it was suggested that
> we do not use same IP for multiple interfaces. We now do not use that
> anymore, but strange link drops still happen. (I think there are some
> bugs in OLSR timers. But maybe it is just bad madwifi driver although
> if I manually add route between nodes and ping from both directions
> there is almost no packet loss (and no packet loss bursts).
>
> This is just one example of where this would be useful. The other
> example is where there is a moving tree (a realworld example) just in
> the link line. And OLSR is just dropping the link and putting it back.
> In this way it would be useful just to leave it alone and lower levels
> will try to do something (or not).
>
> > changing this behaviour for the last reminaing link to a node only, might
> > get a bit complex, what happens if u have on very bad link and one
> dramatic
> > bad link
> > if only the very bad link it detected, it gets announced as its the last
> > one, but if the dramatic bad link gets a bit better, sall we announce it
> > too? or (worst case) don`t announce both? *g
>
> I do not understand why is this a problem? It is the same as now -
> logic behind deciding what to announce or not. If there are multiple
> links we chose the best one. If it is just one, we keep it. If some
> other comes we use the new one if it is the only one measured. So it
> is just just laziness in removing the last route. Everything else
> stays the same. So when new (properly measured) link is established we
> clean-up previous stale route and use new one.
>
> It can just improve things a bit. Everyhing else stays the same.
>
>
> Mitar
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100424/5f2fe1c1/attachment.html>