Thank you very much for taking the time to write your response and link me to 
the resources. 

I am planning on creating CDFs and have no intention of using average queue 
length as a primary statistic in my research. I am putting much more emphasis 
on end to end delays. That said, I am interested in taking sample measurements 
of instantaneous queue length, but am really looking for any queue-length 
statistics the AQMs may measure.

Best,
Ryan Doyle

p.s. Thank you to everyone else that responded as well. I will be sure to look 
at all of the links, but can't respond to everything individually.

> Date: Wed, 25 Feb 2015 10:24:45 -0800
> From: [email protected]
> To: [email protected]
> CC: [email protected]
> Subject: Re: [aqm] Gathering Queue Length Statistics
> 
> On Wed, Feb 25, 2015 at 9:53 AM, Ryan Doyle <[email protected]> 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
> > [email protected]
> > 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/aqm
                                          
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm

Reply via email to