Estimate realistic TCP throughput using the Mathis congestion model and bandwidth-delay product. Analyze how round-trip time, packet loss, and window size limit network transfer speeds.
Overview
The TCP Throughput Calculator estimates the realistic throughput of a TCP connection using the Mathis congestion model and the bandwidth-delay product. It helps network engineers, sysadmins, and ISP staff understand how round-trip time, packet loss, segment size, and window size limit effective transfer speed.
Common Use Cases
Estimating real-world TCP throughput
Tuning TCP window sizes
Analyzing high-latency satellite links
Troubleshooting slow file transfers
WAN optimization planning
VPN throughput estimation
Satellite and long-haul link design
Explaining speed test results
TCP tuning for servers
Capacity planning for transfers
How to Use
1
Enter the nominal link rate in Mbps.
2
Enter the round-trip time in milliseconds.
3
Set the TCP segment size, typically 1460 bytes for Ethernet.
4
Enter the packet loss rate as a percentage.
5
Enter the TCP window size in kilobytes, typically 64 KB for older stacks.
6
Review the loss-limited, window-limited, and effective throughput together with the recommended window size.
Example Scenario
Long-Haul VPN Connection
A link with a 100 ms round-trip time and 0.1% packet loss is limited by the Mathis model to roughly 51 Mbps even if the underlying link is 1 Gbps. Increasing the TCP window size or reducing loss is needed to go faster.
Technical Notes
The Mathis model estimates congestion-limited throughput as 1.22 times MSS divided by RTT times the square root of the loss rate. It models TCP congestion avoidance behavior and applies to links that lose packets before saturating.
Throughput is also limited by the TCP window: the window in bytes divided by the RTT. A small window on a high-latency link caps throughput regardless of link speed.
The effective throughput is the minimum of the loss-limited value, the window-limited value, and the nominal link rate.
The bandwidth-delay product is the amount of data in transit at full speed. It equals the link rate multiplied by the RTT, and it defines the TCP window size needed to saturate the link.
Modern congestion control algorithms such as BBR and CUBIC can behave differently from the classic Mathis model, especially on low-loss and high-bandwidth links.
Packet loss on wired links is usually tiny, but wireless and congested links commonly see 0.1% to 1% loss which sharply cuts throughput.
Common Mistakes
Assuming the link rate is the achievable throughput
Using a default 64 KB window on high-latency links
Ignoring packet loss in throughput estimates
Forgetting the bandwidth-delay product when sizing windows
Comparing transfer speeds measured in MB/s with link speeds in Mbps
Expecting full link speed on satellite or congested links
Frequently Asked Questions
TCP throughput is limited by the lowest of the link rate, the congestion model, and the window size. Latency, packet loss, and a small window all cap real throughput.
It is a widely used formula estimating the maximum TCP throughput given round-trip time and packet loss: 1.22 x MSS divided by RTT x square root of loss.
It is the amount of unacknowledged data a connection can carry, equal to link speed multiplied by round-trip time. The TCP window should be at least this large to fill the link.
On high-latency links, yes. Modern operating systems use auto-tuning, but manually set windows smaller than the bandwidth-delay product will throttle throughput.
Speed tests usually run parallel connections, which hides per-connection limits. A single TCP stream can be much slower than the headline speed test number.