Someone asks how long it will take to push a 100 GB file over the new 1 Gbps link, and the back-of-the-envelope answer comes fast: "a gigabit a second, so a hundred seconds, give or take." It sounds reasonable. It is also off by a factor of eight before you have even accounted for anything real. That single slip is behind a surprising number of blown maintenance windows and migrations that quietly run into the next day.
Get the units right and you can plan around a transfer instead of being surprised by it. The Transfer Time Calculator does the arithmetic for you, but it is worth understanding what it is telling you, because the number it prints is a floor, not a promise. This guide walks through the two ideas you need to read that number correctly: the difference between bits and bytes, and the gap between the speed on the box and the speed you actually get.
Bits and bytes are not the same unit
Here is the mistake that costs the factor of eight. Files are measured in bytes, capital B: kilobytes, megabytes, gigabytes, terabytes. Network links are rated in bits per second, lowercase b: Mbps, Gbps. They look almost identical written down, and they are related by a factor that is easy to drop.
1 Byte = 8 bits
So a "1 gigabit" link does not move a gigabyte per second. Divide by eight: 1 Gbps / 8 = 125 MB/s. That is the ceiling. A few common conversions worth memorising:
| Link speed (bits/s) | Byte rate |
|---|---|
| 100 Mbps | 12.5 MB/s |
| 1 Gbps | 125 MB/s |
| 10 Gbps | 1.25 GB/s |
Note on units: the calculator uses SI, so 1 MB = 1,000,000 bytes and 1 GB = 1,000,000,000 bytes. That keeps the byte-to-bit conversion clean and matches how link speeds and drive capacities are advertised.
Bandwidth, throughput, and goodput
Fix the units and you get an honest theoretical figure. You still will not hit it, and the reason is that "network speed" is really three different numbers wearing the same name.
- Bandwidth is the rated capacity of the pipe. It is what the link can do under ideal conditions.
- Throughput is what is actually moving through it at any moment, including retransmissions and protocol framing.
- Goodput is the useful part: your application's data, stripped of all the packaging around it.
Goodput is always the smallest of the three, and a handful of things pull it down:
- Protocol overhead. Every packet carries Ethernet, IP, and TCP headers wrapped around your data. On a standard 1500-byte MTU that housekeeping eats a few percent of the line before your payload gets a seat.
- Latency and TCP windowing. TCP sends a batch of data, then waits for the receiver to acknowledge it. If that window is smaller than the link can hold in flight, the connection spends part of every round trip idle, waiting on ACKs. The longer the distance, the more this bites.
- Packet loss. TCP reads loss as congestion and backs off hard, roughly halving its sending rate. Even 1% loss on a long path can gut throughput.
- Disk at the far end. A 10 Gbps link wants to deliver 1.25 GB/s. If the receiving array only writes 150 MB/s, the network is no longer your bottleneck; the disk is.
You do not need to model all of this to use it. Just treat the theoretical time as the best case and pad it. A workable rule of thumb: plan for roughly 10 to 20% longer than the ideal figure on a clean local link, and more when the path is long-haul or lossy.
The number the calculator gives you
Under the hood the estimate is one formula:
T = (size x 8) / bandwidth
Your file size in bytes, times eight to turn it into bits, divided by the link speed in bits per second. That is the ideal transfer time and nothing else; the tool does not fold in an efficiency guess, because your real efficiency depends on your path, not on an average. It shows the clean floor and a reminder that reality runs slower. Interpreting the gap is your job, and now you have the background to do it.
Here is what that floor looks like for a 1 TB file across common links:
| Link speed | Theoretical time for 1 TB |
|---|---|
| 10 Mbps | ~9 days 6 hours |
| 100 Mbps | ~22 hours 13 min |
| 1 Gbps | ~2 hours 13 min |
| 10 Gbps | ~13 min 20 sec |
Add your 10 to 20% mentally and you have a planning number you can defend.
Two places this actually matters
When shipping a box beats the wire. Suppose you need to move 500 TB into the cloud. Over a dedicated 1 Gbps link the theoretical time is around 46 days, and that is before overhead. A physical transfer appliance like AWS Snowball or Azure Data Box gets the same data there in a few days end to end. Run the numbers before you assume the internet is faster; past a certain volume, a courier wins. If you are laying out the network for the receiving end, the Subnet Calculator helps you plan the addressing.
When the backup does not fit its window. Backing up 2 TB over a 500 Mbps link is roughly 9 hours in theory, comfortably past a 4-hour maintenance window even before you pad it. That tells you the answer up front: turn on deduplication and compression, move to incrementals, or get a fatter pipe. And since restore speed is bounded by how fast the target array can write, the RAID Calculator is worth a look when you size that storage.
The short version
Convert bytes to bits before you do any mental math, treat the calculated time as a floor, and add a margin for overhead and latency. Do that and your migration and backup plans stop being optimistic guesses and start being schedules you can actually keep.