CPU Bottleneck

A processor limit has a recognizable shape: a ceiling that does not move. It is the same at three in the morning as at nine in the evening, the same against a different server, the same on a different release, and it does not improve when connections are added. Past that point extra connections make matters slightly worse, since each one carries its own session state and decode work on a processor that has nothing left to give.

Hardware that meets this ceiling

Desktop and laptop processors of the last decade carry hardware AES instructions, which reduce the cost of encrypted transfer to something close to noise; a modern machine will saturate a gigabit line over NNTPS without noticing. The devices that struggle are single-board computers, entry-level NAS units built on low-power ARM or Atom-class chips, consumer routers running a download client, and virtual machines allocated a single core. On those, a flat figure in the low tens of megabytes per second with one core saturated is the expected result rather than a defect.

The test that confirms it

A process monitor open during a download, showing load per core rather than an average, settles the question in under a minute. One core at one hundred percent while the rest idle means the client is single-threaded on the work that matters and the ceiling is local. Disabling SSL on one server entry briefly and comparing the resulting speed isolates encryption specifically: a large jump means the processor lacks AES acceleration. That test should be reversed afterwards, since an unencrypted session exposes article requests to anything on the path. If neither reading moves, the ceiling is elsewhere: a disk limit tracks post-processing rather than the download, and an upstream limit varies by hour and by server.

Work that is not encryption

Encryption is only the most visible cost. Every article is yEnc-decoded and CRC-checked as it lands. PAR2 verification computes over the whole set, and repair performs Reed-Solomon arithmetic that is heavy by design. Decompression during unpack is a third demand. Direct unpack overlaps extraction with downloading, which is a good trade on capable hardware and a poor one on a board that was already at its limit. Filesystem overhead adds to the total where the destination is a network share rather than local storage.

What actually reduces the load

Lowering the connection count to the smallest number that still fills the available throughput removes per-session overhead. Turning direct unpack off keeps extraction and downloading from competing. Setting PAR2 checking to run only when damage is detected avoids verifying releases that arrived intact. Restricting the client to one post-processing job at a time prevents two repairs from sharing one core. Where none of that is enough, the ceiling is the hardware, and moving the client, or at least its post-processing, to a machine with AES support is the change that removes it.