[Codel] [Bloat] better testing, linux 3.6.1, cerowrt credits, other stuff

[Dave Taht]

On Tue, Oct 9, 2012 at 9:45 AM, Rick Jones <rick.jones2 at hp.com> wrote:
> Toke -
>
> The script looks reasonable.  Certainly cleaner than any Python I've yet
> written :) I might be a little worried about skew error though (assuming
> I've not mis-read the script and example ini file).  That is why I use the
> "demo mode" of netperf in
> http://www.netperf.org/svn/netperf2/trunk/doc/examples/bloat.sh  though it
> does make the post-processing rather more involved.

In my case I originally had a preference for writing wrappers in lua
(as this is the highest
level language available on the router itself) but rapidly ran into
snags with the overall lack of additional library support and my own
lack of lua expertise. Python is a much easier language to deal with.

That said, there is a start at lua wrappers as well as various
post-processing scripts for things like gnuplot in my deBloat repo on
github. The last time I got serious about getting something more
conventionally publishable is in
https://github.com/dtaht/deBloat/tree/master/test/results

Some stuff that drives gnuplot and does cdf:

https://github.com/dtaht/deBloat/tree/master/test/sfqs

My most current series of ad-hoc tests are at:
https://github.com/dtaht/deBloat/tree/master/test/multiple_codels
and I'm painfully aware of how ad-hoc they are, presently. There's
multiple flooding tests, as well as multiple setup
scripts for htb and hfsc, in there... my primary purpose in this test
series was to determine codel vs ns2_codel characteristics.

Initial results pointed at the ns2_codel derived versions managing a
queue depth better than the linux codel versions...

But: It became obvious fast that long RTT tests were needed, which
I've been trying to establish the infrastructure to do, and the big
flooding tests therein seems to point to a "horizontal standing queue"
issue that I wrote efq_codel to start to resolve, as well as issues
where the queue size is between 0 and 1 and low bandwidths. And that
TCP small queues mess up (improve) the behavior of netperf,
invalidating data not collected with that on....

(as well as tso/gso/ufo/gro really mucking with things, so I generally
turn them off with the debloat tool)

I'm tickled Toke is also dumping stuff into org-mode, which makes
publishing content much easier from emacs.

I will gladly start collecting tests and test results into that repo
if that helps, and grant commit privs. Or start over. There's
tons of cruft in there. Good commit logs, tho...

> I see you are running the TCP_RR test for less time than the
> TCP_STREAM/TCP_MAERTS test.  What do you then do to show the latency without
> the bulk transfer load?

We seem to be converging on this as a decent test, as this is similar
to tests that blogic and myself run.

In my case I had established baseline latency once using TCP_RR, and
didn't feel the need to re-establish the number on every test.

I also have a voip-like test that uses fping on a 10ms interval
instead of TCP_RR. This is useful in wireless especially, as that data
is crazy noisy. I find CDF plots very useful of data like that.

Coherently tracking certain other variables (such as the actual tc
qdisc line and sampling tc -s statistics across an interval) across
tests is also needed.

Another very useful test is TCP_STREAM + TCP_RR while running the
google chrome benchmarks.

Obviously standardization on easily repeatable tests is desperately needed!!

>
> You may find
> http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#Omni-Output-Selection
> in 2.5.0 and 2.6.0 helpful when it comes to getting netperf to emit specific
> measurements.
>
> I was thinking of trying to write a version of bloat.sh in python but before
> I did I wanted to know if python was sufficiently available in most folks
> bufferbloat testing environments.  I figure in "full-featured" *nix systems
> that isn't an issue, but what about in the routers?
>
> happy benchmarking,
>
> rick jones
> here are some links concerning demo mode:
> http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#Using-_002d_002denable_002ddemo
>
> http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#index-g_t_002dD_002c-Global-22
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html