[Netalyzr] Error reported on test...

[Jim Gettys]

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