Data Transfer Time Calculator

Work out how long moving a given volume of data takes at a given link speed, including real-world efficiency overhead.

Inputs

Data volume

Volume unit

Link speed

Speed unit

Achieved throughput

Share of line rate you actually sustain. 60-80% is realistic over WAN.

Results

Transfer time: 1d 7h 44m
Total seconds: 114,286s
Sustained throughput: 87.5MB/s
Effective bit rate: 0.700Gbps

Uses decimal units: 1 TB = 10^12 bytes, 1 Gbps = 10^9 bits/s, consistent with how storage and network equipment is specified.

Bits, bytes and the factor of eight

Storage is measured in bytes; network links are rated in bits per second. The conversion is the first place estimates go wrong:

Time (s) = (bytes × 8) ÷ (bits per second × efficiency)

A 1 Gbps link moves 125 megabytes per second at best, not 1000. Ten terabytes over a perfect 1 Gbps link takes 80,000 seconds — 22 hours. Nobody gets a perfect link, which is what the efficiency figure is for.

Decimal or binary units

This calculator uses decimal units, because that is how both storage vendors and network equipment are specified: 1 TB is 10¹² bytes and 1 Gbps is 10⁹ bits per second. Operating systems often report binary units (1 TiB = 2⁴⁰bytes) while still calling them "TB", which introduces about a 10% discrepancy. If your figure came from a filesystem, expect the real transfer to take roughly 10% longer than the arithmetic here suggests.

Why you never get line rate

The efficiency percentage covers a stack of unavoidable overheads:

Protocol overhead. Ethernet, IP and TCP headers consume roughly 5% of a full-size frame. Small packets are far worse.
TCP window and latency. This is usually the dominant factor over distance. Throughput is limited to window size divided by round-trip time — so a single TCP stream with a 64 KB window over a 100 ms RTT link tops out around 5 Mbps regardless of how fast the link is. Window scaling and parallel streams exist precisely to work around this.
Storage. The source disk or the destination array is frequently slower than the network. Copying many small files is especially punishing, since per-file overhead dominates.
Contention. Production traffic shares the link. Bulk transfers rarely get exclusive use of it.

For planning: 90-95% on a clean LAN, 70-80% on a well-tuned WAN, 50-70% across the public internet, and lower still for many small files.

Reference times at 100% efficiency

Volume	1 Gbps	10 Gbps	100 Gbps
1 TB	2h 13m	13m	1m 20s
10 TB	22h 13m	2h 13m	13m
100 TB	9d 6h	22h 13m	2h 13m
1 PB	92d 14h	9d 6h	22h 13m

Divide by your realistic efficiency to get a usable figure. At 70%, that 1 PB over 10 Gbps becomes just over 13 days.

When to ship disks instead

There is a threshold beyond which physical shipping wins, and it arrives sooner than people expect. A courier moving a box of drives across a continent overnight represents an enormous effective bandwidth — this is why every major cloud provider offers a physical data import appliance.

As a rough rule: if the calculated transfer exceeds about a week, seriously price the physical option. Account for the time to copy data onto the drives at both ends, which is itself a transfer this calculator can estimate, and for encryption in transit — a lost drive is a reportable breach in a way that a failed rsync is not.

Practical ways to go faster

Parallel streams. Multiple concurrent connections sidestep the single-stream window limit. Tools like rclone and aspera exist for this reason.
Compress first, if the data is compressible and CPU is cheaper than bandwidth.
Transfer deltas, not the whole set, on repeat synchronisations.
Tar many small files into fewer large ones before sending, to eliminate per-file overhead.