TCP throughput and data transfer time calculator
Your link says 1 Gbit/s, yet the copy to the remote site tops out at a few dozen Mbit/s? Latency, TCP window and packet loss set a ceiling no subscription removes. This calculator puts a number on it, along with the transfer time.
The calculation runs in your browser: nothing you type is sent anywhere.
TCP throughput, bandwidth-delay product and transfer time
Result
Single TCP stream throughput
1,000 Mbit/s
limited by the link
Bandwidth-delay product
2.38 MiB
2,500,000 bytes: the smallest window that fills the link
Transfer time, one stream
2 h 13 min
Excluding IP, TCP and Ethernet headers, which take a few more percent.
Link utilization
100%
Parallel streams to fill the link
1 stream
| Link bandwidth | 1,000 Mbit/s |
| Ceiling set by the window | 1,678 Mbit/s |
| Ceiling set by packet loss (Mathis) | none |
How the calculation works
TCP never sends more than one window of data without receiving an acknowledgement. As long as the window is smaller than what the link can hold, the sender waits. The calculator therefore takes the smallest of three ceilings: the link bandwidth, the one the window allows, and the one packet loss allows.
BDP (bytes) = bandwidth (bit/s) × RTT (s) / 8
window ceiling = window (bytes) × 8 / RTT
loss ceiling = (MSS × 8 / RTT) × √(3/2) / √p (Mathis et al., 1997)
single stream = min(link, window ceiling, loss ceiling)
streams needed = ⌈ link / min(window ceiling, loss ceiling) ⌉The effective window is the smaller of the two buffers: the send buffer on the sender, the receive buffer on the receiver. On Linux, autotuning grows them up to a ceiling: between 64 KiB and 4 MiB depending on RAM for sending (tcp_wmem), between 128 KiB and 32 MiB for receiving (tcp_rmem). Without the window scale option, the window cannot exceed 64 KiB.
The loss ceiling comes from the Mathis model: every loss cuts the congestion window, which then grows back by one segment per round trip. The longer the latency, the slower the recovery. The default MSS, 1,448 bytes, is a 1,500-byte MTU minus the IP (20), TCP (20) and timestamps option (12) headers.
Sources: Linux kernel ip-sysctl documentation (tcp_rmem, tcp_wmem), RFC 7323 (window scaling), Mathis, Semke, Mahdavi and Ott, "The macroscopic behavior of the TCP congestion avoidance algorithm", 1997.
Remote backups and offsite replication
An offsite backup always crosses some latency, and it is often latency, more than the subscribed bandwidth, that sets the duration. With the 4 MiB send window Linux allows by default, one stream is capped at 1.68 Gbit/s at 20 ms, but at 335 Mbit/s at 100 ms. Add 0.01% packet loss at 100 ms, and the ceiling drops to about 14 Mbit/s.
This is what plays out in replication between two Proxmox Backup Servers: the sync job transfers deduplicated chunks over HTTPS, hence over TCP, and hits the same ceilings. To check whether your backup to Nimbus fits in the night, the backup window calculator starts from your upload bandwidth and the data changed each day. This calculator explains why real throughput sometimes stays well below the subscribed bandwidth.
Shortening the path therefore pays off. We operate our own network, AS206014, from the Equinix PA3, PA4 and PA5 datacenters, connected to the France-IX, AMS-IX, DE-CIX, LINX and HopUS exchange points. The details are on our IP transit and BGP peering page (fr), and why we run our own network is explained on the page about our autonomous network AS206014.
After the calculation
Transfer time is only part of recovering from an incident. The RPO / RTO calculator adds it to detection, response and return to service, to put a number on real downtime. And to know how much data you will have to move, the ZFS and PBS storage calculator estimates the space a backup retention takes.
Frequently asked questions
How long does it take to transfer 1 TB over a 1 Gbit/s link?
About 2 h 13 min if a single TCP stream fills the link: 1,000 GB × 8 bits divided by 1,000 Mbit/s. IP, TCP and Ethernet headers add a few percent. Over 100 Mbit/s, the same data takes about 22 h 13 min. If the TCP window is too small or the link drops packets, a single stream does not reach that rate and the transfer takes longer.
What is the bandwidth-delay product (BDP)?
It is the amount of data "in flight" on the link: bandwidth multiplied by round-trip time. At 1 Gbit/s and 20 ms, the BDP is 2.5 million bytes, or 2.38 MiB. To fill the link, the sender must be able to send at least that much without waiting for an acknowledgement, so the TCP window must be at least as large as the BDP.
Why is my transfer capped well below my link speed?
A TCP stream never exceeds its window divided by the latency. With a 64 KiB window, without the window scaling option, a stream is capped at 26.2 Mbit/s at 20 ms of latency, whatever the link speed. Packet loss is the other common cause: at 20 ms, 0.1% loss limits a stream to about 22 Mbit/s according to the Mathis model.
How many parallel streams are needed to fill the link?
The link bandwidth divided by the ceiling of one stream, rounded up. On a 10 Gbit/s link at 20 ms, with the 4 MiB send window Linux allows by default, one stream is capped at 1.68 Gbit/s: you need 6. This is why replication and backup tools often open several connections.
Does this calculator replace a speed test?
No. It gives the theoretical ceilings set by window, latency and packet loss. Real throughput also depends on the congestion control algorithm (CUBIC, BBR), TCP slow start, and the CPU and disks at both ends. To measure, run a real transfer between the two machines and compare it with the ceiling calculated here.
Contact
Address
5 B RUE DES NOYERS, 95300 PONTOISE, FRANCE