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 <[email protected]> wrote: Subject: Re: [aqm] Gathering Queue Length Statistics To: "Ryan Doyle" <[email protected]> Cc: "[email protected]" <[email protected]> Date: Wednesday, February 25, 2015, 10:24 AM 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
