[HN Gopher] Unbloating the buffers
___________________________________________________________________
Unbloating the buffers
Author : dgroshev
Score : 65 points
Date : 2024-01-23 10:18 UTC (12 hours ago)
(HTM) web link (dgroshev.com)
(TXT) w3m dump (dgroshev.com)
| codyd51 wrote:
| This is a funny and digestible read, thanks for sharing!
| Thaxll wrote:
| Someone can explains why buffer bloat is always tied to specific
| hardware but from what I've read the fix is a different scheduler
| in Linux so it a hardware or a software problem or both?
| FredFS456 wrote:
| It's a software issue, but many routers are sold as appliances
| where the average user does not choose what OS to run.
| Therefore, a common recommended solution to bufferbloat is to
| replace the router with one whose software has more modern
| buffer management algorithms.
|
| OpenWRT, for example, can be flashed on many older routers and
| will be able to solve bufferbloat without replacing the
| hardware.
| wtallis wrote:
| Bufferbloat can be a hardware or software problem. The fix is
| always to move the bottleneck to a device you control and can
| configure to not have bufferbloat at that bottleneck. For
| consumer hardware that means implementing AQM in software.
| JoshTriplett wrote:
| It's a problem in various networking devices, in which those
| devices buffer too heavily rather than dropping packets. That
| behavior may be implemented in a combination of
| hardware/firmware/software. Among other things, this prevents
| other devices from being able to adapt to bandwidth limits
| (because dropped packets are the primary way to signal "slow
| down"), and causes high latency (because packets are sitting in
| deep buffers for a while).
|
| Software such as network schedulers in Linux can work around
| that problem. But ultimately, it _should_ be fixed in the
| various networking devices that create the problem in the first
| place.
| kccqzy wrote:
| CAKE is pretty modern. You can also read the original algorithm
| proposed to solve the problem, CoDel [0]. The article doesn't
| quite go into details of how to unbloat the buffers. So this is
| still worth a read. The TL;DR is that there are good queues and
| bad queues that we must distinguish, and that to distinguish them
| it is not a good idea to use queue length, but rather the
| recently experienced minimum time for a packet to spend in a
| queue. I find this very insightful.
|
| [0]: https://datatracker.ietf.org/doc/html/rfc8289
| p1mrx wrote:
| The biggest problem with CAKE/CoDel is that if you're not
| deploying it on the bottleneck device, you have to artificially
| limit the download/upload speed ("bandwidth 280mbit" "bandwidth
| 45mbit" in this example) in order to create a new bottleneck.
| Finding the correct limits is nontrivial because they might
| change over time.
|
| Anecdotally, switching from DOCSIS 3.0 to 3.1 seems to have
| improved my worst-case latency, because DOCSIS 3.1 includes a
| CAKE-like algorithm (PIE) in the modem itself:
|
| https://www.cablelabs.com/blog/how-docsis-3-1-reduces-latenc...
| davecb wrote:
| The bottleneck device can change with every different
| destination, so CAKE and fq_codel find it the same way older
| TCP code did: increase the load until they get a timeout or a
| "slow down, you idiot" flag (:-))
|
| The initial bandwidth setting is really to get it started at a
| good value for your usual bottleneck device, such as your local
| cable modem.
|
| Always starting off as if you had fast ethernet to the ISP when
| you actually have a super-el-cheapo link is a waste of time and
| effort. Even if you have a good algorithm like CAKE.
|
| --dave
| p1mrx wrote:
| When I used CoDel on OpenWrt years ago, setting a 1 Mbps
| limit prevented the link from ever going faster. If it's now
| smart enough to discover the correct limit, then that's an
| interesting/useful development.
| pixl97 wrote:
| I mean setting a static traffic control limit was generally
| a high water mark, and in general even if you had excess
| bandwidth you didn't want to exceed it.
|
| Now, to get around that some devices perform regular speed
| tests and dynamically adjust the high water mark. This said
| there are some limits at which you should perform these
| tests as too often and you may affect the actual
| applications you're trying to run.
___________________________________________________________________
(page generated 2024-01-23 23:00 UTC)