<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 14, 2014 at 12:03 PM, Nicholas Weaver <span dir="ltr">&lt;<a href="mailto:nweaver@icsi.berkeley.edu" target="_blank">nweaver@icsi.berkeley.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I responded just to Jim and not the group.<br>
<br>
But I should add some on the latter comment by Jim, as I didn&#39;t answer in as much detail and its probably of interest to the general group as well, and starting a discussion here would be good.<br>
<div class=""><br>
<br>
On Apr 9, 2014, at 12:23 PM, Jim Gettys &lt;<a href="mailto:jg@freedesktop.org">jg@freedesktop.org</a>&gt; wrote:<br>
</div><div class="">&gt; Any progress on adding a test for whether flow queuing is enabled?  There are commercial routers out there shipping fq_codel, and it would be interesting to be able to watch it deploy.<br>
<br>
</div>This has been on our todo list for a while, but we haven&#39;t implemented it yet, and we are looking for feedback before we start coding.<br>
<br>
Our thoughts are as follows:<br>
<br>
Create a &quot;load traffic&quot; that is 3 TCP streams.  3 seems to be a good consensus load value for bandwidth testing (its what <a href="http://speedtest.net" target="_blank">speedtest.net</a> uses).<br>
<br>
In parallel, use our UDP ping test (the one we use just before to generate the quiescent latency) and use that to determine the RTT.<br>
<br>
In cases where there is no smart queuing, this should get the same results as before, as 3 streams should start quickly enough that the 5 second rampup should leave things in steady state.<br>
<br>
But if there is smart queueing, the UDP packets should (hopefully) be given enough priority to not see queuing delays.  Since UDP, rather than TCP, is used for the interactive tasks most affected by buffering issues, if the UDP is not given priority in the queueing delay, then this isn&#39;t an effective solution for the problem.<br>
<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">​This will work. Doesn&#39;t matter whether you use a UDP ping test or not; you could just as well arrange a ping operation on a separate TCP flow that you are not driving to saturation. ​if the bottleneck link identifies it as a separate flow and implements flow queuing, the observed time should not significantly increase (or will only increase to the remaining uncontrolled buffering at the bottleneck, a common situation since drivers may have buffering out of control of a flow queuing algorithm). </div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Dave, any other suggestions?</div><div class="gmail_default" style="font-size:small">                        - Jim</div>
<div class="gmail_default" style="font-size:small"><br></div></div></div></div>