What actually determines how long a transfer takes
A transfer takes as long as it takes to push every bit through the narrowest point in the path. That single sentence contains all three things you need: how many bits there are, how fast the narrowest hop is, and how much of that hop is consumed by something other than your data.
The first is a units problem. Storage is counted in bytes, links are rated in bits per second, and one byte is eight bits — so a 1 GB file is 8 × 109 bits, not 109. Miss the factor of eight and you will underestimate every transfer by 800%.
The second is a bottleneck problem. If a 10 Gbps server talks to a 10 Gbps server across a 200 Mbps WAN circuit, the transfer runs at 200 Mbps. Nothing else in the path matters. The number to enter is the committed rate of the slowest hop, which on a business circuit is often well below the burst rate printed on the contract.
The third is the efficiency factor, and it is where estimates go wrong most quietly. Between your file and the wire sit TCP headers, IP headers, Ethernet framing, acknowledgements travelling the other way, filesystem metadata for every small file, and whatever your encryption layer adds. Ethernet framing alone puts a hard ceiling on the arithmetic: a maximum-size TCP segment carries 1,460 bytes of payload but occupies 1,538 bytes of wire time once you count the 20-byte IP header, the 20-byte TCP header, the 14-byte Ethernet header, the 4-byte frame check sequence, the 8-byte preamble and the 12-byte interframe gap. That is 1460 ÷ 1538 = 94.93% before a single acknowledgement or retransmission.
The formula, and the two unit traps inside it
Divide the bits by the bits per second. Everything else is bookkeeping:
t = (S × 8 × 10⁹) ÷ (R × 10⁶ × η)
Trap one: decimal versus binary prefixes. A disk sold as 1 TB holds 1012 bytes. Windows Explorer will show that disk as 931 GB, because it is displaying tebibytes and gibibytes while labelling them TB and GB. The correct names for the binary units are standardised in IEC 80000-13: 1 KiB = 1,024 bytes, 1 MiB = 1,0242, 1 GiB = 1,073,741,824 bytes, 1 TiB = 1,099,511,627,776 bytes. This calculator offers both families and converts everything internally to decimal GB, so pick the unit that matches where your figure came from. The gap is 7.4% at the gibibyte and 10% at the tebibyte — enough to blow a maintenance window. The TB to TiB storage calculator handles that conversion on its own.
Trap two: bits versus bytes in the rate. Network rates are always bits per second and are always decimal: 1 Mbps is exactly 106 bits per second, and 1 Gbps is exactly 125 MB/s. Storage and backup tools, by contrast, usually report MB/s or MiB/s. This calculator lets you enter the link speed either way; if you want to convert between the two families on their own, use the Mbps to MB/s converter.
The efficiency term η is a single number standing in for many effects. On a low-latency LAN with large files, a healthy TCP transfer lands close to the framing ceiling. On a long-haul link, throughput is often limited by the TCP window rather than the line rate at all — a fixed window divided by the round-trip time caps a single stream regardless of how much bandwidth you bought. That is what the per-stream ceiling field is for, and the bandwidth-delay product calculator tells you what that ceiling is on your path.
Worked example: 2 TB over a 500 Mbps circuit at 85% efficiency
You are seeding a new backup target across a 500 Mbps metro circuit. The source volume reports 2 TB (decimal), and your last measured transfer sustained about 85% of line rate.
- Convert the data to bits. 2 TB = 2,000 GB. 2,000 × 8 × 109 = 1.6 × 1013 bits.
- Apply the efficiency to the line rate. 500 Mbps × 0.85 = 425 Mbps.
- Convert the rate to bits per second. 425 × 106 = 4.25 × 108 bps.
- Divide. 1.6 × 1013 ÷ 4.25 × 108 = 37,647 seconds.
- Convert to wall-clock time. 37,647 ÷ 3,600 = 10.4575 hours. That is 10 hours, then 0.4575 × 60 = 27 minutes, then 27 seconds: 10 h 27 m 27 s.
Now the sanity checks a practitioner runs next. Effective throughput of 425 Mbps is 425 ÷ 8 = 53.13 MB/s, which is 53.13 × 3,600 ÷ 1,000 = 191.25 GB per hour and 4.59 TB per day. At 100% efficiency the same job would take 1.6 × 1013 ÷ 5 × 108 = 32,000 seconds, or 8 h 53 m 20 s — so the 15% overhead costs you 5,647 seconds, about an hour and 34 minutes.
The decision that follows is concrete: 10 h 27 m does not fit an eight-hour overnight window, but it does fit a weekend. Either start Friday evening, split the seed across two nights, or negotiate the efficiency upward with more parallel streams.
How to read the result and what to do with it
Compare the answer against the window you actually have, not against your patience. A nightly backup has roughly eight hours between the last user logging off and the first logging on; a change window is typically four; a cutover during business hours may be twenty minutes. If the computed time exceeds the window, you have exactly four levers, and only two of them are usually available on short notice.
Move less data. Deduplication and compression change the numerator, not the denominator, and they are often the cheapest lever by an order of magnitude. Incremental-forever backup strategies exist precisely because the delta is a fraction of the full set. Work out your ratio with the data compression ratio calculator and re-run this one with the reduced figure.
Raise efficiency. If a single stream is far below line rate on a high-latency path, more parallel streams almost always help, because each stream gets its own window. If you are already near the framing ceiling, more streams do nothing.
Buy more bandwidth. Effective on a congested circuit, useless when the limit is window size or disk I/O at either end. Check the disk first: a single 7,200 rpm spindle sustains far less than a 10 Gbps link can carry.
Ship the data physically. Every large cloud provider sells a physical import appliance for exactly this reason. The crossover is worth calculating rather than guessing: at 100 Mbps, 100 TB takes 92 days at perfect efficiency. Courier plus copy time at both ends is measured in days.
One more figure worth reading is the data moved per hour output. It is the number to quote in a change record, because it lets anyone check progress mid-transfer: if you are four hours in and the target holds substantially less than four times that figure, something is wrong now, not at the end.
Transfer time for common data volumes at 100% efficiency
| Data | 100 Mbps | 1 Gbps | 10 Gbps |
|---|---|---|---|
| 1 GB | 1 m 20 s | 8 s | 0.8 s |
| 10 GB | 13 m 20 s | 1 m 20 s | 8 s |
| 100 GB | 2 h 13 m 20 s | 13 m 20 s | 1 m 20 s |
| 1 TB | 22 h 13 m 20 s | 2 h 13 m 20 s | 13 m 20 s |
| 10 TB | 9 d 6 h 13 m | 22 h 13 m 20 s | 2 h 13 m 20 s |
| 100 TB | 92 d 14 h 13 m | 9 d 6 h 13 m | 22 h 13 m 20 s |
Every entry is (bytes × 8) ÷ rate. Each step down a column divides by ten because each link speed is ten times the last.
Many small files are not the same job as one large file
This calculator models a throughput-bound transfer. A dataset of ten million 20 KB files is usually latency-bound instead: each file costs at least one round trip for an open, one for the metadata and one for the close, and on a 60 ms path that is nearly 200 ms per file no matter how fast the link is. Ten million files at three round trips each on a 60 ms path is over twenty days of pure waiting, with the link almost idle.
If your dataset looks like that, tar or zip it into large archives before sending, use a tool that pipelines metadata operations, or run many parallel workers. Then the figure this calculator gives becomes achievable again.
Why real transfers come in slower than the arithmetic
- The link is shared. Your transfer competes with everything else on the circuit. A backup that starts at 18:00 shares the pipe with the end-of-day surge.
- The TCP window is too small for the path. A single stream can never exceed window ÷ round-trip time, whatever the line rate. This is the single most common cause of a 1 Gbps link delivering 40 Mbps.
- Storage cannot feed the network. Random reads on spinning disk, a saturated RAID controller, or a throttled cloud volume will bound the transfer well below line rate.
- Encryption or compression is CPU-bound. A single-threaded SSH transfer on an old CPU can cap out long before a 10 Gbps NIC does.
- Packet loss triggers congestion control. Even a fraction of a percent of loss on a long path collapses TCP throughput, because the sender halves its window on every loss event.
- The rated speed is asymmetric. Consumer and many business broadband services upload far more slowly than they download. Enter the upload figure when you are sending.
- MTU mismatches force fragmentation. A tunnel that shaves bytes off the path MTU without correct clamping costs both throughput and reliability — the MTU and MSS calculator shows the size you should be clamping to.
Where this sits among the other sizing tools
This calculator answers a single question: given a fixed amount of data and a fixed rate, how long? Three neighbouring questions need different tools.
If you want to know whether a nightly job fits a recurring window, including the incremental change rate and the retention chain, the backup window calculator models that directly. If you are sizing a circuit for a population of users rather than a single transfer, the network bandwidth requirement calculator aggregates concurrent demand. And if the data is leaving a cloud provider, elapsed time is rarely the binding constraint — egress charges are, and the cloud egress cost calculator puts a price on the same terabytes.
Finally, treat any single answer here as the middle of a range. Measure a representative 10 GB sample over the real path before committing to a cutover plan, then feed the observed throughput back in as your efficiency figure. A measured 62% is worth more than an assumed 85%.
Key terms
- Line rate
- The nominal signalling speed of an interface or circuit, in bits per second. It is what the port negotiates, not what your application will see.
- Goodput
- The rate at which useful application payload arrives, excluding all headers, acknowledgements and retransmissions. Efficiency is goodput divided by line rate.
- Decimal prefix (GB, TB)
- SI prefixes based on powers of ten: 1 GB = 10⁹ bytes. Used by drive manufacturers, cloud consoles and all network rates.
- Binary prefix (GiB, TiB)
- IEC 80000-13 prefixes based on powers of two: 1 GiB = 2³⁰ = 1,073,741,824 bytes. Used by most operating systems, often mislabelled as GB.
- Per-stream ceiling
- The maximum a single TCP connection can achieve on a path, equal to the window size divided by the round-trip time. Parallel streams multiply it.