I'm quite aware that I have bad bufferbloat problems. Unfortunately suggestions like these are kind of useless to me, and I'm surprised that they're not useless for more people. My (cable) residential internet averages about 110mbps. However, sometimes during the day it will go down to 85mbps or so, and later at night it's usually about 120mbps, and I've seen up to 135.
The way these congestion algorithms work, you've got to let the algorithm limit your bandwidth to ~95% of what's actually available. If I always got exactly 110mbps, I'd be okay with that. The problem is that I've got to limit it to 80 mbps or so for it to be useful during the day. And there's no way I'm going to do that and lose 40-50 mbps of my bandwidth every night.
Widely varying connection speeds are common enough that I'm surprised many people have found these algorithms useful. I wish there was one intelligent enough to respond dynamically to however much bandwidth is available.
My cable is very asymmetric 150/5 nominal, 170/6 best case.
I just now experimented with creating only the outgoing queue on my external interface. That's the slow direction. I went from a D in bufferbloat to an A, with just that one line addition.
Can you live with reducing just your upload speed? I sure can, I rarely upload much. But even if I were doing large amounts of cloud backup, it might not matter. If I go from 5000K to 4500K, is that really such a loss? Am I going to cry over 10%?
And if there is congestion such that my actual upload speed falls below 4500K, it's possible, maybe even likely, that I'm no worse off than before I created my upload queue.
Unfortunately the DSL Reports speedtest only tests one direction at a time. So maybe my fix doesn't work well if there is significant bidirectional simultaneous traffic?
Fortunately I'm running OpenBSD on my firewall, so it was very easy to experiment with this.
I'm running OPNsense here, so it's also fairly easy to manage. If I interpreted the DSL Reports test correctly, it looks like I see bufferbloat (median ~1.5 seconds) when downloading, but not a significant amount when uploading. So I don't think shaping only the outgoing traffic would help me. But maybe I'm misunderstanding.
If so, explore your cable modem and see if it's possible to manually configure the link speed to 100 Mbps (leave duplex set to auto-negotiation, though). This should cause your link to always auto-negotiate to 100/full and, at that point, bufferbloat (in that direction, at least) should (in theory) be much less of an issue (or potentially even non-existent!).
Unfortunately, some cable modems have very few configuration options that can be controlled or modified by the end user (they download their configurstions via TFTP at startup, as you probably know) -- especially when it comes to ISP-provided (or, worse, "ISP-customized") cable modems.
You're correct. Even though I have a decent third-party modem that I own, it lacks any real configurablity because most of the options get locked away by TWC.
The way these congestion algorithms work, you've got to let the algorithm limit your bandwidth to ~95% of what's actually available. If I always got exactly 110mbps, I'd be okay with that. The problem is that I've got to limit it to 80 mbps or so for it to be useful during the day. And there's no way I'm going to do that and lose 40-50 mbps of my bandwidth every night.
Widely varying connection speeds are common enough that I'm surprised many people have found these algorithms useful. I wish there was one intelligent enough to respond dynamically to however much bandwidth is available.