Slow Download

Before any cause is worth investigating, the number itself needs checking. Bandwidth is sold in megabits per second, and download clients almost always report megabytes per second, a factor of eight between the two. A 500 Mbps line running at full rate shows roughly 60 MB/s in the client, not 500. A large share of complaints that a connection is delivering an eighth of its rated speed are this conversion and nothing more.

The cheap causes, checked first

• A speed limit set during some earlier evening and forgotten. Most clients expose this in the toolbar as well as in settings, and a scheduler rule can apply one on a timetable with no visible reminder that it is active.
• The line already carrying other traffic: another machine streaming, a phone backing up, a torrent client seeding, an operating system update running in the background.
• A VPN in the path, which adds a second layer of encryption and routes the traffic through an intermediate hop that may be considerably busier than the direct route.

Connection count and where it stops helping

Per-connection throughput is limited by latency and by server-side pacing, so the total depends on how many run in parallel. Moving from 3 connections to 10 usually transforms a slow download. Moving from 20 to 50 usually changes nothing except the account's allowance and the size of the router's connection table. The right figure is the smallest one that fills the line: raising it in steps and watching where the gain flattens finds it in a few minutes. Values well beyond that point are a common source of 502 refusals on other devices sharing the same account.

Separating the machine from the network

1. Processor load during a download, read per core rather than as an average. One core pinned while the others idle is a processor limit, not a network one, and it is ordinary on ARM boards, entry-level NAS units, and routers running a client.
2. A brief test with SSL disabled on one server entry. A large jump confirms encryption cost on hardware without AES acceleration. Encryption should go back on afterwards, since the session is otherwise readable in transit.
3. Whether the collapse happens only when a repair or an unpack begins. That is storage contention, and the network is not involved.

When the provider or the route is responsible

What survives those checks is genuinely upstream, and it has a shape worth recognizing. Good speeds at some hours and poor speeds at others points at congestion on the path, frequently at the ISP rather than at the provider. A flat ceiling at every hour, with the processor idle, the disk quiet, and connections plentiful, points at the route to that particular server. Where a provider offers server entries in more than one region, switching between them separates the two cases quickly.