[Cake] Fwd: longer rtt codel/cake testing with remote servers

[Dave Taht]

This email, also:

---------- Forwarded message ----------
From: Dave Taht <dave.taht at gmail.com>
Date: Wed, Dec 23, 2015 at 6:30 AM
Subject: Re: longer rtt codel/cake testing with remote servers
To: cake at lists.bufferbloat.net


also of good use is the new tc_iterate.sh and tc_iterate.c code which
lets you track qdisc queue lengths, number of packets, outstanding
bytes, and drops, on your machine AND on the remote router(s).

If you want deeper insight into the actual queuing behavior, this is
the code for it! Traditionally most aqm folk looked more at queue
depth than at measured throughput....

There is a flent-flent-tc_iterate package for openwrt in ceropackages
has a high precision version in c

(you should use it on your own machine too - cd into your flent/misc
dir and "make install" in there)

after getting a root ssh key on the router, you can track the remote
queue length statistic via:

S=flent-london.bufferbloat.net

flent -l 60 -H $S -x -t noecn_pfifo_100mbit-wtf\
        --test-parameter qdisc_stats_hosts=root at your_router,root at your_router\
        --test-parameter
qdisc_stats_interfaces=the_interface,the_inbound_interface\

tc_iterate is actually capable of getting snapshots of the queue length down
below the 10ms level but flent is not.

Last week's cake at 2mbit/384k

http://snapon.cs.kau.se/~d/384k/batch-2015-12-21T140643/voip-rrul/384Kbit-01/cake_bad_backlog.png

vs my "bcake" variant:

http://snapon.cs.kau.se/~d/384k/batch-2015-12-21T140643/voip-rrul/384Kbit-01/bcake_saner_backlog.png

be comforted at what happens to pie at these speeds, however:

http://snapon.cs.kau.se/~d/384k/batch-2015-12-21T140643/voip-rrul/384Kbit-01/becomfortedathowbadpieisthough.png

There is perhaps insight to be gleaned by looking at drop patterns and
so on, and the above dataset can be had at:

https://kau.toke.dk/experiments/cake/batch-2015-12-21T140643.tar.gz

A variety of RTTs and speeds are in:

https://kau.toke.dk/experiments/cake/batch-2015-12-10T172606.tar.gz

On Wed, Dec 23, 2015 at 3:08 PM, Dave Taht <dave.taht at gmail.com> wrote:
> I have long maintained a set of servers suitable for testing at a
> range of RTTs, but did not publish them because I'd had no desire to
> maintain them personally [1] for wide use, they are "in the cloud", so
> I do not trust their network behavior not much past 100mbit,  I
> frequently used shapers on them merely to get interesting bandwidths
> at varieties of RTTS, and they cost 10 bucks a month each which I have
> sometimes needed for food.
>
> If people truly want to get a feel for how to modify codel without a
> lab handy, these boxes would be good to test against - and have long
> term flent data sets against, at typical home bandwidths, from your
> home. The most basic multi-rtt tests are the rtt_fair tests, but the
> rrul and tcp_upload/dlownload tests are also good for seeing the
> interactions on long rtts...
>
> and it's always good to do occasionally do a test to, like, tokoyo and
> wonder why tcp even works at all.
>
> I would like to find flent  servers in finland, russia, australia/nz
> spain, and elsewhere in the eu. [1]
>
> These machines are active subdomains of bufferbloat.net.
>
> netperf-west: defunct (was snapon)
> netperf-east I do not know where this is actually
> netperf-eu - this is toke's server somewhere
>
> flent-atlanta # georgia
> flent-dallas  # texas
> flent-freemont  # california
> flent-london  # england - this is also taht.net, at the moment
> flent-newark # new jersey
> flent-tokyo # japan
>
> [1] maintainer wanted. Also could use d-itg set up on them. Securely.
> I also do not remember if they all have ecn enabled by default or not.
> Several run the fq qdisc. I am in  the progress of migrating several
> to kvm from xen.
>
> I would argue for consistently using sch_fq on these servers with ecn
> always enabled. I will check today.
>
>
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi