The problem is that ISP provided kit is built to a price, so will tend to have a more aenemic processor. Shaping high bandwidth needs CPU cycles, or better yet, hardware offloading.

Funnily enough, I've just got a firmware applied to my cable connection with Virgin Media in the UK that mitigates the Puma 6 issue on their provided DOCSIS 3 modem - it's eliminated buffer bloat as well, which is a nice side effect.

People are listening, Docsis 3.1 includes active queue management for instance, which goes a long way to preventing the issue.

Note that the firmware update doesn't fix the issue (which is Intel failed to put much cache on their chips to save $$), but merely helps to lessen the impact of Intel's shoddy hardware engineering. I would still replace your modem with a non-Intel modem ASAP if you want good performance.

This thread covers the issue pretty well: https://www.dslreports.com/forum/r31614833-Equip-Intel-Puma-...

Virgin Media in the UK don't allow third party modems.

I've run a lot of tests since the update, and it's definitely on a par now with my old FTTC connection, jiter especially is much improved.

I enabled sch_cake on my router (an R7800 with Openwrt 18.06 on it) recently. Worked like a charm. Would happily recommend.

I imagine the main thing that's holding back ISPs from using it on their consumer routers is the (minimal) configuration the user has to do to set to upload bandwidth limit. If ISP routers were also using decent queuing algorithms and not buffering like crazy then that wouldn't be necessary of course, but it doesn't seem like that's going to change any time soon.

Well, many isp-born devices are provided with that info by the ISP at connect time, so the hope has always been that during configuration they'd just pass (for example) "bandwidth 10mbit docsis" to the network setup routine. DSL modems also typically get this info at startup.

> We can end bufferbloat, now, on everything.

We have been able to for years. htb+sfq has been around forever.

Neither HTB or SFQ includes a CoDel-like AQM component. HTB+SFQ will get you fair sharing of bandwidth shaped at the rate of your choosing, but does nothing to control queue lengths.

> but does nothing to control queue lengths.

For directly managing bufferbloat, I never understood this to be a requirement. Either technique is meant to create back-pressure on the TCP stack so it can more effectively manage it's window.. and both do that perfectly well.

My understanding is that you would want AQM in order to keep your bandwidth utilization closer to the actual wire speed than a simple priority queue would.

So, we've had the tools to deal with bufferbloat for a long time, it's just that this mode now just provides slightly better peak performance.

> For directly managing bufferbloat, I never understood this to be a requirement. Either technique is meant to create back-pressure on the TCP stack so it can more effectively manage it's window.. and both do that perfectly well.

If you have a traffic shaper being fed by a deep, dumb queue, you aren't giving useful back-pressure to TCP until it's too late. You need an AQM that gives either ECN marks or packet drops soon enough that you don't build up or sustain deep queues of packets. That's the core of what bufferbloat is. The queue(s) in front of HTB in your router might not be as stupidly oversized as the queue in your cable or DSL modem, but they're still susceptible to the same problems when there's no AQM component. Some TCPs do a decent job of backing off when latency climbs, before the buffers actually fill and start causing packet drops. But AQM in the router can more directly observe and act on congestion, and works with older TCPs and non-TCP traffic.