TCP Throughput From Latency Calculator

Work out tcp throughput from latency instantly with clear inputs, formula shown and shareable results.

About TCP Throughput From Latency Calculator

A single TCP stream can have at most one window of data outstanding per round trip, so throughput is window divided by RTT. Loss imposes a second ceiling described by the Mathis formula, MSS x 1.22 / (RTT x sqrt(loss)), because congestion control halves the window on every loss event. On long fat links, either constraint can dominate.

Formula

TCP throughput limits

window limit = window bytes x 8 / RTT; loss limit = MSS x 8 x 1.22 / (RTT x sqrt(loss)); actual = the lower of the two

Worked example

With the default values below, TCP Throughput From Latency Calculator returns Achievable TCP throughput of 17.81. Change any input above and every figure here is recalculated in your browser.

Inputs used

TCP window sizeminimum 1 KB: 256 KB
Round-trip timeminimum 0.1 ms: 80 ms
Packet lossaccepts 0–10 %: 0.01 %
Maximum segment sizeaccepts 64–9,000 bytes: 1,460 bytes

Results

Achievable TCP throughput: 17.81 Mbps
Window and RTT limit: 26.21 Mbps
Loss-limited rate (Mathis formula): 17.81 Mbps
Binding constraint: Packet loss - congestion control caps the rate

Step by step

1Values used
2TCP throughput limits
3Achievable TCP throughput= 17.81 Mbps
4Window and RTT limit= 26.21 Mbps
5Loss-limited rate (Mathis formula)= 17.81 Mbps
6Binding constraint= Packet loss - congestion control caps the rate

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

Why does one stream not fill a fast long-distance link?

Because window over RTT caps it. A 256 KB window over an 80 ms path yields about 26 Mbps regardless of the link being 10 Gbps — window scaling or parallel streams are required.

Does BBR change this?

Yes. BBR models bandwidth and RTT rather than treating loss as congestion, so it sustains much higher rates on lossy long paths than loss-based algorithms like CUBIC.