Bandwidth & Transfer Calculator
Real transfers rarely reach line rate. 85 to 95% is typical for TCP on a clean path.
Over distance: what one TCP stream actually gets
Add a round trip time and this shows the ceilings above. Leave it blank on a local network, where neither applies.
The same size in other units
Sizes, link speeds and honest transfer times, with the bits-versus-bytes confusion handled.
Why size divided by link speed is optimistic
On a local network, dividing the file size by the link speed is close enough. Over distance it is not, because a single TCP stream is not limited by the link. It is limited by how much data it is allowed to have unacknowledged in flight, and by how often loss forces it to back off.
The gap is not small. A 1 Gbps path with a 200ms round trip and a default receive window carries about 2.6 Mbps on one stream. That is a quarter of one percent of the link, and a 10 TB transfer that the simple arithmetic puts at a day takes closer to a year.
Bandwidth delay product and the receive window
The bandwidth delay product is bandwidth multiplied by round trip time: the amount of data that must be in flight to keep the pipe full. At 1 Gbps and 200ms that is roughly 24 MiB. If the receive window is smaller than that, the sender spends most of its time waiting for acknowledgements rather than sending.
A window that has not been scaled tops out at 64 KiB, which is why the ceiling is one window per round trip: 64 KiB every 200ms is 2.6 Mbps and no more, on a link of any speed. Window scaling, from RFC 1323, is what lifts that, and it is why tuning tcp_rmem matters far more on a long path than a short one.
What packet loss does over distance
Loss-based congestion control halves the window on every loss and grows back slowly, so throughput falls with the square root of the loss rate. The Mathis approximation puts it at roughly MSS divided by round trip, times one over the square root of loss.
The consequence is that loss and distance multiply. At 0.1% loss, a 20ms path carries about 23 Mbps on one stream and a 200ms path about 2.3 Mbps: same loss, ten times the distance, a tenth of the throughput. It is also why cutting loss from 0.1% to 0.01% only about triples throughput rather than multiplying it by ten. Both are estimates of a classic congestion control sawtooth, so a stack using BBR will behave differently.
What to do about it
Three levers, in the order they usually pay. Raise the receive window so it exceeds the bandwidth delay product, which is free and often enough on a clean path. Run parallel streams, since the ceilings apply per stream and the calculator above tells you how many you would need. Or shorten the path, because both formulas have round trip time in the denominator and nothing else you tune has that leverage.
Bandwidth and transfer FAQs
Why does my 1 Gbps link only move about 110 MB per second?
Network speeds are quoted in bits per second and file sizes in bytes: eight bits to the byte. A 1 Gbps link therefore tops out at 125 MB/s before protocol overhead, and a healthy TCP transfer typically delivers 85 to 95% of that, which lands near 110 MB/s.
What is the difference between GB and GiB?
GB is decimal, 10^9 bytes; GiB is binary, 2^30 bytes, about 7% larger. Storage vendors and network engineering use decimal, operating systems often display binary. The calculator shows both so the numbers reconcile.
How long does 10 TB take to transfer?
At a full 1 Gbps, about 22 hours; at 100 Mbps, over nine days. This is why large migrations plan bandwidth first, and why shipping physical drives remains rational for very large datasets over slow links.
What efficiency figure should I use?
90% is a reasonable default for TCP on a clean low-latency path. Use lower figures for high-latency links without tuning, many small files, or encrypted tunnels with small MTUs. Line rate, 100%, is a theoretical bound rather than an expectation.
Is anything I enter sent to a server?
No. The math runs in your browser and the page works offline.