Re: [aqm] Gathering Queue Length Statistics

[Jesper Dangaard Brouer <[e-mail]>]

Hi Ryan,

Follow Daniel's advice, just use netperf-wrapper. I wrote an easy setup
guide for netperf-wrapper here:
 http://netoptimizer.blogspot.co.nz/2014/09/mini-tutorial-for-netperf-wrapper-setup.html

You will love the GUI mode:
 netperf-wrapper --gui

Most powerful thing in the GUI is that you can easy "load" result sets
on-top-of each-other, which allow you to easy compare. And you can save
these as PNG and add them easily to your report :-)

And the secret to (solving) bufferbloat is not the queue length, but
the time-spend in the queue, which is actually easier to derive ;-) 

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer



On Wed, 25 Feb 2015 11:16:40 -0800 Daniel Havey <[e-mail]> wrote:

> 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
>  
> 
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm




-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer