We use cookies to understand how the site is used and to improve it. You can accept them, or carry on with them switched off.
Also known as: buffer bloat
Oversized queues in routers and modems that fill during a saturating download, adding hundreds of milliseconds of latency to everything else sharing the connection. A newsreader running many connections at full speed is a frequent trigger, which is why browsing and calls feel broken while a queue drains. Capping the client slightly below the line rate, or enabling queue management on the router, resolves it.
This is the one entry in this section that is not an error at all. Nothing fails, nothing is logged, and the newsreader reports full speed from start to finish. The complaint comes from everyone else sharing the connection, and the natural first conclusion, that the line or the provider has developed a problem, is exactly backwards. The transfer is working too well for the equipment carrying it.
What degrades is latency, not bandwidth. A saturated queue in a modem or router holds hundreds of milliseconds of data waiting its turn, and every new packet joins the back of it. Interactive traffic is small and urgent but receives no priority, so name lookups crawl, pages take seconds to start rendering, and voice and video calls break up while a bulk transfer runs at full rate. Speed tests taken during the download often look healthy, because they measure throughput rather than queue delay.
Usenet clients open many parallel connections deliberately, since one TCP stream rarely saturates a modern line on its own. Twenty or thirty streams pushing at once fill any queue in the path within a second or two and keep it full for the duration of the download. It is worse on asymmetric connections, where the acknowledgements for a large download must squeeze through a narrow and now congested upstream, which eventually slows the download itself alongside everything else.
Cutting from twenty connections to five usually changes nothing, because five connections saturate the line just as thoroughly and fill the same queue. The variable that matters is total throughput relative to the line rate, not the number of sockets carrying it. Connection count is worth lowering for other reasons, plan limits and router NAT pressure among them, but it is not the fix here, and time spent on it delays the two that work.
Every serious newsreader offers a global speed limit. Setting it to roughly 85 to 90 percent of the measured downstream rate keeps the bottleneck queue from filling and makes the rest of the network usable again. The transfer finishes slightly later; nothing else is given up. The figure has to come from an actual measurement of the line rather than the number on the bill, and it has to sit below the real rate rather than at it. Clients with a scheduler can lift the cap overnight when nobody is competing for the connection.
The better fix is applied where the queue actually forms, on the device facing the slow link. Current router firmware often includes smart queue management, frequently implemented as fq_codel or cake, which signals congestion early so senders slow down before delay accumulates. Configured with accurate upstream and downstream rates it holds latency low without any client-side cap, and it protects the connection from whatever else saturates it later, not just from the newsreader.
Browse all terms in Errors & Troubleshooting, or see the full Usenet glossary.