On Tue, Dec 22, 2009 at 11:42 PM, Fred Moyer
<fred <at> slwifi.com> wrote:
On Tue, Dec 22, 2009 at 2:28 PM, Markus Kittenberger
<
Markus.Kittenberger <at> gmx.at> wrote:
> i think the best solution is to do QOS on your links, and priorize olsr
> traffic above antything else
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?
> 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
So you would suggest turning fisheye off? The target networks are
5-200 node wifi mesh networks.
for the smaller ones turn it off, without thinking about it
i think 200 nodes will still be quite well manageable without fisheye, depends on your message intervals, and how much bandwidth you are willing to let olsr use,.. (or how fast your slowest links are)
but make sure u have only new olsrds, as we had some changes/bugfixes in r5 and r6 which reuced the amount of traffic
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 *G
> On Tue, Dec 22, 2009 at 11:16 PM, Fred Moyer <
fred <at> slwifi.com> wrote:
>>
>> Greetings,
>>
>> I'm looking for some feedback on a suggested FishEye based OLSR
>> configuration file on
open-mesh.com devices. These are static wifi
>> mesh networks in various configurations. I've been seeing some route
>> switching in cases where there is short bursts of UDP traffic on the
>> devices, so I was looking to make the routes a bit more stable.
>>
>> The current OLSR conf is here -
>>
>>
http://www2.hosted-projects.com/trac/ansanto/robin-mesh/browser/trunk/robin-mesh/files/etc/olsrd.conf.robin
>>
>> Below is my modified version based on reading through the OLSR docs
>> and source. Please feel free to comment on my changes here,
>> especially if it doesn't look like it is doing what my comments said.
>> Many thanks in advance!
>>
>> The big change is with the HelloInterval and HelloValidityTime. They
>> are setup based on the suggested calculations in
>> README-Link-Quality.html
>>
>> However, the HelloInterval is kept at 6 seconds, as the current
>> configuration is. So this gives a 5 minute window over which 100%
>> OLSR packet loss would cause a route switch. This *should* make the
>> routes more stable to packet loss from interference from user and
>> system traffic.
>>
>> -------------------------------------------
>>
>> DebugLevel 0
>>
>> IpVersion 4
>> AllowNoInt yes
>>
>> # 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
>>
>> # defaults from files/olsrd.conf.default.lq-fisheye
>> TcRedundancy 2
>> MprCoverage 7
>> LinkQualityFishEye 1
as said above, better turn it off
>>
>> #
>> LinkQualityWinSize 100
value is not used any more afaik
>> LinkQualityDijkstraLimit 0 9.0
>> LinkQualityLevel 2
>> UseHysteresis no
>>
>> # 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?
>>
>> Interface "ath0"
>> {
>> Ip4Broadcast 255.255.255.255
>>
>> # 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
>> 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
>>
>> # 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
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
>> 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
--
Silver Lining Networks
http://slwifi.com/
http://twitter.com/slwifi
o: 888.334.6602
m: 415.720.2103
RSS Feed