Hong Life CalculatorsUnderstanding the TCP throughput with packet loss calculator — concept and principle
This calculator estimates the maximum steady-state throughput of one TCP connection when packets are being lost, using the well-known Mathis formula. It explains why a path with a little loss and a long round-trip time can feel slow even on a fast link, and helps network engineers judge whether a loss rate is acceptable for a given transfer speed, for example across a WAN or VPN.
How it is calculated
Throughput ≤ (MSS ÷ RTT) × C ÷ √p, with C ≈ 1.22.
- MSS is the TCP payload per segment in bytes; it is multiplied by 8 to get bits.
- RTT is the round-trip time, entered in milliseconds and converted to seconds.
- p is the packet loss probability, entered as a percentage and divided by 100.
- The result is shown in Mbps (10^6 bit/s).
The principle
Classic TCP congestion control (Reno-style AIMD) grows its window by about one segment per RTT and halves it after each loss. Mathis, Semke, Mahdavi and Ott (1997) showed that with random, periodic losses this saw-tooth averages out to a window of about √(3/(2p)) segments, which gives the constant √1.5 ≈ 1.22. Throughput is window ÷ RTT, so it falls with the square root of loss and in direct proportion to RTT. Halving the RTT doubles the ceiling; cutting loss by a factor of 4 doubles it too.
Worked example
- Inputs: MSS 1,460 bytes, RTT 50 ms, loss 0.1%.
- MSS in bits: 1,460 × 8 = 11,680 bits.
- MSS ÷ RTT: 11,680 ÷ 0.05 = 233,600 bit/s.
- √p = √0.001 = 0.031623, so 1.22 ÷ 0.031623 = 38.580.
- Throughput: 233,600 × 38.580 = 9,012,238 bit/s ≈ 9.012 Mbps.
| RTT (ms) | Max throughput (Mbps) |
|---|---|
| 12.5 | 36.0489534 |
| 25 | 18.0244767 |
| 37.5 | 12.0163178 |
| 50 | 9.012238349 |
| 62.5 | 7.209790679 |
| 75 | 6.0081589 |
| 100 | 4.506119175 |
How to read the result
The number is a ceiling for one flow, independent of link speed. On a 1 Gbps path with 50 ms RTT and 0.1% loss, a single classic TCP stream cannot exceed about 9 Mbps. To reach higher speeds you need lower loss, lower RTT or several parallel flows. Loss well below 0.01% is often needed for multi-hundred-megabit single streams over long distances.
Common mistakes
- Entering loss as a fraction (0.001) when the field expects a percentage (0.1).
- Applying the formula to modern algorithms such as CUBIC or BBR, which respond to loss differently.
- Using it when the window or link speed is the real limit; the true rate is the smallest of all limits.
Frequently asked questions
Why does a little packet loss slow TCP so much?
Each loss halves the window, and rebuilding it takes many RTTs on long paths.
Does BBR follow this formula?
No. BBR models bandwidth and RTT directly and is much less sensitive to random loss.
Where does 1.22 come from?
It is √(3/2), from averaging the saw-tooth window of periodic loss.
Sources: Mathis, M., Semke, J., Mahdavi, J., Ott, T. (1997), The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm, ACM SIGCOMM Computer Communication Review 27(3) · IETF RFC 5681, TCP Congestion Control