Why Usenet Speeds Vary: It Is Almost Never the Provider

When someone on Reddit says "I am only getting 50 Mbps on my gigabit connection, is this provider slow?" the answer is almost always no. The provider is serving data as fast as your connection can pull it. The bottleneck is somewhere between your computer and the server, not at the server itself.

This page explains every link in that chain, why each one can limit your speed, and how to identify which one is your actual bottleneck. If you just want the quick optimization checklist, see our speed optimization guide. This page is the deeper "why."

When you download from NewsDemon, your data does not travel directly from our server to your computer. It passes through a chain of networks, and each link in that chain can be a speed limit.

NewsDemon server → our data center network → transit provider(s) → internet exchange point(s) → your ISP backbone → your ISP last mile → your modem/router → your computer

Your "gigabit connection" only describes the last mile, the link between your ISP and your house. Every other link in the chain has its own capacity, its own congestion level, and its own potential to be the bottleneck.

ISP peering and transit

Your ISP connects to the broader internet through peering relationships and paid transit links. If your ISP has a weak peering connection to the network where NewsDemon servers live, your traffic has to take a longer, more congested route. This is the single most common reason someone with a fast internet connection gets slow Usenet speeds.

You can test this with a traceroute to news.newsdemon.com. If you see high latency or packet loss at a specific hop (especially one owned by your ISP or a transit provider), that is likely the bottleneck. Switching to a different NewsDemon server region (US East, US West, or EU) sometimes helps because the traffic takes a different path through the internet.

ISP throttling

Some ISPs deliberately slow down Usenet traffic. They use Deep Packet Inspection (DPI) to identify NNTP protocol traffic and apply rate limits. This is more common on port 119 (unencrypted) where the protocol is easy to identify, but some ISPs throttle even encrypted traffic on port 563 based on traffic patterns.

The test is simple: connect through a VPN and compare speeds. If your speed jumps significantly with the VPN, your ISP was throttling. A VPN prevents the ISP from identifying the traffic as Usenet. SlickVPN is included free with every NewsDemon plan for exactly this scenario.

Congestion at peak hours

Internet congestion follows predictable daily patterns. In the evening (roughly 7-11 PM local time), residential networks see peak usage as people stream video, game, and download. Your ISP shared infrastructure, the node serving your neighborhood, the transit links from your ISP to the wider internet, can all get congested during these hours.

If you consistently see slow speeds in the evening but fast speeds at 2 AM, the problem is congestion somewhere on your ISP side of the connection. The provider is not slowing down. The pipe between you and the provider is just more crowded at peak times.

Geographic distance (mostly a non-issue)

As long as your provider has an NNTP server on your continent, geographic distance is rarely a meaningful factor in download speed. A connection from London to a server in Amsterdam has about 10-15ms of round-trip latency. New York to Virginia is under 20ms. At those latencies, even a single TCP connection can push hundreds of megabits. Add 30-50 parallel connections and distance within a continent stops mattering entirely.

Where distance does become a factor is intercontinental connections. Sydney to Virginia is roughly 200ms round-trip. At that latency, each individual TCP connection tops out at 50-80 Mbps regardless of your line speed, so you need all 50 connections working to get decent aggregate throughput. It works, but it is noticeably less efficient than connecting to a server in your own region.

This is why provider server locations matter. A provider with one server farm in the US is fine for North American users, but a European or Australian user is paying a latency tax on every connection. NewsDemon operates three server regions: US East (Virginia), US West (California), and EU (Netherlands). If your provider only has servers on a different continent from you, that alone could explain your speed issues, and no amount of connection tuning will fully fix it. Switch to a provider that has infrastructure near you.

TCP window size and tuning

TCP, the protocol that carries your Usenet traffic, has a congestion control mechanism that determines how much data can be "in flight" between you and the server at any moment. The maximum throughput of a single TCP connection is limited by the formula:

Max throughput = TCP window size / Round-trip latency

On a high-latency connection (say 100ms RTT), a single TCP connection with the default window size might max out at 50-80 Mbps even on a gigabit line. This is why Usenet uses multiple connections in parallel. Each connection has its own TCP window, and the total throughput is the sum of all connections. With 30-50 connections, the aggregate throughput can saturate even a gigabit link across high latency.

This is the single best argument for more connections: they are not just about downloading more articles simultaneously. They are about overcoming the per-connection throughput limit imposed by TCP and latency.

Wi-Fi

Wi-Fi is the most common hidden bottleneck. Even Wi-Fi 6 (802.11ax) with its theoretical multi-gigabit speeds delivers real-world throughput that is significantly lower than wired ethernet, and varies constantly based on distance from the router, interference from other devices, wall construction, and how many other devices are on the network.

