to shorten the painful duration of the test, you can tell the chrome benchmark merely to repeat 3 times each rather than 10.
I have been collecting statistics on the behavior of the 3.7.5-2 version of cerowrt, and perhaps y'all out there can help. I've been doing four repeatable tests.I feed the attached file into the chrome web page benchmark and run it 4 times:1) No other load on the system2) while running a single up and single down netperf stream to icei.org (on the east coast)3) then while still loaded, after turning on simple_qos.sh, set for ~85% of the rated up/down bandwidth...4) then killing the load, and keeping simple_qos enabled.I export each detailed (you have to select it) .csv output from that benchmark to a file.I do it against a bidirectional stream - one each of
netperf -l 6000 -4 -H icei.org -t TCP_MAERTS &netperf -l 6000 -4 -H icei.org -t TCP_STREAM &(if you have ipv6, more power to you, kill the -4. )then starting the web tests 10-20 seconds later. It's interesting to watch cero's bandwidth graphs while doing this.There are netperf servers setup on the east (icei.org) and west coast (snapon.lab.bufferbloat.net) and a few other places. It would be sane to setup your own someplace you control (from netperf's svn compiled with --enable-demo), as it helps to have a shorter RTT to truly load up the link. You can also run the rrul test (preferably for 5 minutes or more because this test idea KILLs web page load times) to get a heavier load and more graphs.If you are up to trying this test series, please let me know, send along the details of your setup, and the 4 csv files, and perhaps your data will show up in an upcoming paper.The chrome web page benchmark can be had at:And requires you fire off chrome with --enable-benchmarkingYou can use the version of netperf on cerowrt to generate the load if you like, but rrul doesn't run on that. Latest version of rrul is at https://github.com/tohojo/netperf-wrapper--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html