Transfer throughput

It is the achieved rate, not the plan you pay for and not the link's theoretical capacity. RFC 6349 separates TCP throughput testing from raw path capacity for that reason. A file copy also pays for protocol overhead, so the file-level rate sits a bit under the TCP rate.

Bandwidth is the neighbor term. Bandwidth is how much the path can carry. Throughput is how much this transfer used. A 1 Gbps office port and a 40 Mbps upload are both "the speed" in casual speech. Only the second number predicts when a cloud upload finishes. Latency is the other neighbor: round-trip delay. High latency hurts a chatty protocol with many small requests. It barely changes a single long upload once the window is full.

The planning formula is size in megabits divided by throughput in megabits per second. A byte is 8 bits. A 5 GB file is 40,000 megabits if you treat the gigabyte as 1,000 megabytes. At 80 Mbps that is 500 seconds, about 8 minutes, before retries and TCP slow-start. At 8 Mbps on a home up link it is 5,000 seconds, about 83 minutes. Quoting the download speed of the recipient does not help the sender's upload.

A nightly job pushes a 12 GB database dump. The circuit is sold as 500 Mbps. The job averages 62 Mbps because the path shares the link with backups and the server caps each session. Wall time is 12 × 8 / 0.062 ≈ 1,548 seconds, about 26 minutes. An operator who scheduled a 5 minute window from the sales number gets a partial file and a false failure. The fix is to measure the session, not the brochure, and to alert on byte count rather than on elapsed time alone.

Throttling is a cap someone set. Congestion is a cap the path imposed. Both show up as lower throughput. Neither is a different kind of transfer. Report the rate, the byte count, and the duration together. A single "speed" figure without those three is not enough to explain a miss.