If you are troubleshooting slow Usenet speeds, the first thing to try is a wired ethernet connection. If your speed doubles when you plug in a cable, Wi-Fi was the bottleneck. This is not a Usenet-specific issue. It affects everything, but Usenet speeds are more noticeable because you are sustaining high throughput for long periods rather than loading web pages in short bursts.

Router and modem limitations

Some consumer routers cannot handle high-throughput encrypted traffic at line speed. SSL/TLS requires CPU cycles to decrypt, and cheap routers may not have the processing power to decrypt a gigabit of traffic in real time. If your router CPU is maxed out during downloads, it becomes the bottleneck.

This is more common with ISP-provided routers than with aftermarket ones. If you suspect your router, try connecting your computer directly to your modem (bypassing the router) and test again.

Disk speed

Your download client writes data to disk continuously during a download. If you are writing to a slow mechanical hard drive, a USB 2.0 external drive, or a NAS connected over a slow network link, the disk becomes the bottleneck before your internet connection does. Use an SSD for your download client temporary directory. Even a cheap SATA SSD is orders of magnitude faster than spinning rust for the random-write pattern that Usenet downloads produce.

CPU limitations (rare but real)

SSL decryption, PAR2 verification and repair, and archive extraction all use CPU. On modern desktop hardware this is not an issue. On low-power devices (Raspberry Pi, older NAS units, budget ARM-based routers), the CPU can become the bottleneck during SSL decryption. NZBGet is lighter than SABnzbd on CPU, which is why it is preferred for NAS and embedded devices.

Can the provider actually be the bottleneck? Yes, but it is rare with established providers and much less common than people assume. Here is when it is actually the provider:

Oversold server capacity. If a provider puts too many users on a single front-end server without enough bandwidth, users compete for the same pipe. Established providers with their own infrastructure (like NewsDemon) scale their front-end capacity to handle peak load. Smaller resellers who rent a single server may not.

Slow spool retrieval. If the spool software or storage hardware cannot serve articles fast enough, the server becomes the bottleneck. This mainly affects older articles on spinning disk. Recent articles on NVMe hot spool are served at memory speed.

Artificial throttling. Some budget providers throttle speeds on cheaper plans or during peak hours to reduce costs. NewsDemon does not throttle any plan, ever. The $3/month metered plan gets the same speeds as the unlimited annual.

If you suspect the provider is the issue, the test is to try a different server region. NewsDemon has three (US East, US West, EU). If all three are slow but your internet is fast for everything else, contact support and we will investigate the path from your ISP to our servers.

When your Usenet speeds are not what you expect, work through this in order:

1. Are you on Wi-Fi? Try wired ethernet. If speed doubles, that was it.

2. How many connections? If under 20, increase to 30-40. This alone fixes most complaints.

3. Are you on SSL port 563? If on port 119, switch. If 563 is blocked, try 443.

4. Does your provider have a server on your continent? If you are in Europe connecting to a US-only provider, that is your problem. Switch providers or find one with EU servers. If your provider has a local region, make sure you are connected to it.

5. Try a different server region. If your provider has multiple, test each one. Different region means different network path, potentially different bottleneck.

6. Test with a VPN. If speed improves, your ISP is throttling. Keep the VPN on.

7. Check disk speed. Are you writing to an SSD or a slow mechanical drive?

8. Check time of day. Slow at 9 PM but fast at 3 AM? That is ISP congestion, not the provider.

9. Run a traceroute to news.newsdemon.com. Look for high latency or packet loss at specific hops. That identifies the weak link.

10. Still slow after all of the above? Contact NewsDemon support with your traceroute results and we will dig into it from our end.

People sometimes ask why Usenet uses 20-50 connections instead of one fast connection like a web download. The answer is physics and protocol design.

A single TCP connection on a 100ms latency link maxes out at roughly 50-80 Mbps regardless of how fast your line is. This is a fundamental property of TCP congestion control, not a limitation of Usenet or any specific provider. HTTP gets around this by downloading multiple files in parallel and using HTTP/2 multiplexing. Usenet gets around it by opening multiple NNTP connections, each downloading a different article segment simultaneously.

With 30 connections, each doing 50 Mbps on a 100ms link, your aggregate throughput is 1.5 Gbps (limited to your actual line speed). This is why Usenet can saturate gigabit connections while a single HTTP download from the same data center might not.

NewsDemon includes 50 connections on every plan because connection count directly translates to achievable throughput, especially on high-latency or high-bandwidth connections. The $3/month plan gets the same 50 connections as the unlimited annual.