<div><br></div><div class="gmail_quote">On Tue, Dec 22, 2009 at 11:42 PM, Fred Moyer <span dir="ltr"><<a href="mailto:fred@slwifi.com">fred@slwifi.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Dec 22, 2009 at 2:28 PM, Markus Kittenberger<br>
<<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>> wrote:<br>
> i think the best solution is to do QOS on your links, and priorize olsr<br>
> traffic above antything else<br>
<br>
</div>I'm going to be implementing that but wanted to make sure my config<br>
values were not wildly out of whack to start with.<br></blockquote><div>i looked at the config now, did you write it (especially the comments) yourself, or did u find this configuration somewhere?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> fisheye will not have effects on stability, it will reduce traffic, but may<br>
> bring you even more troubles in combination with often changing routes or in<br>
> fact changing lq values<br>
<br>
</div>So you would suggest turning fisheye off? The target networks are<br>
5-200 node wifi mesh networks.<br></blockquote><div><div>for the smaller ones turn it off, without thinking about it<br></div><div><br></div><div>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)</div>
<div><br></div><div>but make sure u have only new olsrds, as we had some changes/bugfixes in r5 and r6 which reuced the amount of traffic</div><div><br></div><div>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</div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div class="h5"><br>
> On Tue, Dec 22, 2009 at 11:16 PM, Fred Moyer <<a href="mailto:fred@slwifi.com">fred@slwifi.com</a>> wrote:<br>
>><br>
>> Greetings,<br>
>><br>
>> I'm looking for some feedback on a suggested FishEye based OLSR<br>
>> configuration file on <a href="http://open-mesh.com" target="_blank">open-mesh.com</a> devices. These are static wifi<br>
>> mesh networks in various configurations. I've been seeing some route<br>
>> switching in cases where there is short bursts of UDP traffic on the<br>
>> devices, so I was looking to make the routes a bit more stable.<br>
>><br>
>> The current OLSR conf is here -<br>
>><br>
>> <a href="http://www2.hosted-projects.com/trac/ansanto/robin-mesh/browser/trunk/robin-mesh/files/etc/olsrd.conf.robin" target="_blank">http://www2.hosted-projects.com/trac/ansanto/robin-mesh/browser/trunk/robin-mesh/files/etc/olsrd.conf.robin</a><br>
>><br>
>> Below is my modified version based on reading through the OLSR docs<br>
>> and source. Please feel free to comment on my changes here,<br>
>> especially if it doesn't look like it is doing what my comments said.<br>
>> Many thanks in advance!<br>
>><br>
>> The big change is with the HelloInterval and HelloValidityTime. They<br>
>> are setup based on the suggested calculations in<br>
>> README-Link-Quality.html<br>
>><br>
>> However, the HelloInterval is kept at 6 seconds, as the current<br>
>> configuration is. So this gives a 5 minute window over which 100%<br>
>> OLSR packet loss would cause a route switch. This *should* make the<br>
>> routes more stable to packet loss from interference from user and<br>
>> system traffic.<br>
>><br>
>> -------------------------------------------<br>
>><br>
>> DebugLevel 0<br>
>><br>
>> IpVersion 4<br>
>> AllowNoInt yes<br>
>><br>
>> # bump the pollrate in between the existing ROBIN 0.5 and the fisheye<br>
>> default of 0.05<br>
>> Pollrate 0.1<br></div></div></blockquote><div>at least for larger networks leave the default here, as you may loose packets if this vlaue is too high</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div class="h5">
>><br>
>> # defaults from files/olsrd.conf.default.lq-fisheye<br>
>> TcRedundancy 2<br>
>> MprCoverage 7<br>
>> LinkQualityFishEye 1<br></div></div></blockquote><div>as said above, better turn it off </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">
>><br>
>> #<br>
>> LinkQualityWinSize 100<br></div></div></blockquote><div>value is not used any more afaik </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">
>> LinkQualityDijkstraLimit 0 9.0<br>
>> LinkQualityLevel 2<br>
>> UseHysteresis no<br>
>><br>
>> # require a 50% link quality difference for route switch<br>
>> # <a href="http://www.olsr.org/?q=sticky-gateway" target="_blank">http://www.olsr.org/?q=sticky-gateway</a><br>
>> NatThreshold 0.5<br></div></div></blockquote><div>the comment is wrong afaik</div><div>furthermore the more threshhold you use, the more routing loops you might get, </div><div><br></div><div>do you have multiple gateways? that are doing nat?</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">
>><br>
>> Interface "ath0"<br>
>> {<br>
>> Ip4Broadcast 255.255.255.255<br>
>><br>
>> # set the HELLO validity time to the HELLO interval multiplied<br>
>> # by the LinkQualityWinSize, from README-Link-Quality.html<br>
>> # This configuration will cause a route switch in 5 minutes with<br>
>> # a 100% HELLO loss, 10 minutes with a 50% HELLO loss<br></div></div></blockquote><div>again the comment is wrong/outdated </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div class="h5">
>> HelloInterval 6.0<br>
>> HelloValidityTime 600.0<br></div></div></blockquote><div>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,..</div><div>
i would suggest 100</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">
>><br>
>> # defaults from files/olsrd.conf.default.lq-fisheye<br>
>> TcInterval 2<br></div></div></blockquote><div>use ~5 seconds (especially if u turned off fisheye as recommended) </div><div><br></div><div>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)</div>
<div><br></div><div>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</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">
>> TcValidityTime 500.0<br></div></div></blockquote><div>very high validity again, 250x times the interval as validity looks insane to me </div><div>if you use fisheye the value is ok, if suggest to lower it to 200 or less,..</div>
<div><br></div><div>afair only tcs are affected of fisheye, so tc timings are the only values you have to adapt when you turn on/off fisheye</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div class="h5">
>> MidInterval 25.0<br>
>> MidValidityTime 500.0<br>
>> HnaInterval 125.0<br>
>> HnaValidityTime 125.0<br></div></div></blockquote><div>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)</div>
<div><br></div><div>whatever, try to have the validity times of all values within 5-15x of the interval than message intervals</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div class="h5">
>> }<br>
>><br>
>> LoadPlugin "olsrd_txtinfo.so.0.1"<br>
>> {<br>
>> PlParam "port" "8090"<br>
>> PlParam "Host" "127.0.0.1"<br>
>> }<br>
>><br>
>> --<br>
>> Olsr-dev mailing list<br>
>> <a href="mailto:Olsr-dev@lists.olsr.org">Olsr-dev@lists.olsr.org</a><br>
>> <a href="http://lists.olsr.org/mailman/listinfo/olsr-dev" target="_blank">http://lists.olsr.org/mailman/listinfo/olsr-dev</a><br>
>><br>
><br>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
Silver Lining Networks<br>
<a href="http://slwifi.com/" target="_blank">http://slwifi.com/</a><br>
<a href="http://twitter.com/slwifi" target="_blank">http://twitter.com/slwifi</a><br>
o: 888.334.6602<br>
m: 415.720.2103<br>
<br>
</font></blockquote></div><br>