See why one TCP flow is slower than your link. Enter RTT, packet loss, MTU and window size to find the real ceiling and what limits it.
A single TCP connection rarely fills a fast link. Its speed is held down by the round-trip time, by any packet loss, and by the size of the receive window. This calculator takes your round-trip time, loss rate, MTU and, optionally, a fixed receive window, and works out the ceiling for one flow. It compares three limits (the link speed, the window limit of window divided by round-trip time, and the loss limit from the Mathis equation) and names the one that applies.
The loss limit uses the Mathis model, which estimates steady-state TCP throughput as the maximum segment size divided by the round-trip time, multiplied by 1.22 and divided by the square root of the loss rate. For example, with a 150 ms round trip, 0.1% loss and a 1500-byte MTU, one flow tops out near 3 Mbps, however fast the link is. A sensitivity table shows how the ceiling moves as loss and round-trip time change, so you can see whether fixing loss or shortening the path helps more.
Use it to explain slow single-stream transfers over long distances, to decide whether more bandwidth will help, and to judge whether parallel streams or a different congestion control algorithm is worth trying. The Mathis model is an approximation. Modern congestion control such as CUBIC and BBR can behave differently, so check the result against a real measurement.
One TCP connection is held back by whichever of three limits is lowest.
With a 150 ms round trip, 0.1% loss and a 1500-byte MTU, one connection tops out near 3 Mbps on a 1 Gbps link. The calculator shows all three limits side by side and names the one that applies.
Match the fix to the limiter.
The table below the result shows the ceiling as loss and round-trip time change around your inputs. Look for the row where the ceiling crosses your link speed. That tells you how much loss or delay you can tolerate before the connection stops filling the link, and whether reducing loss or shortening the path gets you there faster.
A single TCP connection is limited by the round-trip time, packet loss and the receive window, not just by the link. On long paths or lossy links one connection can use only a small share of a fast line. Enter your round-trip time and loss rate to see the ceiling for one flow.
It estimates the steady-state throughput of a loss-limited TCP connection as (MSS ÷ RTT) × (1.22 ÷ √p), where p is the packet loss rate. It shows why loss and distance together cut speed so sharply: doubling the round-trip time halves the ceiling, and loss matters in proportion to its square root.
At a 50 ms round trip and a 1460-byte MSS, 1% loss limits one connection to about 2.8 Mbps, 0.1% to about 9 Mbps, and 0.01% to about 28 Mbps. Even small loss rates matter on a fast link.
It takes the MTU you enter and subtracts 40 bytes for the IPv4 and TCP headers, so a 1500-byte MTU gives an MSS of 1460. If your path uses a tunnel, find the effective MTU first with the MTU calculator.
It models classic loss-based TCP such as Reno. CUBIC and BBR respond to loss differently, and BBR in particular is less sensitive to random loss, so treat the result as a guide and confirm with a real measurement. QUIC with a loss-based congestion controller behaves similarly to TCP.
Often yes. Each connection has its own ceiling, so downloads split across several connections can add up to much more, until the link itself or a shared bottleneck is the limit. This is why download managers and some transfer tools open multiple streams.
Calculate optimal TCP window sizes, bandwidth-delay product, and buffer settings. Generate OS-specific tuning commands to maximize throughput on high-latency links.
Calculate network latency, ping distance, and data transfer times between geographic locations. Free tool for network engineers.
Estimate how long a file takes to download or upload, and find out whether the link, the TCP window or packet loss is the bottleneck.
Work out the effective MTU and the TCP MSS to set after VPN or tunnel overhead, and whether a packet will be fragmented.
Estimate the circuit size a site needs from user count, application mix, busy-hour concurrency and headroom.