Same building ~1 ms · same country ~10–30 ms · across an ocean ~80–150 ms.
Whichever end is slower — reading the file or writing it. Sustained sequential speed, not the burst figure on the box.
Everything not modelled above: a busy Wi-Fi channel, a throttled server, someone else streaming. Protocol overhead is not in here — that is computed from the frame size.
Time is size divided by throughput, and the division is trivial. The interesting part is that the number you divide by is almost never the number on the bill, because four separate ceilings sit above every transfer and only the lowest of them matters. Protocol overhead is arithmetic: a 1500-byte frame carries 1460 bytes of payload and costs 1538 bytes on the wire, so a gigabit link tops out at 949 Mbps before anything goes wrong. The TCP window caps you at one window per round trip, so window ÷ latency is a hard ceiling no matter how fat the pipe. The disk at whichever end is slower cannot absorb data faster than it can write it. And congestion takes whatever is left. This page computes all four and tells you which one is actually holding you back — because upgrading anything else changes nothing.
A 15 GB film over a 500 Mbps line, 10 ms away, with a default 64 KB window. The link could carry 451 Mbps of payload — but 64 KB every 10 ms is only 52 Mbps, so that is what you get, and the transfer takes 38 minutes instead of four and a half.
The fix is not a faster line. Opening the window to 1 MB takes the same transfer to 4 minutes 26 seconds on the same connection. Note that 512 KB is not enough — the bandwidth-delay product here is 610 KB, and a window has to beat that number rather than merely look large.
ISPs advertise megabits (Mbps). File sizes are usually megabytes (MB). Divide Mbps by 8 for ideal MB/s, so 100 Mbps is about 12.5 MB/s. Roughly half the complaints about a connection being slower than advertised are this factor of eight.
How much data is in flight between you and the far end at any moment — speed multiplied by round-trip time. A 1 Gbps link 10 ms away holds about 1.2 MB of data somewhere on the wire. TCP will not send more than one window before it hears back, so if your window is smaller than that number, the link sits idle waiting for acknowledgements. That is why the same file moves faster to a server down the road than to one across the Atlantic on the identical connection.
Because each stream gets its own window, so n streams multiply the window ceiling by n. It is the standard workaround for a long fat pipe and it is what download managers and tools like rsync’s parallel modes are doing. It does not help at all when the disk or the link is the binding limit — you are then just dividing the same bottleneck between more connections.
They take protocol overhead from about 5.1% down to 0.9%, so roughly 4% more throughput. That is real but small, and it is worth having only where you control both ends and everything in between — a storage network or a datacentre link. Over the internet a single device in the path with a 1500-byte limit undoes it.
The link, just. A 7200 rpm drive at 120 MB/s is 960 Mbps, and a gigabit link delivers about 930 Mbps of payload, so the disk is not quite the bottleneck — which is the opposite of what most people assume. Drop to an SD card at 90 MB/s and it absolutely is.
Sooner than you would think. A 1 TB drive sent next-day moves data at an effective 93 Mbps, so it beats any connection slower than that. At 20 TB the courier is doing 1.9 Gbps and beats almost anything you can buy. The page works out the crossover for whatever size you have entered.
A steady transfer at one throughput, with sizes in decimal units (1 GB = 1,000,000,000 bytes, matching how drives and ISPs count), and one large file. Protocol overhead and the window ceiling are exact arithmetic; the disk figures are typical sustained speeds for a class of device rather than a measurement of yours, and the congestion allowance is a number you set, not a model. Not modelled: TCP slow start, so the first seconds of any real transfer are slower than this says; retransmission and packet loss; per-connection throttling at the far end; per-file overhead, which dominates when you are moving thousands of small files rather than one big one; a link whose speed varies while you use it; and encryption or compression, either of which can move the bottleneck to the processor. Treat the answer as the best case for the conditions you described.
Use the Internet Speed Test for actual throughput and latency on your connection, then bring both numbers back here.
Releases in which this page changed, newest last. Derived from the archived copy of every release, not from notes written afterwards — so it reflects what actually shipped. Site-wide passes are left out; they are in the full changelog.