[Olsr-users] How to make routes *very* sticky?

Teco Boot (spam-protected)
Wed Jun 3 10:12:33 CEST 2015


Could you check your queuing strategy? The olsrd packets could get dropped by Linux queue management, NIC driver or NIC hardware. There is some space for improvement.

ETX link measurement should not be influenced badly by user traffic. On the other hand, high rate of olsrd packets in highest priority queue has bad effects on real time traffic. Also because multicast is on low data rate.

There is the olsrd TosValue parameter, you could mark olsrd packets with "Network Control" (TosValue 192).
No reason not having fq_codel in place. However, because lower layer queue management dominates, it doesn't help that much.
Most difficult part is to manage queue strategy of NIC driver and hardware. Broadcast packets might have its special handling. Check net/mac80211/wme.c on is_multicast_ether_addr(ra).

Having codel at driver level is a research topic. Dave Taht could inform you on current status.

Please let us know results, this is an important topic. 

Teco


> Op 3 jun. 2015, om 05:55 heeft Ben West <(spam-protected)> het volgende geschreven:
> 
> I've been running a stress test on a mesh of 4 UBNT M5 radios with Openwrt 14 and olsrd 0.6.6.2 (the version still bundled with Barrier Breaker). The 3 repeater nodes are situated so that one provides an ideal route for the other two back to the gateway node, with poorer wireless links between them for redunancy.
> 
> The purpose of the test is to exercise the wifi driver to see if a recurring lockup problem encountered with previous versions of Openwrt is resolved (so far, yes, happily) , but I'd also been using the opportunity to try out olsrd under heavier traffic load.
> 
> When I let all 3 repeater nodes run iterative curl downloads of a 500MB file located upstream of the gateway node, i.e. to saturate all links (ping times in the 100's of milliseconds), it looks like olsrd starts flapping routes, breaking SSH sessions and other TCP streams.  This doesn't occur with those nodes set to static routes and olsrd disabled.  I understand this behavior is by design, as the poor ETX values from saturated links will make the weaker, redundant links more appealing.  However, frequency of flapping (~1x per hour), or so) is a bit disruptive.
> 
> My /etc/config/olsrd on all nodes is quoted below.  What is the best way these days to enforce route stickiness?  I.e. try setting very low values for SmartGatewaySpeed or is link hysteresis the more appropriate variable to play with?
> 
> config olsrd
> 
>     option 'IpVersion' '4'
>     option 'LinkQualityLevel' '2'
>     option 'LinkQualityAlgorithm' 'etx_ffeth'
>     option 'SmartGateway' 'yes'
>     option 'SmartGatewayUseCount' '1'
>     option 'Pollrate' '0.1'
> 
> config 'LoadPlugin'
>     option 'library' 'olsrd_arprefresh.so.0.1'
> 
> config 'LoadPlugin'
>     option 'library' 'olsrd_dyn_gw.so.0.5'
>     option 'HNA' '0.0.0.0 0.0.0.0'
> 
> config 'LoadPlugin'
>   option 'library' 'olsrd_nameservice.so.0.3'
>   option 'sighup_pid_file' '/var/run/dnsmasq.pid'
>   option 'suffix' '.mesh'
> 
> config 'LoadPlugin'
>     option 'library' 'olsrd_txtinfo.so.0.1'
>     option 'port'    '2006'
>     option 'Accept' '127.0.0.1'
> 
> config 'Interface'
>     list 'interface' 'wan'
>     option 'Mode' 'ether'
> 
> config 'Interface'
>     list 'interface' 'mesh'
>     option 'Ip4Broadcast' '255.255.255.255'
>      option 'Mode' 'mesh'
> 
> -- 
> Ben West
> http://gowasabi.net <http://gowasabi.net/>
> (spam-protected) <mailto:(spam-protected)>
> 314-246-9434
> -- 
> Olsr-users mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20150603/56670007/attachment.html>


More information about the Olsr-users mailing list