[Olsr-dev] Idea for small OLSR improvement

[Markus Kittenberger]

u might than suffer from timeouts,..

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)

maybe caused by to much fisheye

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/5715d5e7/attachment.html>