Slow rsync? Check source CPU before blaming network
Diagnosing slow long-running file transfers between two hosts when uncertain whether the bottleneck is bandwidth or compute
When SSH encryption competes with a CPU-heavy workload (e.g. transcription, ffmpeg, builds) on the source machine, per-stream throughput can drop to a fraction of the actual link capacity even though the network itself is fine. Disambiguate with time dd if=/dev/zero bs=1M count=200 | ssh host 'cat > /dev/null' — this measures clean SSH throughput without rsync metadata overhead. If that is also slow AND top shows source load avg >> core count, the answer is CPU contention, not bandwidth, and no rsync flag will fix it. Side gotcha: macOS stock rsync (BSD 2.6.9) does NOT support --info=progress2; use --progress or the rsync silently aborts with usage output.
On any 'why is this transfer slow' question, measure (a) load avg on source, (b) clean SSH throughput via dd-piped-into-cat-on-remote, before assuming bandwidth — and remember macOS stock rsync uses old BSD flag syntax.