From: George Amanakis <gamanakis@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Dave Taht <dave.taht@gmail.com>, Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] cake vs fqcodel with 1 client, 4 servers
Date: Mon, 04 Dec 2017 22:50:37 -0500 [thread overview]
Message-ID: <1512445837.3088.2.camel@gmail.com> (raw)
In-Reply-To: <CAJq5cE0t40Tq+97buPfQqJM_mz_P1jB+gNcRrhDFFLWobjhncA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]
Of course Jonathan is right. Furthermore adjusting the failsafe ingress
to the number of flows would result in an extremely jerky behaviour
regarding the bandwidth.
I redid the test with net.ipv4.tcp_ecn=1 and I am attaching the
results.
On Tue, 2017-12-05 at 03:38 +0200, Jonathan Morton wrote:
> Ingress mode works by counting dropped packets, not only delivered
> packets, against the shaped limit. When there's a large number of
> non-ECN flows and a low BDP per flow, a lot of packets are dropped to
> try and keep the intra-flow latency in line. So the goodput tends to
> decrease when the flow count increases, but this is necessary to
> control latency.
> The modified failsafe ensures that at most a third of the total
> bandwidth will "go missing" this way. Previously, as much as three-
> quarters could. At that threshold, Cake stops counting dropped
> packets, trading a reduction in latency control for maintaining
> reasonable goodput. There is no more sophisticated heuristic that I
> can think of to achieve ingress mode's goals.
> However, it might be worth revisiting an old question once raised
> over fq_codel's use of a fixed set of Codel parameters regardless of
> active flow count. It was then argued that the delay target wasn't
> dependent on the flow count.
> But when the flow count is high, a fixed delay target plus the
> baseline latency might end up requiring a lower BDP than the sender
> is able to select as a congestion window (typical TCPs have a hard
> lower limit of 4x MSS). In that case, currently packets are being
> dropped for no effect on send rate. This wouldn't matter with ECN,
> of course.
> So a better fix might be to adjust the target latency according to
> the number of active bulk flows. Fortunately for performance, this
> should be a multiply, not a division.
> - Jonathan Morton
[-- Attachment #2: rrulbe_11_4_4servers_1client_10mbit_2mbit_cake_htbfqcodel.tgz --]
[-- Type: application/x-compressed-tar, Size: 3275211 bytes --]
[-- Attachment #3: download_per_flow_cake_ing_ecn.png --]
[-- Type: image/png, Size: 60804 bytes --]
next prev parent reply other threads:[~2017-12-05 3:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-04 22:30 Georgios Amanakis
2017-12-05 0:06 ` Dave Taht
2017-12-05 1:13 ` Georgios Amanakis
2017-12-05 1:38 ` Jonathan Morton
2017-12-05 3:50 ` George Amanakis [this message]
2017-12-05 4:48 ` Jonathan Morton
2017-12-05 21:15 ` Dave Taht
2017-12-05 21:26 ` Georgios Amanakis
2017-12-05 22:39 ` xnor
2017-12-06 9:37 ` Jonathan Morton
2017-12-06 19:32 ` xnor
[not found] ` <CAJq5cE3MUfCuV_=GXAAOwvAXxee_dcJBaUkRVAEEWwyT5m7gAw@mail.gmail.com>
2017-12-07 1:59 ` Jonathan Morton
2017-12-07 2:27 ` Jonathan Morton
2017-12-07 2:30 ` George Amanakis
2017-12-07 2:58 ` George Amanakis
2017-12-07 3:04 ` Jonathan Morton
2017-12-07 3:08 ` Georgios Amanakis
2017-12-07 7:08 ` Jonathan Morton
2017-12-07 8:21 ` Jonathan Morton
2017-12-07 8:51 ` Kevin Darbyshire-Bryant
2017-12-07 9:03 ` Jonathan Morton
2017-12-07 13:17 ` Georgios Amanakis
2017-12-07 22:12 ` xnor
2017-12-07 22:34 ` Georgios Amanakis
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=1512445837.3088.2.camel@gmail.com \
--to=gamanakis@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=dave.taht@gmail.com \
/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