[Cake] fiddling with variable bandwidth (emulating wifi rate control) with cake and flent

[Dave Taht <dave.taht@gmail.com>]

After collecting some good traces of the state of the art of wifi
under varying conditions, I set about to use cake to model the traces'
changes in available bandwidth, and then... after dealing with all the
horrific noise... just set about creating repeatable models. In this
case, this is running tests for 60 seconds, on a link that has a 16
and 4 mbit variance twice, that is also 1Gbit down.

http://snapon.lab.bufferbloat.net/~d/varying_bandwidth.tgz

The wifi dataset I think  I will have to polish a little to get folk
to make sense of it.
(I put some of it out already)

Any feedback on a better set of standard models for looking at how
rate control actually varies in the real world, welcomed!

Here is the basic comparison
I wanted to see, with cake fq, and cake "flowblind", which is
basically cake's version of a pure codel.

flent --gui tcp_upload*.gz qdisc-stats-*tcp_upload*.gz

using the new (under development) qdisc buffering sampler in flent.

There are multiple bugs left to conquer but...

0) It is so nice to see latency stay so reasonably flat when the
bandwidth changes - the flowblind results were pretty nice to see.

http://snapon.lab.bufferbloat.net/~d/vband/qdisc_tcp_upload_16_4mbit_flowblind.svg

http://snapon.lab.bufferbloat.net/~d/vband/tcp_upload_16_4mbit_flowblind.svg

1) cake can't possibly be reporting the right number of dropped
packets or bytes, or something. the numbers do not add up. Overflow?

http://snapon.lab.bufferbloat.net/~d/vband/prettysureidonttrustthesestats.png

Speaking of overflow and requeues, what do those terms mean, exactly,
in cake, codels, fq_codel, etc, mental context?

2) sqm-scripts has changed dramatically since I last used it. What I
used to use on debian was:

IFACE=eth0 QDISC=codel UPLINK=x DOWNLINK=y ./simplest.qos

what do I now?

3) at least on the box I was debugging on, the tc filter part on
ingress (3.16) was failing.... which is why I tested 1gbit down. :(

4) flent needs to be able to sample at faster rates than it does.
(theres a bug filed on this). I'd like to be able to see in detail the
roughly 3 second period where
the latency goes up when the bandwidth goes down.

5) the qdisc stats code needs to work on openwrt (can't, no fractional sleep)
(I keep threatening to rewrite this in c)

6) bugs in the qdisc_stats plots, from sampling, to code output, to
the last 2 plots,
make all this data unworthy of trust - but it is very pleasant feeling...

when the experiment lines up with your expectations...

...even if the experiment is possibly wrong.

I hope the dumb script is pretty grokkable.

-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast