Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
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 --]

  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