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