debian finally adopts fq_codel. ---------- Forwarded message --------- From: Noah Meyerhans <[email protected]> Date: Sun, Jan 2, 2022 at 9:30 PM Subject: Re: fq_codel in debian To: Dave Taht <[email protected]>
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 <[email protected]> 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 <[email protected]> wrote: > > > > > > > > On Thu, Jan 21, 2021 at 4:22 PM Noah Meyerhans <[email protected]> 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 > > > > > > > > [email protected] <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 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
