[Olsr-dev] LinkQualityMult problems in 0.5.6-r5

[Henning Rogge]

Am Samstag 05 September 2009 14:44:09 schrieb Daniel Nitzpon:
> do you mean something like
> https://dev.leipzig.freifunk.net/trac/browser/firmware/packages/global/frei
> funk-gwtun ?
> that has solved the issue of people messing with lqmult for gateway
> selection here. i'm surprised that the openwrt folks don't know about
> the package.
We are working on a service which can connect to the running routing daemon, 
so that you don't need to choose ONE gateway, you can set up some limitations 
for selection and still get the best gateway (with some kind of hysteresis to 
prevent flapping) matching your rule.

> >>> Hmm... would be interesting to do lqmult in a way that it only works if
> >>> both sides of the link agree to the change. That would allow "link
> >>> management" without all this strange "zero-gain" games.
> 
> i've never heard of a situation of "escalating race towards ever lower
> lqmult factors" between different neighbours that you seem to talk about
> and can hardly imagine a topology where that might occur. have you
> really experienced such situations?
I only have second hand stories (I only work on olsr.org, not on a freifunk 
network).

> just one example on where it might make sense to use lqmult: we have
> quite a chaotic mix of firmare and olsrd versions here. only quite
> recently we realized that only with a fixed multicast rate we will get
> meaningfully comparable lq values. however we can neither enforce the
> same setting everywhere as we might isolate nodes in doing so nor can we
> force people to upgrade their firmwares to a version that has a fixed
> default setting. so if we want to reflect the different relevance of lq
> values without recompiling olsrd or writing a new metric plugin lqmult
> is basically the only choice available.
I think the thing will only be resolved when networks start upgrading to 
OLSRv2.

> now this is still a global issue that might be solvable on firmware
> level, but our mesh is basically organized in the form that some people
> have lots of nodes in one or two streets and keep an eye on them and
> their settings. however we always have some node owners in between who
> do not answer to attempts on contacting them, and if one of these has a
> configuration that somehow yields good lq values but bad traffic
> results, what do you expect us to do?
Getting an ETT metric running (include bandwith in the metric). ;)

> discussing every case on a mailing
> list or a meeting is not really an option, i'm afraid...
Yes, that's a problem.

> please don't try to make olsrd "better" by taking configuration options
> away, this is exactly what the b.a.t.m.a.n. folks did and was the reason
> why we switched from batman to bmx as secondary experimental protocol..
We will only drop the option if we have other stuff that make it unnecessary.
Lq-Mult will be in the next olsrd version I think, but it will also contain 
stuff that will (hopefully) lower the usage of lq_mult.

Henning
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20090905/0c762458/attachment.sig>