[Netalyzr] Error reported on test...

Jim Gettys jg at freedesktop.org
Mon Apr 14 09:10:44 PDT 2014

On Mon, Apr 14, 2014 at 12:03 PM, Nicholas Weaver <nweaver at icsi.berkeley.edu
> wrote:

> I responded just to Jim and not the group.
> But I should add some on the latter comment by Jim, as I didn'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.
> On Apr 9, 2014, at 12:23 PM, Jim Gettys <jg at freedesktop.org> wrote:
> > 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.
> This has been on our todo list for a while, but we haven't implemented it
> yet, and we are looking for feedback before we start coding.
> Our thoughts are as follows:
> Create a "load traffic" that is 3 TCP streams.  3 seems to be a good
> consensus load value for bandwidth testing (its what speedtest.net uses).
> 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.
> 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.
> 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't an
> effective solution for the problem.
​This will work. Doesn'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).

Dave, any other suggestions?
                        - Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20140414/2cf230c9/attachment.html 

More information about the Netalyzr mailing list