<div dir="ltr"><div><div><div>Thank you Teco and Henning for the responses.  I do fully agree overloading a multi-hop link is suboptimal.  I'm actually doing this for the purpose of stress testing, i.e. wilfully creating worst case conditions.<br><br></div>I did not enable any special queuing strategy or QoS on these nodes under test, besides whatever OpenWRT v14 decides to use with stock configuration.  I anticipated fq_codel tweaking to be doable as a later step (or in parallel).<br><br></div>The route flapping doesn't occur when these nodes don't use olsr just have static routes set, yet with the same traffic (over)load.  My interest in trying to deploy olsr in this mesh is to see if it could be useful in establishing backup routes through the redundant wifi links, in the event of a repeater node along the preferred multi-hop route going down.  (I.e. where just setting static routes manually would fail.)<br><br></div>Indeed, I wouldn't expect olsrd to flap routes disruptively under moderate traffic load.  However, the catch-22 I'm seeing is that the backup routes through the weaker links would be <i>more</i> likely to saturate (i.e. since their capacity is less), meaning the very conditions where I'd like to see olsr establish the backup routes are also those where it may start flapping routes disruptively.<br><div><div><div><br></div><div>Independent of queuing discipline (if any), what is the best way simply to make olsrd extremely unwilling to change routes?  I.e. where a particular link has to be extremely bad (or non-existent if the node goes down) where olsrd alters any routes?<br></div><div><br><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 3, 2015 at 3:17 AM, Henning Rogge <span dir="ltr"><<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Jun 3, 2015 at 10:12 AM, Teco Boot <<a href="mailto:teco@inf-net.nl">teco@inf-net.nl</a>> wrote:<br>
> Could you check your queuing strategy? The olsrd packets could get dropped<br>
> by Linux queue management, NIC driver or NIC hardware. There is some space<br>
> for improvement.<br>
><br>
> ETX link measurement should not be influenced badly by user traffic. On the<br>
> other hand, high rate of olsrd packets in highest priority queue has bad<br>
> effects on real time traffic. Also because multicast is on low data rate.<br>
><br>
> There is the olsrd TosValue parameter, you could mark olsrd packets with<br>
> "Network Control" (TosValue 192).<br>
<br>
</span>This is the default setting for current olsrd (and for olsrd2).<br>
<span class=""><br>
> No reason not having fq_codel in place. However, because lower layer queue<br>
> management dominates, it doesn't help that much.<br>
> Most difficult part is to manage queue strategy of NIC driver and hardware.<br>
> Broadcast packets might have its special handling. Check net/mac80211/wme.c<br>
> on is_multicast_ether_addr(ra).<br>
><br>
> Having codel at driver level is a research topic. Dave Taht could inform you<br>
> on current status.<br>
<br>
</span>There is also the point that overloading a multihop wifi link is a bad idea.<br>
<span class="HOEnZb"><font color="#888888"><br>
Henning<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>314-246-9434<br></div></div>
</div>