this post was submitted on 25 Jul 2023
478 points (98.4% liked)
World News
32286 readers
745 users here now
News from around the world!
Rules:
-
Please only post links to actual news sources, no tabloid sites, etc
-
No NSFW content
-
No hate speech, bigotry, propaganda, etc
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
No... I'm not. Downloading a 100GB game from Steam for example will gladly eat the full 50 mbps this person claims is "usable". A 100GB download would be ~4.5 hours at full speed. With ANY amount of overhead it will be more than 5 hours.
A download saturating the full connection is a capacity problem.
To the second point... If you are on a zoom call and are uploading the full 10 mbps of your connection speed. You will have problems uploading requests to fulfill for download.
Both of these are capacity problems. Not bufferbloat. Quite honestly, this capacity problem can CAUSE bufferbloat. There will be excessive queuing and packet loss.
Multi-hour downloads have been a thing since capacity was measured in kbps. If a simple TCP transfer causes excessive queueing, then the queueing algorithm is broken.
A router with OpenWrt and
luci-app-sqm
can fix this problem, at least for an internet connection with a fixed speed limit.LMAO. No. This has nothing to do with a router. TCP is a "fair" protocol. https://www.geeksforgeeks.org/tcp-fairness-measures/
How you can argue about this stuff and now even know how it works... beyond me.
A steam download (which tends to open multiple TCP channels, thus choking other connections on a network)... That's taking 50 mbps + your youtube video that wants to take 7mbps. 50+7 = 57 which is > 50 mbps. This is literally a capacity problem.
Once again... It would be the fact that you're using more than your actual bandwidth that you would cause excessive queueing and thus have a bufferbloat problem. But simply switching queueing mechanisms won't resolve it. especially if you're using traffic that isn't prioritized. Nor does switching queueing mechanisms mean that the problem was bufferbloat to begin with.
Well, if you currently have this problem and want to fix it, I've shown you the way. OpenWrt is free software.
Otherwise, there's no point arguing about it.
OpenWrt can't magic extra bandwidth in your pipes.