From: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: "Dave Täht" <dave@taht.net>, "Cake List" <cake@lists.bufferbloat.net>
Subject: Re: [Cake] [Fwd: Re: RHODIUM - nuking blue (for testing)]
Date: Thu, 7 Dec 2017 09:08:49 +0000 [thread overview]
Message-ID: <20897949-7EBC-42C9-ABCA-44D7D5CDCE01@darbyshire-bryant.me.uk> (raw)
In-Reply-To: <CAJq5cE1OdOVjGL_CpyEg_PoXV5bk6WjgkRuNxA3rtaXXnNa=OQ@mail.gmail.com>
> On 7 Dec 2017, at 02:19, Jonathan Morton <chromatix99@gmail.com> wrote:
>
> > It would be nice to have a test showing blue being useful.
>
> To do that, you would need to have a saturating unresponsive load, such as a UDP flood, which drives Cake's queue to the memory limit. Even then, I suspect you wouldn't see much difference in the traffic stats, but there might be a CPU advantage since the hard-drop path would be exercised less.
This reminds me of a recent discovery/mystery related to ECN, acks, Qnap NAS box and Microsoft onedrive. I sent a packet dump to Dave for his thoughts. But in summary, NAS box does file copies to MS Onedrive folder/s across a 19Mbit bit cake controlled egress link (ingress is 70Mbit ingress cake controlled, no large contending bandwidth). Upload uses 4 streams and I saw around 25 packet drops per second/per flow by cake to keep things under control. What I found curious in combination with the ‘ack drop’ thread is that MS appears to send an ack per packet, not even ack per every 2nd packet.
I wondered if enabling ECN would improve things (ie mark instead of drop), it didn’t. Instead cake memory usage goes up to configured limit and it regards the flows as uncontrolled. My view is that cake handles this particular abuse very well, latency through the link isn’t really affected, though the ‘peak, avg & sparse delay’ figures are remarkably high (peak around 1.6Seconds! but then getting 4MB of data over 19Mbit is going to take time, unless you drop the packets due to unresponsive)
Curious.
Kevin
next prev parent reply other threads:[~2017-12-07 9:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1512525519.21401.11.camel@gmail.com>
2017-12-06 2:01 ` Georgios Amanakis
[not found] ` <CAJq5cE3rqrHSCgdU9rw3dXrW8A7sNTuFtxEXddPHh9Rmqzh3qg@mail.gmail.com>
[not found] ` <CAJq5cE2rm0jbEyCMWrYcXqkqL=aXtd2jhkRzowvRx_usLo+-sQ@mail.gmail.com>
2017-12-06 2:09 ` Jonathan Morton
2017-12-06 21:08 ` Dave Taht
2017-12-06 21:17 ` Georgios Amanakis
2017-12-06 21:21 ` Georgios Amanakis
2017-12-06 21:43 ` Georgios Amanakis
2017-12-06 22:35 ` Luis E. Garcia
2017-12-07 1:15 ` Dave Taht
2017-12-07 8:40 ` Pete Heist
2017-12-07 2:19 ` Jonathan Morton
2017-12-07 9:08 ` Kevin Darbyshire-Bryant [this message]
2017-12-07 9:16 ` Jonathan Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20897949-7EBC-42C9-ABCA-44D7D5CDCE01@darbyshire-bryant.me.uk \
--to=kevin@darbyshire-bryant.me.uk \
--cc=cake@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=dave@taht.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox