Cake at 300+MBit on wrt3200acm in 2019

Is it possible that a congested DOCSIS connection is causing this? I don't mean to hijack this thread but I have had a similar problem with SQM on my DOCSIS connection where after a certain speed the bufferbloat gets really bad but the router CPU isn't pegged.

right, the local link could be easily oversold, but it wouldn't explain if you are able to get high download without cake and then not with cake.

That's about what is expected. For one, there is a need to leave some reserve capacity for high-priority traffic, so the bulk exchanges used in the speed test are not allowed to fully saturate the line. Alos, an AQM will keep TCP congestion widows (cwnd) pretty small (double-digits), whereas an unmanaged line allows humongous cwnd of 1500 and even more. RTT's of over a second for those crazy huge cwnd mean tons of latency for the latency measurement pings.
Look a the 'server view' section of the detailed report to see the cwnd and RTT's. Lower RTT and smaller cwnd are better for overall real-world throughput.

Remember, on the Internet, a 'speed' test is a measure of capacity, not velocity.

Cable industry gets it right with DOCSIS 3.1

Looks like the light bulb came on with the goal of 0% of retransmitted packets across their cable networks. Wish all other types or Internet connections would require some type of TCP/IP RFC standard that would resolve the bufferbloat issue. Know that OpenWrt 18.06.2 r7676-cddd7b4c77 / LuCI openwrt-18.06 branch (git-19.020.41695-6f6641d) / SQM - cake - piece_of_cake.qos has done the job of resolving my bufferbloat issue on my Frontier 150/150 FIOS connection.


Solve Bufferbloat Problems with a DOCSIS 3.1 Modem
Dave HamiltonDave Hamilton
Jan 15th, 2018 11:44 AM EDT | MGG Answers

Phil asks, “Comcast/XFINITY has raised their rental fee to $11/month and I’m going to buy a new modem. Should I buy DOCSIS 3.0 or is there a good reason to buy DOCSIS 3.1 today?”

At this point, if you’re buying a modem for Xfinity I would go with a DOCSIS 3.1 modem, for sure. Not only does it future-proof you for if/when you want to get Gigabit service, it also gives you the new DOCSIS-PIE queue management that’s mandated to be in all DOCSIS 3.1 modems, even when they’re running DOCSIS 3.0 connections. DOCSIS-PIE is mandated by Cable Labs for DOCSIS 3.1 modems (and later) because it effectively solves that upstream bufferbloat problem which plagues all pre-DOCSIS 3.1 modems.

This makes a HUGE difference, and means you no longer have to think about solving Bufferbloat with WAN QoS management in your router.

Comcast has had DOCSIS 3.1 active for over a year now but they never bothered enabling AQM. So even with a DOCSIS 3.1 modem I still get +2000ms of bufferbloat. I doubt Comcast will ever bother setting it up because why would they care if your connection is bloated when most of their subscribers don't have another ISP choice at their address.

Well Comcast stated that they have started to roll out DOCSIS across the nation. This started back in December of 2015.... Comcast begins rolling out DOCSIS 3.1-based gigabit home Internet By Todd Ogasawara on December 29, 2015 at 11:08 am

Now I do not have Comcast at this time however have a number of people I know in the Portland (OR) / Vancouver (WA) metro area that have run tests and they do not seem to have a bufferbloat issue on their connections. It would look as if they have updated the equipment in this area. So if someone updated the cable modem if they rent from Comcast, or have a newer one they own themself (which is what I advise people to do) they should get these better results.

As far as we know the egress aqm PIE is mandatory for all DOCSIS 3.1 modem's, and on by default, so unless your ISPs actively diasables this there should be upstream AQM on your link. Could I convince you to run a speedtest according to the recommendations in with all AQM/SQM in your router disabled? I expect to see very little* bufferbloat in the egress direction, while the download might still be terrible.

*) If I recall correctly the PIE latency target is something along the lines of 20ms, so I would expect latency under load in upload direction to be 20-40ms higher than during idle periods (but note that this might be initially swamped by the leftover download packets in the upstream buffers that first need to be sent before the return latency probes are not delayed anymore by this resudue from the download test).