[Olsr-dev] Looking for developer feedback on olsrd.conf values

[Fred Moyer]

On Wed, Dec 23, 2009 at 3:56 AM, Markus Kittenberger
<(spam-protected)> wrote:
>
> On Tue, Dec 22, 2009 at 11:42 PM, Fred Moyer <(spam-protected)> wrote:
>>
>> On Tue, Dec 22, 2009 at 2:28 PM, Markus Kittenberger
>> <(spam-protected)> wrote:
>> > i think the best solution is to do QOS on your links, and priorize olsr
>> > traffic above antything else
>>
>> I'm going to be implementing that but wanted to make sure my config
>> values were not wildly out of whack to start with.
>
> i looked at the config now, did you write it (especially the comments)
> yourself, or did u find this configuration somewhere?

I wrote it based on the initial conf file I was working with, and
implemented suggestions found in the README files and the default
fisheye conf file.  I referenced the code as needed for further
information on directives that weren't fully documented.

>> > fisheye will not have effects on stability, it will reduce traffic, but
>> > may
>> > bring you even more troubles in combination with often changing routes
>> > or in
>> > fact changing lq values
...
> if you turn on fisheye, u will have less trassic, but much errors, as link
> state routeing protocols don`t do well if one node knows more than the other

Huh, good to know, thank you.

>> >> # bump the pollrate in between the existing ROBIN 0.5 and the fisheye
>> >> default of 0.05
>> >> Pollrate 0.1
>
> at least for larger networks leave the default here, as you may loose
> packets if this vlaue is too high

Ok

>> >> # defaults from files/olsrd.conf.default.lq-fisheye
>> >> TcRedundancy 2
>> >> MprCoverage 7
>> >> LinkQualityFishEye 1
>
> as said above, better turn it off

Got it.

>> >> LinkQualityWinSize 100
>
> value is not used any more afaik

Good to know, thank you.  May have some patches to the docs for you.

>> >> # require a 50% link quality difference for route switch
>> >> # http://www.olsr.org/?q=sticky-gateway
>> >> NatThreshold 0.5
>
> the comment is wrong afaik
> furthermore the more threshhold you use, the more routing loops you might
> get,
> do you have multiple gateways? that are doing nat?

Yes, multiple gateways doing nat.  Do you think 0.5 is ok here for
multiple gateways on a large network, or would you go smaller?

>> >>  # set the HELLO validity time to the HELLO interval multiplied
>> >>  # by the LinkQualityWinSize, from README-Link-Quality.html
>> >>  # This configuration will cause a route switch in 5 minutes with
>> >>  # a 100% HELLO loss, 10 minutes with a 50% HELLO loss
>
> again the comment is wrong/outdated

Thanks for the heads up on that.

>> >>  HelloInterval 6.0
>> >>  HelloValidityTime 600.0
>
> it will couse a route switch much faster now,.. furhtermore such a high
> validity time for messages that are only sent to the direct neighbour,..
> i would suggest 100

Great, thanks.

>> >>  # defaults from files/olsrd.conf.default.lq-fisheye
>> >>  TcInterval 2
>
> use ~5 seconds (especially if u turned off fisheye as recommended)
> the information in the tcs relies on information gathered by the hellos, so
> sending tcs tc more often than hellos makes imho only sense if you plan to
> get rid off the tc messages somehow (extremely heavy packet loss or fisheye)
> slight packet loss will usually be no problem, as every neighbour that gets
> the message braodcasts it again, so if you have (usually) multiple
> neighbours per node, most messages will get flooded to the complete network
> quite reliable, so no need for high interval
>>
>> >>  TcValidityTime 500.0
>
> very high validity again, 250x times the interval as validity looks insane
> to me
> if you use fisheye the value is ok, if suggest to lower it to 200 or less,..
> afair only tcs are affected of fisheye, so tc timings are the only values
> you have to adapt when you turn on/off fisheye

Great, will adjust this.  I got this number from the default config.

>> >>  MidInterval 25.0
>> >>  MidValidityTime 500.0
>> >>  HnaInterval 125.0
>> >>  HnaValidityTime 125.0
>
> having same interval and validity time, is even more insane (even in a
> network without packet loss race conditions will happen that will time out
> your hnas)
> whatever, try to have the validity times of all values within 5-15x of the
> interval than message intervals

Will do.  Thank you very much for the review and suggestions!