Re: [Cake] second system syndrome

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

On Wed, Dec 23, 2015 at 2:06 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 23 Dec, 2015, at 14:41, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> Are you actually testing your codel changes at longer RTTs?
>
> The latest set has, so far, only been tested on an ordinary Internet link.  It produced an immediately noticeable improvement on ingress there, implying that it’s controlling the upstream queue better.
>
> I’m reasonably confident, however, that it’ll stand up to more varied tests as well.  Fundamentally, it returns to the standard Codel trigger mechanism under most circumstances, since that’s been shown to work well.
>
> It also adds a new wrinkle that only appears when the queue is growing very quickly, to trigger the signalling early when it’s abundantly clear that it *will* inevitably trigger later.  I think this will particularly help cope with TCP slow-start or, on a long-RTT path, with RTT-independent TCPs like CUBIC.
>
> Feel free to run your own tests.  I need to sleep.

The testbed is closed for the holidays, and unless toke logs in, lab
testing will not resume until jan 12th. I might, today do a bit on
your latest code, but I am mostly trying to finish the server moves
before taking off for the holidays myself.

It does strike me that you are perhaps overly concerned about slow
start behavior in general.

The load spike exhibited by many of the "rrul" derived tests in the
flent suite are artifacts of the side effects of starting too many
flows at almost exactly the same time. In a normal congested scenario
we would have a saturated link, with stablized codel values with a set
of flows, and short flows coming and going on a regular basis.

We have a few tests that do something saner, like the tcp_2up_delay test,
as well as the web tests, which takes some setup to have running, as
does the rrul_voip test.

Some of the lab results are colored by using an older version of
netperf which does not restart the udp flows after a loss for 250ms -
the voip tests are a better indicator of what loss is like for
isochronous flows, and honestly I wish we used isochronous rather than
ping based tests for all of the rrul stuff.

Certainly there are issues with doing the massive overload tests like
the 50down one, notably with admission control (some tests simply
can't start with that much congestion), and with ecn (ecn clogs up the
pipe way worse and makes it even harder to start a new flow as the
various aqm algorithms scale up to a higher "drop" rate than desirable
 - ecn has mass, I've always said)

I put out the list of existing flent servers earlier (which are a bit
underconfigured), in the hope that more would do measurements rather
than go by feel - and also of use are the new queue depth things which
toke and I put into flent over the last month or so.

>  - Jonathan Morton