Täht: The state of fq_codel and sch_cake worldwide [LWN.net]

Dave Täht has put together a summary of the state of fair queuing and the fight against bufferbloat in general.

On a very positive note, while it might seem the negatives are overwhelming in the list above, I’m confident that there are billions of devices for which fq_codel is doing a good job. I’m confident there is a rising tide of clued system administrators and users applying smart queue management in the right places at the right times. There’s more than enough products on the market already that have the right stuff in them to make better networks a matter of merely recognising the problem and applying the fix.

to post comments

Täht: The state of fq_codel and sch_cake worldwide

Posted Apr 25, 2022 18:42 UTC (Mon) by flussence (guest, #85566) [Link] (7 responses)

Still stuck on 2000s-era, IPv4-only, sub-1Mbit-up DSL home internet here. While codel/cake's not perfect, it has measurably improved things and allowed this LAN to function with an ever-increasing number of wifi appliances fighting over a single plastic straw.

I'm extremely grateful to Dave et al. for keeping my ping somehow below 100ms most of the time (and below 1000! The ISP-supplied Netgear junk can't do that and its alleged "QoS" just makes things way worse.)

Täht: The state of fq_codel and sch_cake worldwide

Posted Apr 25, 2022 18:53 UTC (Mon) by Sesse (subscriber, #53779) [Link] (6 responses)

I don't use cake on my Wi-Fi, but for the Internet uplink, it's amazing. I've had issues where I've discovered by accident that I've had rsync upload sessions running for days, without noticing anything at all.

It's a travesty that this isn't available and on-by-default for typical ISP gear.

Täht: The state of fq_codel and sch_cake worldwide

Posted Apr 26, 2022 0:52 UTC (Tue) by mtaht (guest, #11087) [Link]

One of the things I discovered is that a lot of folk actually do have fq_codel on the wifi now, they just don't know it. The mt76 is pretty popular, and here's a stock vs openwrt benchmark: http://blog.cerowrt.org/post/fq-codel-unifi6/

Packet Pacing

Posted Apr 26, 2022 1:04 UTC (Tue) by mtaht (guest, #11087) [Link] (4 responses)

Sess, so far as I remember you were the originator of the need for packet pacing, am I right in that? I'm planning pieces on each subsystem in play...

Packet Pacing

Posted Apr 26, 2022 7:26 UTC (Tue) by Sesse (subscriber, #53779) [Link] (3 responses)

Well, yes and no. I made a series of blog posts in 2012 where I demonstrated (empirically, qualitatively) that packet pacing for video streaming helped reduce loss (and thus rebuffering) significantly. This was in preparation for the video streaming at The Gathering, which I led at the time—now they use Twitch, unfortunately. The idea of paced TCP was not new, however. It had come up a number of times in academia, and there were supposedly Linux patches lying around somewhere, but I never found them and believe they would be outdated anyway. My implementation at the time was using HTB, putting each stream manually in its own bucket. For a hack, it worked beautifully.

You could argue that my postings on this brought the benefits of packet pacing to the attention of others, probably including you and Eric Dumazet, which in turn wrote sch_fq (and I believe implemented fq_codel in Linux?). I cannot say for sure what impact it actually had, though, as it's entirely possible this was just something "everybody" knew about and waited for its time.

Packet Pacing

Posted Apr 26, 2022 15:23 UTC (Tue) by mtaht (guest, #11087) [Link] (2 responses)

Can you point me back to those blogs?

Yes, you convinced me that the relevant 2004 paper (which I can't remember), was wrong. But everyone, including me, thought it was impossible to do, until eric burned a weekend or two (I think he was on a plane flight?) doing it. And then it changed the world. It's still changing it. I'm seeing people doing IW256 w/pacing...

I can't remember when other concepts for packet pacing arrived, like TIMELY and so on, but IMHO packet pacing was the single most important innovation we've had for servers in the last 5+ years, one that keeps giving and giving... the BBR attempt at netflix failed, in part, (I think) because BSD didn't have the infrastructure for highres time....

Packet Pacing

Posted Apr 26, 2022 15:45 UTC (Tue) by Sesse (subscriber, #53779) [Link]

They've expired, like nearly everything else on my blog. I can send you an offline copy if you send me an email.

Packet Pacing

Posted Apr 26, 2022 16:11 UTC (Tue) by mtaht (guest, #11087) [Link]

Ah, the relevant lwn is this: https://lwn.net/Articles/564978/

But to me, it's more of the human story that I'm trying to recall.

Täht: The state of fq_codel and sch_cake worldwide

Posted Apr 26, 2022 1:00 UTC (Tue) by mtaht (guest, #11087) [Link]

Thx jon for posting this. I know bufferbloat and the fixes for it are "old news" within our community, but I'm sure that 80% of the more general public, based on the NTIA broadband statistics I've been able to get - could benefit from applying cake to their existing slow dsl or cable links.

I've been trying to raise awareness within the $70B NTIA broadband upgrade planners to make sure we got better speed AND buffering as part of it, and making some progress there - but the comprehension gap (outside of the WISP community) is vast.

I would very much like to find more help in explaining that we need better bandwidth to more decisionmakers in Washington DC. A "speaker-to-lawyers".

Täht: The state of fq_codel and sch_cake worldwide

Posted Apr 26, 2022 4:56 UTC (Tue) by rsidd (subscriber, #2582) [Link]

About 18 months ago, when our home fibre link was just not working for video calls (frequent drops in audio), I figured (thanks to years of reading LWN) that this may be the problem. The wifi router was from early 2010s. I configured a raspberry pi 4 that we had lying around with openwrt and set it up as the wifi router, and it was fantastic. Subsequently we got another router (TPLink Archer C7) as well as another service provider but keep the old provider and the pi as a backup and it's still chugging along 24/7. There's little measurable bufferbloat on the Archer, stock firmware; I'm not sure what queue algorithm it uses but it's "good enough" that I haven't tried to install openwrt on it (though I bought that model specifically because it's openwrt-compatible).

Anyway, thanks all the bufferbloat fixing folks, the openwrt project, and LWN for spreading the awareness!