Re: [aqm] Gathering Queue Length Statistics

[Daniel Havey <[e-mail]>]

Jeez Dave, don't scare the kid!  :^)  He's only an undergrad!

Look Ryan, Dave really does have your best interest at heart and that is why he wants you to use CDFs instead of averages.  And he is right, I think you should use CDFs also.  In fact, save yourself a pile of repetitve work and just use Toke's tools.  They will produce better results and require less work from you :)

Trust me on this.  I have done both and Toke's tools are waaaaay better and easier than anything you (or I) will come up with.  Install Toke's tools and then you will have a cornucopia of awesome and repeatable results that you can just plug in to your final paper.  Go for it :^)

thanxs ;^)
...Daniel


--------------------------------------------
On Wed, 2/25/15, Dave Taht <[e-mail]> wrote:

 Subject: Re: [aqm] Gathering Queue Length Statistics
 To: "Ryan Doyle" <[e-mail]>
 Cc: "[e-mail]" <[e-mail]>
 Date: Wednesday, February 25, 2015, 10:24 AM
 
 On Wed, Feb 25, 2015 at
 9:53 AM, Ryan Doyle <[e-mail]>
 wrote:
 > Hello,
 >
 > I am a senior undergraduate student at the
 University of North Carolina at
 > Chapel
 Hill and am studying the effectiveness of AQMs. I have set
 up a lab
 > network and plan on running
 different sets of experiments with different
 > AQMs. My router machines are running Linux
 kernel version 3.16.0.
 >
 > I am using the fq_codel, codel, and pie
 qdiscs for my research and am
 > wondering
 if there is a way to collect statistics regarding the
 average
 > queue length since a qdisc was
 enabled? I have looked at tc's "-s" flag
 for
 > statistics, but they show nothing
 about queue length and I have been unable
 > to find anything else that might help me
 get queue length statistics.
 
 Oh, god. I am getting incredibly sensitive
 about average queue length,
 and I realize
 that that is not what you meant. But since not enough
 people have seemingly read this or any of the
 related materials, here
 it is again.
 
 http://www.pollere.net/Pdfdocs/QrantJul06.pdf
 
 And I of course always
 recommend van´s talk on the fountain model for
 thinking about closed loop servo systems.
 
 http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos
 
 In the bufferbloat
 project...
 
 We have
 developed many tools that drive aqms hard, see
 netperf-wrapper
 on github for that, which
 measures e2e delay without requiring any
 tools on the routers inbetween. e2e delay in my
 mind is way more
 important than average
 queue length. And you can derive the queue
 length(s) from tcp timestamps in those
 netperf-wrapper tests, from
 additional
 packet captures, if you must.
 
 If you absolutely MUST derive average queue
 length from the box, you
 can poll the
 interface frequently with tc -s qdisc show as well as
 with ifconfig- and parse out the number of
 packets and the number of
 bytes. But you can
 do MUCH more valid statistical analysis than that,
 with that sort of data set - and if you poll
 too frequently you will
 heisenbug your
 tests, as those data collection calls take locks that
 interfere with the path. and we have all sorts
 of advice about traps
 for the unwary
 here:
 
 http://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel
 
 
 Please use
 things like CDFs to see the range of delays, rather than
 averages. It is what happens at above 90% of
 the range that makes
 bufferbloat maddening
 to ordinary users.
 
 I am
 summarily rejecting any papers that I review that report
 average
 queue length as if it meant
 anything. And for a few other reasons. You
 have been warned. I really lost my temper after
 the last paper I
 reviewed last weekend and
 the resulting flamage is all over the bloat
 list and codel lists, and starts here:
 
 https://lists.bufferbloat.net/pipermail/codel/2015-February/000872.html
 
 
 > Best,
 > Ryan Doyle
 >
 >
 _______________________________________________
 > aqm mailing list
 > [e-mail]
 > https://www.ietf.org/mailman/listinfo/aqm
 >
 
 
 
 -- 
 Dave
 Täht
 Let's make wifi fast, less jittery
 and reliable again!
 
 https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
 
 _______________________________________________
 aqm mailing list
 [e-mail]
 https://www.ietf.org/mailman/listinfo/aqm