[Bloat] Fwd: fq_codel in debian

Mon Jan 3 01:43:55 EST 2022

debian finally adopts fq_codel.

---------- Forwarded message ---------
From: Noah Meyerhans <frodo at morgul.net>
Date: Sun, Jan 2, 2022 at 9:30 PM
Subject: Re: fq_codel in debian
To: Dave Taht <dave.taht at gmail.com>

The change was merged; Barring any regressions or the like, the fq_codel
should be the default for future major releases of Debian.

Happy New Year.

noah

On Wed, Nov 17, 2021 at 09:25:43AM -0800, Dave Taht wrote:
> Well, I hope it makes it in before then. But happy to hear it's on it's way!
>
> I've been working at the us government policy level lately. Attached
> is a draft report we're working on in BITAG. I'd like to find some way
> to improve it, with an axe, if you are interested in a quick review.
>
> On Wed, Nov 17, 2021 at 9:20 AM Noah Meyerhans <frodo at morgul.net> wrote:
> >
> > Sadly not in time for the Debian 11 release.  So, we've got to wait
> > until Debian 12, which is likely going to be released mid 2023.
> >
> > On Mon, Nov 15, 2021 at 10:11:34AM -0800, Dave Taht wrote:
> > > you ever get anywhere?
> > >
> > > On Sat, Jan 23, 2021 at 2:33 PM Dave Taht <dave.taht at gmail.com> wrote:
> > > >
> > > > On Thu, Jan 21, 2021 at 4:22 PM Noah Meyerhans <frodo at morgul.net> wrote:
> > > > >
> > > > > On Wed, Jan 20, 2021 at 10:47:42PM -0800, Dave Taht wrote:
> > > > > > I'm not on that debian list, but I'm glad to hear of your patch. In
> > > > > > particular, on the armbian releases for a zillion low end arms,
> > > > > > fq_codel is often not even built, although made the default by
> > > > > > systemd, so my hope is your patch will fix that, and pfifo_fast will
> > > > > > continue to die the death it deserves.
> > > > >
> > > > > It may help with these, although it's not a given since they all provide
> > > > > their own kernels with their own configuration.  It's probably still
> > > > > necessary to chase down the maintainers and make sure they do the right
> > > > > thing.
> > > >
> > > > Yes, I figured we should make that effort, but perhaps after your patch
> > > > goes through it would be easier. I am a big proponent of testing,
> > > > and some of those low end arches might not have a fast onboard
> > > > clock for timestamps.
> > > >
> > > > >
> > > > > > I wish cake wasn't so heavyweight, it pretty much solved everything
> > > > > > even slightly wrong with fq_codel.
> > > > >
> > > > > It's been suggested that we also consider pie, which can be enabled as a
> > > > > default qdisc in Linux.  Do you have a sense of how suitable it would be
> > > > > versus fq_codel and cake?
> > > >
> > > > How long an answer do you want? :) I can write something for wider consumption
> > > >
> > > > but I can go on record with this...
> > > >
> > > > as one of the authors of codel/fq_codel I could be considered biased... except
> > > > that I also worked pretty hard on pie and several other variants, like
> > > > sfqred. fq_codel
> > > > swept them all off the map and I'm pretty proud of the one in wifi
> > > > also ( https://lwn.net/Articles/705884/ ).
> > > >
> > > > The newer "Cake" addressed a few new things that the sqm subsystem we
> > > > built around fq-codel really beautifully,
> > > > but it's too slow to use as a default on higher speed links. fq_codel
> > > > is massively better than
> > > > pfifo_fast in all respects.
> > > >
> > > > My principal reason for working on the alternative ideas in pie was
> > > > that I was afraid
> > > > that in some future day someone would find an attack on codel, and I
> > > > preferred a diverse
> > > > ecosystem. Also I viewed pie as slightly easier to implement in pure
> > > > hw as it was closer
> > > > to red in design, and O(1). In software or firmware the difference in
> > > > cpu cost is immeasurable. Also
> > > > I wanted to produce fair, and comprehensive benchmarks. Which we did.
> > > > And the pie makers
> > > > still haven't.
> > > >
> > > > I have stated elsewhere that pie is a better "single queue" AQM than codel is.
> > > > It is less gentle, and more responsive to overload.
> > > > codel is kinder and gentler but: generally achieves queue lengths much shorter
> > > > than pie can. Pie is also kind of unstable on jittery links, like
> > > > wifi. Adding fq to codel
> > > > was a marriage made in heaven, it lets codel be gentle everywhere needed, and
> > > > fq prioritize sparser flows.
> > > >
> > > > fq, or fq-anything is VASTLY better than any single queue aqm can be.
> > > > A single unresponsive sender
> > > > can completely disable pfifo-fast, pie, codel, red or what have you,
> > > > while fq or fq-anything
> > > > just shrugs it off. A lot of good things that are also good on cpu in
> > > > this sadly common case,
> > > > is the bulk drop facility in fq-codel. fq-codel and fq-pie achieve
> > > > near perfect utilization
> > > > for multiple flows, which a single queue aqm cannot.
> > > >
> > > > As for fq-pie vs fq-codel, the authors of fq-pie maintain it is better
> > > > for DASH traffic,
> > > > and I maintain that fq-codel is better for all forms of other traffic.
> > > > There's a couple
> > > > competing papers on this. Codel's head drop (+bql) is very superior to
> > > > tail drop in every
> > > > circumstance, you (almost) never, for example, get a TCP RTO, and shorter
> > > > queues make the impact of a hash collission much less.
> > > >
> > > > (that said, cake uses a set associative rather than direct mapped hash, can
> > > > do per host/per flow fq even through nat, has a native shaper that works
> > > > to defeat an bad htb shaper upstream of it, does dscp classification
> > > > and ack-filtering,
> > > > and can be configured with a single line of tc.) If we could somehow have
> > > > achieved those goals without eating at least 3x more cpu than fq_codel
> > > > does... I'd have
> > > > loved to have made it the linux default... but we didn't.
> > > >
> > > > We wrote a couple good papers on cake, and it's gradually becoming the
> > > > default sqm implementation for many a router OS.
> > > >
> > > > Anyway...
> > > >
> > > > It's taken 8 years for fq-pie to become even slightly competetive with
> > > > fq_codel, with
> > > > continuous refinement, where fq_codel is stable, well tested, and determistic in
> > > > action rather than random, and heavily deployed since 2012.
> > > >
> > > > OFF THE RECORD:
> > > >
> > > > The pie folk tend to be really shrill sometimes, and in general I find
> > > > their papers
> > > > rather weak and too narrowly focused in scope. They almost never publish
> > > > source code to their benchmarks, either. And: There's a subcontingent
> > > > ranting about L4S vs SCE which is one of the saddest poltical fights I've
> > > > ever been in ni the ietf. But I digress.
> > > >
> > > > >
> > > > > > have a gratuitous yet funny link.
> > > > > >
> > > > > > https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/
> > > > >
> > > > > Thanks, that was fun!
> > > >
> > > > Glad I could share. Pass it on. I only give one talk a year, and
> > > > post-covid, I don't think
> > > > I'll ever be able "push packets" like that around again.
> > > >
> > > > > >
> > > > > > happy new year.
> > > > > >
> > > > >
> > > > > And same to you.
> > > > >
> > > > > noah
> > > > >
> > > >
> > > >
> > > > --
> > > > "For a successful technology, reality must take precedence over public
> > > > relations, for Mother Nature cannot be fooled" - Richard Feynman
> > > >
> > > > dave at taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729
> > >
> > >
> > >
>
>
>

-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC