Hacker News new | ask | show | jobs
by commandersaki 313 days ago
I reckon bufferbloat is overhyped as a problem, it mattered to a small set of Internet connectivity in the 2010s and promptly went away as connectivity changed and improved, yet we continue to look at it like it was yesterdays problem.
4 comments

Bufferbloat is alive and well. Try a t-mobile 5g home gateway. Oof.

I think cable modems have had a ton of improvement, and more fiber in our diet helps, but mobile can be tricky, and wifi is still highly variable (there's promising signs, but I don't know how many people update their access points)

Is it though, or is it just a scapegoat or a red herring, especially in the case with a wireless medium? That's been my experience with quick claims to bufferbloat, it's usually something else at play. But again ymmv.
There's always something else at play. Bufferbloat hides problems from the systems that can easily solve them. It doesn't cause problems, it makes them worse.
I mean, I did a speed test with t-mobile 5g home internet, download speed was impressive, but so was the difference in ping time during the download vs otherwise.

Sure, wireless is complex, but there were definitely some way too big buffers in the path. Add in some difficulty integrating their box into my network, and it wasn't for me.

Fair enough, I concede with your assessment, my understanding of bufferbloat (which I have to relearn everytime I look at it) is that the telltale sign is ping to any destination that traverses the uplink exhibits higher latency than usual when you're saturating your download. It's just a tricky thing to test given variability of conditions (and what might be deemed as expected operation) which is why I'm usually hesitant and sceptical, and I don't trust those speedtest websites to gauge it properly.
Every speed test I tried that measures latency under load shows a large difference between fq_codel on and off.
This is very much a problem ISPs have to deal with as big pipes feed small pipes.
What do ISPs have to actually determine these issues outside of sketchy speedtest websites and vague reports or concerns from customers? What about placing probes in the correct places (e.g. in conditions where there is no additional loss or introduced latency between the end user and uplink). Also is this an actual problem that users are really having, or is it perceived because some benchmark / speedtest gave you a score.

There's a lot of issues and variables at play; this isn't a case of "it's always DNS". What tools do ISPs even have at their disposal and how accurate are they and does it uncover the actual problem users are experiencing? This is the real issue that ISPs of all size have to deal with.

codel/CAKE also came from that project, no middlebox needed.
Internet connectivity improvement has slowed a lot. It was improving at a good clip in the 00's but then a lot of usage moved to mobile data which also caused investment to shift away from broadband speedups. If we had 00's rate of improvement, people would have 100G connections at home now.

(wifi also dampened bandwidth demand for a long time - it didn't make sense to pay for faster-than-wifi broadband)

A relative of mine runs a WISP (800+ customers). He's using LibreQoS to prevent bufferbloat (not its only feature) for his entire network.
Someone hasn't travelled a lot outside of the house I see?

Wifi is still mostly shitty in most places in the world.

Then there are countries like Philippines with just all around slow internet everywhere.

Never said there isn't connectivity or service quality issues inside or outside the home; just that bufferbloat specifically is a trope that should be put to rest.