<div>u might than suffer from timeouts,..<br></div><div><br></div><div>did u check how close to timing things are (ether is an compile time flag to enable display of timeouts intxtinfo) (see txtinfo header file)</div><div>
<br></div><div>maybe caused by to much fisheye</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>