The name "bufferbloat" is falling out of favor. First off, it has a horrible sound... And it doesn't really give an intuitive sense of what's wrong.
Referring to "latency" or (my favorite) "responsiveness" is better.
And I was encouraged to see this recent ZDNet article that mentioned the "ping rates" of 600-1000 msec, and notes that these would cause videoconferencing or gaming to be unusable.
> I just stopped updating the controller software (none of their gear is external-facing, and IIRC it's only needed for configuration/management) because cloud login is an absolute dealbreaker for me.
Yeah. Updates used to be a nightmare. I had to worry about Windows updates, Java updates, and of course Unifi updates.
I have 21 APs all controlled by the container on a Raspberry Pi 4. It's not even breaking a sweat. When I want to upgrade the Unifi application, I stop the container, and re-run the command to use the newer Unifi version. Three minutes later, it's back on the air.
As another poster noted, the Feds funded a lot of the cost of electrification. There is starting to be some action on the internet front. But...
Here are the economics for a fiber optics deployment in 2021 for a rural town of ~800 premises, where about 60% got service. They charge customers about $100/month for symmetric 75/75mbps internet plus phone.
It costs about $40K per mile to run the fiber down the road on existing utility poles. It costs between $2K and $4K to run the drop from the utility pole to the home.
Those two numbers (miles of road, number of premises) get you in the ballpark of the cost of deployment in a town/county. More premises per mile obviously decreases the cost per premise - that's why utilities prefer dense areas (cities).
@LinuxBender is on the right track. Bufferbloat can cause this kind of lag. (There may be other causes, but first thing to do is check for bufferbloat.) To do this use:
This measures the latency/lag while data is being transferred. When it's complete, click "Results + Share" and you'll see a report. Send us the link of that page so we can see your results.
Your router is holding ("buffering") packets in the hopes that they can be sent soon. Your measurements indicate that the router is "bloated", holding about five seconds (5,000 ms) worth of data.
This gives the sending TCP algorithm the wrong impression. It's waiting to hear about a dropped packet to indicate that there's congestion. When your router holds on to those packets (instead of dropping them), the TCP algorithm doesn't get any feedback, so it keeps shoveling data into the connection.
This leads to the bad state you're seeing. And that's where the advice on "What can I do about Bufferbloat?" comes in.
There's no benefit to having more than one packet buffered by the router. (Hanging on to more than one packet per connection only causes the latency/lag you're seeing.)
There are routers that actually check the time the router has held packets. If packets have been queued for "too long", the router discards them immediately, giving the vital feedback to the sending TCP. Those routers use the technique known as SQM (Smart Queue Management) and the fq_codel, cake, PIE algorithms to keep the queues within the router short - typically less than 5 msec.
To solve your problem, investigate getting a router that implements one of those SQM algorithms. They're listed on the "What can I do..." page. I am a fan of OpenWrt (use it at home), but have installed a bunch of IQrouters and Ubuquiti devices for friends.
TCP has its own buffers too. In a media application I had to use UDP because I could know how deep the local transmit buffering went. TCP just swallows the packets and maybe sends them, maybe buffers them. Adding to the problem.
Please report back to the list so we can refine our knowledge. (It's like Covid-19 testing. We cannot know the incidence of infection if we don't test lots and lots of people to find a true rate...) Thanks.
> Why should the video bitrate be dropped because some second rate ISPs are oversubscribing super badly? Isn't all of this totally against the principles of net neutrality?
No. This is entirely separate from net neutrality. That principle says, "No ISP should discriminate on the basis of content."
In the case of an oversubscribed ISP, the "magic of the markets" that so many lobbyists talk about is that you can simply switch to a new provider. Oh, you only have one provider? Tough cookies.
I already do this. But I cheat - I use a good router (OpenWrt One) that has built-in controls for Bufferbloat. See [How OpenWrt Vanquishes Bufferbloat](https://forum.openwrt.org/t/how-openwrt-vanquishes-bufferblo...)