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.
A 1500-byte frame carries 1460 bytes of payload and costs 1538 on the wire (94.93%), so a gigabit link tops out at 949 Mbps before anything goes wrong.
One window per round trip, so window ÷ latency is a hard ceiling however fat the pipe. It is the bandwidth-delay product, stated the other way round.
The slower disk at either end cannot absorb data faster than it can write it. Typical sustained speeds by class of device, not yours.
Takes whatever is left. A number you set, not a model. The lowest ceiling wins, and upgrading anything else changes nothing.
ISPs sell megabits; files are measured in megabytes. The factor of eight accounts for roughly half of all complaints that a connection is slower than advertised. 100 Mbps is 12.5 MB/s at absolute best.
A 1500-byte frame occupies 1538 bytes on the wire once framing and the inter-frame gap are counted, so a gigabit link tops out at 949 Mbps. Jumbo frames cut the tax to 0.86%, roughly 4% more throughput: real but small, and only worth having where you control both ends and everything between.
A 64 KB window over a 10 ms round trip is 52 Mbps no matter what you pay for, and over a 150 ms ocean hop it is 3.5 Mbps. The pipe is not full; it is idle, waiting for acknowledgements. It is why the same file moves faster to a server down the road than across the Atlantic.
Each stream gets its own window, so eight streams give eight times the ceiling. It works, and it is what download managers do, but only when the window is what binds. Against a slow disk it just divides the same bottleneck more ways.
120 MB/s is 960 Mbps against about 930 Mbps of payload on a gigabit link, so the disk is not quite the bottleneck: the opposite of what most people assume. An SD card at 90 MB/s absolutely is.
A 1 TB drive posted next-day moves data at an effective 93 Mbps, beating any connection slower than that. At 20 TB the courier is doing 1.9 Gbps. Bandwidth is cheap in bulk and latency is terrible, which is exactly what a lorry is. The page works out the crossover for your size.
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.