<br><br><div><span class="gmail_quote">On 6/15/08, <b class="gmail_sendername">L. Aaron Kaplan</b> <<a href="mailto:aaron@lo-res.org">aaron@lo-res.org</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br> > when we were testing it at the Meraka 'Massive Mesh' grid under high<br> > payload.) To get entirely rid of routing loops, TC redundancy has<br> > to be<br> > even greater. But the resulting protocol overhead is much more severe<br>
 > then occasional routing loops that persist for a couple of seconds.<br> > This<br> > is a limitation of the protocol design.</blockquote><div>imo every routing protocol needs qos priorization sooner or later,..</div>
<br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">So basically what you are saying is "let's spam more because we can't</blockquote><div> </div>
<div>So why is there no QOS in fff?</div><div><br>afaik all needed tools are already available on fff / openwrt, imo just a lack of configuration,..</div><div></div><div>Is there just nobody who makes proper configuration, or are there other/technical reasons for not doing it?</div>
<div></div><div>if the first is the case, i`ll do it, ...</div><div></div><div>Markus</div><br></div><br>