[Netalyzr] Error reported on test...

Nicholas Weaver nweaver at ICSI.Berkeley.EDU
Mon Apr 14 09:03:03 PDT 2014

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.

But overall we'd appreciate any thoughts others on this list would have in how to conduct a buffer-measurement experiment that is better than our current UDP-only test.

Nicholas Weaver                  it is a tale, told by an idiot,
nweaver at icsi.berkeley.edu                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20140414/3ae3ec16/attachment.bin 

More information about the Netalyzr mailing list