I wrote the other day about several big things happening in Usenet over the last few weeks. In case you missed it, Frugal Usenet debuted their South Africa based server. The other notable news is the SabNZB newsreader software added NNTP Pipelining support.
SABnzbd Added NNTP Pipelining
SABnzbd dropped version 5.0.0 with NNTP pipelining as a new marquee feature. The pitch is that it eliminates idle waiting between requests and speeds up downloads, especially on high-latency connections.
So I immediately wondered: does this actually matter for anyone?
What They’re Claiming
NNTP pipelining lets SABnzbd send multiple article requests to your Usenet server without waiting for each response to come back. Pre-pipelining, SABnzbd would send a request, wait for the answer, then send the next request (even without pipelining, this is still happening very quickly). Pipelining lets it get X number of requests in flight to the server so there is less (or no) idle time.
The theory is that on a higher latency connection, the software is not sitting around doing nothing while waiting for the server to respond. You’re already asking for the next batch.
It’s set to default at 2 articles per request for new server configs, which is basically “light pipelining.” You can turn it up to 5-10 (not recommended at all) if you’re on a really high latency connection or have a ton of bandwidth.
When It Actually Helps
If you’re on a connection with more than 100 milliseconds of latency to your Usenet server, pipelining can make a difference.
For everyone else, most people in the US downloading from US servers, Europeans using European providers, the latency is most likely under 50ms already. In that case, pipelining is not really beneficial at all. The wiki notes increasing connections helps more than increasing pipelining values.
So if you’re local-ish to your server already, don’t expect a speed bump.
The Catch
New servers added to SabNZB get pipelining automatically set to 2. Existing installations running prior to 2 months ago, you have to manually turn it on. That means most people running SABnzbd setups won’t get this unless they dig into the settings that they probably have not touched in years, to turn it on.
Also, pipelining values that are too high can actually reduce performance due to increased overhead. So you can’t just crank it to 20 and call it a day. You have to tune it carefully based on your latency and connection limits. It becomes trial and error really.
In my testing, and I really tried to break something, a value any higher than 2 or 3, with a bunch of connections configured, will really cause performance issues on all but the most beefy of hardware.
Honest Take
If you’re in a region with genuinely high latency to your Usenet provider, enable pipelining and play with the values. You might see improvement.
If you’re anywhere else, most people, this probably isn’t going to change your download speeds noticeably. It’s a technical optimization for a specific use case, not a silver bullet.
The good news is that it’s a free update and the default is sane (2 articles per request won’t hurt). The bad news is that it gets marketed like it’s a major speed boost when really it’s just fixing an inefficiency for people who had a specific problem to begin with.
SABnzbd is still one of the most popular newsreaders. This update just doesn’t revolutionize anything for most users.
My final take on it is that the setting should have been a simple checkbox (enable/disable) and the value hard-coded to 2 when enabled. I think a fair amount of users who will not bother reading the docs will get a bit ambitious with the numbers and cause problems for themselves.