From: Jonathan Morton <chromatix99@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] packet mass, ecn, and a fractional count
Date: Fri, 8 May 2015 08:12:18 +0300 [thread overview]
Message-ID: <A319826C-2038-47F4-A9B1-6DDFD3F72870@gmail.com> (raw)
In-Reply-To: <CAA93jw7NmPhbJWmmxssdH_3GynGX4X2wuD9DzaqkFZ7OcFCyew@mail.gmail.com>
> On 8 May, 2015, at 05:32, Dave Taht <dave.taht@gmail.com> wrote:
>
> from observing behaviors with large numbers of flows, fq_codel derived
> algorithms start to struggle to achieve the desired delay, cake
> seemingly less so, and perhaps this is related to collisions also.
>
> A thought would be to use a fractional (fixed point) increment to
> count rather than "1" when larger numbers of flows are present.
Given that cake handles this extreme case better than average already, I’m not particularly concerned about trying to improve it further. Adding set-associative hashing (or red-black trees for perfect isolation, if you prefer) to other FQ qdiscs might be a better idea than fudging codel.
There’s a reasonably straightforward answer for why flow collisions might cause worse AQM behaviour. Assume a situation with a very large number of flows, so adding one more flow doesn’t change the throughput of existing flows much. Now assume that most queues have just one flow assigned, but there are a few with two each. (Ignore the possibility of more, for simplicity.)
The flows assigned to the doubled queues will have half the throughput each, compared to those in single queues. This also means that only half the packets are available for sending congestion signals on, and since codel marks packets on a fixed schedule once it is triggered, each flow will therefore receive only half the congestion signals. *BUT* each flow still gets the same IW, so a doubled queue is twice as full as singles to begin with.
So with perfect flow isolation (and a separate codel per queue), codel’s signalling rate naturally scales with the number of flows. With collisions, that doesn’t happen so reliably; it is at best a sublinear scaling. Without FQ at all, representing the pessimal collisions case, codel has to wait for its signalling rate to grow over time in order to match the number of flows, so it won’t react as quickly to an abruptly imposed load.
- Jonathan Morton
next prev parent reply other threads:[~2015-05-08 5:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 2:32 Dave Taht
2015-05-08 5:12 ` Jonathan Morton [this message]
2015-05-09 16:37 ` Dave Taht
2015-05-09 17:59 ` 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=A319826C-2038-47F4-A9B1-6DDFD3F72870@gmail.com \
--to=chromatix99@gmail.com \
--cc=cake@lists.bufferbloat.net \
--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