[Bloat] [Cerowrt-devel] fq_codel is SEVEN years old today...

Tue May 14 18:05:32 EDT 2019

I wonder if an interesting project to design and pitch for CrowdSupply to fund would be a little board that packages sch_cake or something in the minimal hardware package that could sit between a 1 GigE symmetric port and either an asymmetric GigE or a symmetric 1 GigE connection into a 10 GigE switch.
The key point is that it needs to support wire-rate forwarding with small packets of Gigabit throughput. Ideally, it also supports a dnsmasq NAT and wireguard optionally.

I know a Celeron with 2 GB of RAM can easily do it (because that is what I use). We know (well that's what you guys tell me) that the dinky MIPS processors are underpowered to handle sch_cake at such packet rates. The Linksys and Netgear and TP-link guys seem to see no market at all for any such thing. But I see it as a useful jellybean device if it could be cheap and simple.

Could maybe design, produce, and sell this for $100? No one else seems to want to make such a thing. I could just barely design and implement the board and get it made, but to be honest I'm better at spec'ing and prototyping than making manufacturable hardware designs. I suspect I could find someone to do the PCB design, layout and parts selection as a project.

The idea for this hardware "product" is to decouple this buffer management from the WiFi compatibility and driver mess, and make it easy for people, maybe to demonstrate that it could be a great product. Forget designing the packaging, negotiating a sales channel, etc. Just do what is needed to make a few thousand for the CrowdSupply market.

Thoughts?

-----Original Message-----
From: "David P. Reed" <dpreed at deepplum.com>
Sent: Tuesday, May 14, 2019 2:38pm
To: "Valdis Klētnieks" <valdis.kletnieks at vt.edu>
Cc: "Rich Brown" <richb.hanover at gmail.com>, "cerowrt-devel" <cerowrt-devel at lists.bufferbloat.net>, "bloat" <bloat at lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] fq_codel is SEVEN years old today...

Well, of all the devices in my house (maybe 100), only the router attached to the cable modem (which is a 2x GigE Intel Linux board based on Fedora 29 server with sch_cake configured) is running fq_codel. And setting that up was a labor of love. But it works a charm for my asymmetric Gigabit cable service.

My home's backbone is 10 GigE fiber, so I suppose fq_codel would be helpful for devices that run on 1 GigE subnets like my 2 802.11ac access points when talking to my NAS's.
However, the 802.11ac access point high speed functionality doesn't seem to be supportable by LEDE. So what can I do? 

I suppose I could stick some little custom Intel Linux 2x GigE devices between access points and the 10 GigE backbone, and put fq_codel in there.

My point is, to get the primary benefit of bufferbloat reduction, one has to stick little Linux boxes everywhere, because fq_codel is not supported except via DIY hacking.

And indeed, 10 GigE->1 GigE buffering does affect storage access latency in bad ways.

We see the same problem in datacenter networks that have excessive buffering - a famous switch company backed by Andy Bechtolsheim is really problematic because they claim building up huge buffers is a "feature" not a bug.
-----Original Message-----
From: "Valdis Klētnieks" <valdis.kletnieks at vt.edu>
Sent: Tuesday, May 14, 2019 1:57pm
To: "Rich Brown" <richb.hanover at gmail.com>
Cc: "cerowrt-devel" <cerowrt-devel at lists.bufferbloat.net>, "bloat" <bloat at lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] fq_codel is SEVEN years old today...

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
On Tue, 14 May 2019 08:16:06 -0400, Rich Brown said:

> Let's all pat ourselves on the back for this good work!

Do we have an estimate of what percent of connected devices
are actually using fq_codel or other modern anti-bloat methods?
I'm reasonably sure my TV, my PS3, and my PS4 are still
behind the curve.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20190514/ce617ff8/attachment-0002.html>