From: Jonathan Morton <chromatix99@gmail.com>
To: Michael Yartys <michael.yartys@protonmail.com>
Cc: "bloat@lists.bufferbloat.net" <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Phoronix: Linux 5.9 to allow FQ_PIE as default
Date: Thu, 16 Jul 2020 03:37:30 +0300 [thread overview]
Message-ID: <156954CF-BCBC-4B0C-9C42-A2A6F2450185@gmail.com> (raw)
In-Reply-To: <Zci4SOZKoI_pTbc2MzCFmWJWI_bWMc852HrxDScgGaLOyLyMQqRhwUCJDTQL8Ayeml1EZkccfqjETFOQ_ptBHA2mndf_C0HOvWw7E4ylPLI=@protonmail.com>
> On 16 Jul, 2020, at 12:58 am, Michael Yartys via Bloat <bloat@lists.bufferbloat.net> wrote:
>
> Are there any major differences between fq_codel and fq_pie in terms of their performance?
I think some tests were run some time ago which showed significantly better behaviour by fq_codel than fq_pie. In particular, the latter used only a single AQM instead of an independent one for each flow. I'm not sure whether it's been changed since then.
The only advantage I can see for PIE over Codel is, possibly, a reduction of system load for use of the AQM. But fq_codel is already pretty efficient so that would be an edge case.
In any case, it is already possible to chose any qdisc you like (with default parameters) as the default qdisc. I'm really not sure what the fuss is about.
> And how does the improved fq_codel called cobalt, which is used in cake, stack up?
COBALT has some modifications to basic Codel which, I think, could profitably be backported into fq_codel. It also has a particular extra mode, based on BLUE, for dealing with unresponsive traffic (that continued to build queue even after lots of ECN signalling and/or Cdel-scheduled packet drops). It is the latter which inspired the name.
For the other major functional component of fq_codel, Cake also has a set-associative hash function for allocating flows into queues, which substantially reduces the probability of hash collisions in most cases.
- Jonathan Morton
next prev parent reply other threads:[~2020-07-16 0:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-15 21:58 Michael Yartys
2020-07-16 0:37 ` Jonathan Morton [this message]
2020-07-16 18:07 ` Toke Høiland-Jørgensen
2020-07-17 1:16 ` [Bloat] fq_pie in FreeBSD... " grenville armitage
-- strict thread matches above, loose matches on Subject: below --
2020-07-15 11:56 [Bloat] " Rich Brown
2020-07-15 13:02 ` Toke Høiland-Jørgensen
2020-07-15 15:22 ` Rich Brown
2020-07-16 17:50 ` Toke Høiland-Jørgensen
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/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=156954CF-BCBC-4B0C-9C42-A2A6F2450185@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=michael.yartys@protonmail.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