Solve for transfer time, the rate you need, or how much data fits — with the byte convention named and a latency check for long-distance links.
Signalling rates are the figure the interface is named for, and the two families name different things. USB 3.0 and SATA III quote the rate on the wire, where 8b/10b encoding carries eight payload bits in every ten symbols — so four fifths of the headline is the ceiling before any protocol overhead at all. The Ethernet rows carry a dash because their named rate is ALREADY the payload rate; USB4 and Thunderbolt carry one because their encoding overhead is not a single fixed ratio.
| Interface | Signalling rate | Payload ceiling |
|---|---|---|
| Gigabit Ethernet | 1.00 Gbps | — |
| USB 3.0 (SuperSpeed) | 5.00 Gbps | 4.00 Gbps |
| SATA III | 6.00 Gbps | 4.80 Gbps |
| 10 Gigabit Ethernet | 10.00 Gbps | — |
| USB4 | 40.00 Gbps | — |
| Thunderbolt 4 | 40.00 Gbps | — |
Protocol overhead alone is computable: at the usual 1500-byte MTU, an IPv4 packet spends 20 bytes on its IP header and 20 on the TCP header, leaving 1460 bytes of payload. That is 97.3% of the IP packet, or 94.9% of everything Ethernet puts on the wire once framing, preamble and the interframe gap are counted. Storage interfaces lose more again to line coding. Everything below that comes from congestion, disk speed at one end or the other, and distance — which no formula predicts for you, so the efficiency field is yours to set from a measurement rather than a number we invent.
You might also find these calculators useful
See how long a download takes, in GB or GiB
How long a file takes to upload, in GB or GiB
How much internet speed you need, and how long a transfer takes
Find the bandwidth-delay product and the TCP window a link needs
A transfer has three numbers — how much data, how fast the link is, and how long you have — and any two of them give the third. Pick the one you are missing. This calculator names the byte convention it used, lets you scale the link rate down to what you actually measure, and, on a long-distance link, tells you whether latency is what is holding the transfer back.
Transfer time is the data size in bits divided by the rate in bits per second. The arithmetic is trivial; the traps are in the units. A size in TB can mean 10¹² bytes or 2⁴⁰, a 10% difference at that magnitude, so the unit you pick here says which. Rates in bits per second are always decimal — Mbps has meant 10⁶ bit/s since long before the binary prefixes existed — which is why a 100 Mbps link delivers 12.5 MB/s and not 11.92.
The three solves
Check a nightly job finishes before the working day, at the efficiency the last run actually achieved.
Size a cutover before you commit to it, and switch to the rate solve when the deadline is fixed and the link is not.
Work out whether distance or bandwidth is the binding constraint before paying for more of the wrong one.
Compare the payload ceiling of USB, SATA and Ethernet rather than the headline number printed on the box.
1 TB decimal and 1 TiB binary are 10% apart. On a backup window measured in hours, that is the difference between finishing and overrunning.
Line coding, protocol headers, disk speed and congestion all sit between the signalling rate and the bytes that land. The efficiency field is where you put what you actually measured.
TCP can only have one window of data in flight per round trip. Over a long link that ceiling can bite long before the link rate does, and it is invisible in a plain size-over-rate calculation.
“We have to move 4 TB before Monday” is a provisioning question. Switching the solve answers it directly instead of making you guess rates until the time looks right.
Twenty-two hours and thirteen minutes, reading TB as the decimal terabyte: 10¹² bytes is 8×10¹² bits, divided by 10⁸ bits per second gives 80,000 seconds. If your 1 TB came from a file manager it is a tebibyte, 2⁴⁰ bytes, and the same link takes 24 hours 26 minutes — two and a quarter hours longer for a figure that looks identical on screen. The calculator prints whichever reading you chose and tells you what the other one would have given.
Mbps is megabits per second and MB/s is megabytes per second, and there are eight bits in a byte, so 100 Mbps is 12.5 MB/s. Both prefixes are decimal here: a megabit is 10⁶ bits and a megabyte on a network rate is 10⁶ bytes. That is why the throughput tile on this page reads 12.5 MB/s for a 100 Mbps link rather than 11.92, which is what you get if you divide by 1,048,576 instead.
Four reasons, in the order worth checking. Line coding: a 5 Gbps USB 3.0 link carries eight payload bits in every ten symbols, so 4 Gbps is its ceiling before anything else. Protocol headers: IP and TCP cost about 2.7% at a 1500-byte MTU. The disk at one end, which on a bulk copy is very often the real limit. And distance — see the next answer. Enter what you measured into the efficiency field and the calculator will use it.
It can decide it. TCP sends at most one receive window of data per round trip, so throughput is capped at window ÷ RTT no matter how fast the link is. Filling a 100 Mbps link at 80 ms needs a megabyte in flight; the 64 KiB window TCP uses before any scaling caps that path at 6.55 Mbps. RFC 7323 window scaling has been on by default for years and normally removes the problem, which is why this calculator reports the requirement rather than quietly derating your answer — but if a transfer is running at a small fraction of the link rate over a long path, the window is the first thing to look at.
Use the one your figure came from. Drive manufacturers, cloud providers and contracts quote decimal TB. Operating systems, file managers and most storage arrays report binary TiB, often while printing the letters “TB”. The two are 10% apart at terabyte scale, so the safest habit is to check where the number came from before typing it, and this calculator shows both readings beside every answer.