TCP Throughput Calculator (Mathis Formula)

The most surprising thing about TCP is how it gets slower as the network gets longer. A 1 Gbps link with 100 ms round-trip time can carry a single TCP connection at only a fraction of its physical capacity, even with zero packet loss, because of how TCP’s sliding window interacts with the speed of light. Add even a tiny amount of packet loss and the throughput falls off a cliff.

Three throughput limits, whichever is smallest wins:

A TCP connection’s actual throughput is bounded by three independent factors:

1. The link’s raw physical bandwidth.
2. The receiver’s TCP window divided by the round-trip time (the window-limited rate).
3. The Mathis-formula limit set by packet loss.

Whichever is smallest sets the actual achievable rate.

Window-limited throughput (no packet loss):

Throughput_max = Window / RTT

A 64 KB window over a 100 ms RTT gives 65,536 × 8 / 0.1 = 5.24 Mbps. That’s the absolute maximum a single connection can pump even on a 100 Gbps link. The fix is a larger window — modern Linux defaults to ~16 MB max with autotuning, giving 1.3 Gbps on the same path. Pre-2003 systems were stuck at 64 KB.

Bandwidth-delay product (BDP):

BDP = Bandwidth × RTT

This is the amount of data “in flight” at any moment when the link is saturated. A 1 Gbps link with 80 ms RTT has BDP = 10 MB. Your TCP window must be at least this large to fully use the link; smaller windows leave bandwidth on the table. Networks with high BDP are called “long fat networks” or LFNs.

Mathis formula (loss-limited):

Throughput ≈ (MSS / RTT) × √(3/2) / √p ≈ (MSS / RTT) × (1 / √p)

Where MSS is the maximum segment size in bytes (typically 1460 for Ethernet), RTT is the round-trip time in seconds, and p is the packet loss probability (0 to 1). The simpler 1/√p form is commonly used as a first estimate; the more precise constant √(3/2) ≈ 1.22 comes from a careful analysis of TCP Reno’s congestion avoidance phase.

The Mathis formula says throughput scales inversely with both RTT and the square root of loss. A doubling of loss costs you about 30% of throughput; a 100× increase in loss (from 0.01% to 1%) drops throughput by a factor of 10.

Worked example, transatlantic link:

A connection from New York to London has an MSS of 1460 bytes, RTT of 80 ms (0.08 s), and 0.05% packet loss (p = 0.0005).

Throughput ≈ (1460 / 0.08) × (1 / √0.0005) = 18,250 × 44.72 = 816,193 bytes/s ≈ 6.5 Mbps

That’s the per-connection upper bound. To saturate a 1 Gbps transatlantic link, you would need about 150 parallel TCP connections — which is why CDNs and large file transfers use parallelism.

Worked example, lossy WiFi:

Same MSS, 50 ms RTT (local network), 2% packet loss:

Throughput ≈ (1460 / 0.05) × (1 / √0.02) = 29,200 × 7.07 = 206,500 bytes/s ≈ 1.65 Mbps

A WiFi link advertised as 866 Mbps delivers 1.65 Mbps per connection at 2% loss. This is why packet loss is the death of TCP throughput, even on apparently fast links.

Why √p, not p?

TCP’s congestion avoidance uses additive increase, multiplicative decrease (AIMD). The window grows by 1 MSS per RTT, then halves on loss. The average window oscillates around a sawtooth pattern. Integrating the area under the sawtooth gives the average throughput, which works out to be proportional to 1/√p, not 1/p. The √(3/2) constant comes from the geometry of that integration.

Modern variants beat Mathis:

The Mathis formula assumes TCP Reno-style congestion control. Modern variants do better:

• TCP CUBIC (Linux default since 2006): cubic window growth instead of linear. Throughput scales as p^(-3/4) instead of p^(-1/2). For p = 1%, CUBIC achieves about 3× the Mathis throughput.
• TCP BBR (Google, 2016): Doesn’t use packet loss as a congestion signal at all. Measures bandwidth and RTT directly. Can saturate paths Mathis would predict to be near-unusable.
• QUIC (HTTP/3): Application-layer congestion control over UDP. Faster recovery from loss, no head-of-line blocking on multiplexed streams.

The Mathis formula is still useful for lower-bound estimation and for understanding why naive TCP performs the way it does. Real production networks routinely exceed it.

Practical implications:

• A 1% increase in packet loss does not cost you 1% of throughput; on TCP Reno it costs about 30% (because √(1.01/1) ≈ 1.005, but the throughput ∝ 1/√p makes the effect compound).
• Halving RTT doubles throughput — directly. This is why CDNs work: they don’t increase bandwidth, they reduce RTT.
• Two parallel TCP connections give you 2× throughput up to the physical link capacity. This is how programs like aria2 and IDM accelerate downloads.
• An ssh/scp file transfer over a long path is almost certainly window-limited, not loss-limited. Set TCP buffer sizes (net.core.rmem_max, net.core.wmem_max on Linux) to BDP for maximum throughput.

Edge cases:

• Zero loss (p → 0): the Mathis formula gives infinite throughput. The window limit takes over.
• Very high loss (p > 10%): TCP essentially stops working; the formula’s asymptotic assumptions break down. Real connections retransmit so much that effective throughput becomes erratic.
• Wireless and satellite: bursty errors and high RTT make Mathis pessimistic by a wide margin if FEC and ARQ are at the link layer.