<div>the point is, just keeping the last route "forever" sounds uhmmm .. not desireable for me,..<br></div><div><br></div><div>as i prefer having no loop, or long route into nowhere, when trying to reach a node that is actually down,..</div>
<div><br></div><div>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,.. </div><div>(based on about how much the lq values are changing over time on typical bad links i know)</div>
<div><br></div><div>especially your usually 1.0 links would never drop wihtout misoncifguration or a bug, so lets find out why they do!!!</div><div><br></div><div>but anyways it might be useful to allow somewhat a hysteresis on the "linktoobad" decision (which ist at 0.1) </div>
<div><br></div><div>e.g. on lower threshold like 0.05 to stop announcing it, and one significantly higher one like 0.2 to enable it again.</div><div>this should reduce fluctuations on bad or gone links,..</div><div>(afaik we already had this idea months ago, and maybe it already in !? *G)</div>
<div><br></div><div>btw i doubt that wind & tree effects really cause such fluctuation often,..<br></div><div><br></div><div>usually a tree moves only for some seconds into a link, not enough to reduce the lq very much,..</div>
<div><br></div><div>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,..</div><div><br></div><div>regards Markus</div><div><br></div><br><div class="gmail_quote">
On Sat, Apr 24, 2010 at 1:47 PM, Mitar <span dir="ltr"><<a href="mailto:mmitar@gmail.com">mmitar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi!<br>
<div class="im"><br>
On Sat, Apr 24, 2010 at 1:08 PM, Markus Kittenberger<br>
<<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>> wrote:<br>
> the problem is that links that are regarded as too bad, are currently not<br>
> used anywhere in the mesh,..<br>
<br>
</div>I am not talking just about really bad links but also about very good<br>
links which get temporary (maybe because of the bug in OLSR of WiFi<br>
driver) removed. Like this node:<br>
<br>
<a href="https://nodes.wlan-lj.net/nodes/node/a9c18585-0fc3-47ac-a0d1-a24b8fafe1c4" target="_blank">https://nodes.wlan-lj.net/nodes/node/a9c18585-0fc3-47ac-a0d1-a24b8fafe1c4</a><br>
<br>
It has almost all the time ETX 1.0 link to peering node (you can also<br>
check the graph bellow).<br>
<br>
But then the link really fluctuates:<br>
<br>
<a href="https://nodes.wlan-lj.net/nodes/events/a9c18585-0fc3-47ac-a0d1-a24b8fafe1c4" target="_blank">https://nodes.wlan-lj.net/nodes/events/a9c18585-0fc3-47ac-a0d1-a24b8fafe1c4</a><br>
<br>
(Down/up events are events of removing a node from the mesh and back<br>
as reported by OLSR.)<br>
<br>
We check topology in 5 minutes intervals but I have reports from users<br>
of that node that there are also many shorter removals from the mesh.<br>
I have wrote about this some time ago and then it was suggested that<br>
we do not use same IP for multiple interfaces. We now do not use that<br>
anymore, but strange link drops still happen. (I think there are some<br>
bugs in OLSR timers. But maybe it is just bad madwifi driver although<br>
if I manually add route between nodes and ping from both directions<br>
there is almost no packet loss (and no packet loss bursts).<br>
<br>
This is just one example of where this would be useful. The other<br>
example is where there is a moving tree (a realworld example) just in<br>
the link line. And OLSR is just dropping the link and putting it back.<br>
In this way it would be useful just to leave it alone and lower levels<br>
will try to do something (or not).<br>
<div class="im"><br>
> changing this behaviour for the last reminaing link to a node only, might<br>
> get a bit complex, what happens if u have on very bad link and one dramatic<br>
> bad link<br>
> if only the very bad link it detected, it gets announced as its the last<br>
> one, but if the dramatic bad link gets a bit better, sall we announce it<br>
> too? or (worst case) don`t announce both? *g<br>
<br>
</div>I do not understand why is this a problem? It is the same as now -<br>
logic behind deciding what to announce or not. If there are multiple<br>
links we chose the best one. If it is just one, we keep it. If some<br>
other comes we use the new one if it is the only one measured. So it<br>
is just just laziness in removing the last route. Everything else<br>
stays the same. So when new (properly measured) link is established we<br>
clean-up previous stale route and use new one.<br>
<br>
It can just improve things a bit. Everyhing else stays the same.<br>
<font color="#888888"><br>
<br>
Mitar<br>
<br>
</font></blockquote></div><br>