redzilla
All tools
Performance

TCP Throughput / BDP

Enter the bandwidth, the RTT and the TCP window size and compute the BDP, the real throughput limited by the window and the recommended window to fill the link. On high-latency links the window must be ≥ BDP to use the full bandwidth.

Mbps
ms
KB

Without scaling, the classic maximum is 64 KB. With window scaling (RFC 7323) it goes much higher.

%

If it is > 0, the Mathis limit (MSS=1460) is added as a reference.

Examples
redzilla.cl — tcp
 
BDP (bandwidth × delay product)
Throughput with this window
Recommended window
to saturate the link
BDP
Throughput
Optimal window

Diagnosis

How it is calculated · BDP, window and Mathis

1. BDP (bytes) = BW × RTT / 8, with BW in bps and RTT in seconds. It is the amount of data "in flight" needed to fill the link.

2. Throughput limited by the window: (window × 8) / RTT. A fixed window only lets you send those bytes per RTT.

3. To saturate the link, the window must be ≥ BDP. On high-BDP links (lots of latency or bandwidth), 64 KB without scaling severely limits performance.

4. With loss p > 0, the Mathis limit ≈ (MSS × 8) / (RTT × √p) bounds classic TCP throughput, independent of the window.

Runs locally in your browser · no sign-up · nothing leaves your browser.

How it works

The calculator takes the link bandwidth (Mbps), the RTT (round-trip latency, in ms) and the TCP window size (KB), and returns three results: the BDP or bandwidth-delay product (BDP = BW × RTT / 8, in bytes), the actual throughput that window allows (window × 8 / RTT, capped at the physical bandwidth) and the recommended window to saturate the link, which is exactly the BDP.

The logic is TCP itself: a connection can only keep as many bytes in flight as its window, and those bytes take one RTT to be acknowledged, so on high-latency links a small window wastes bandwidth (which is why RFC 7323 window scaling exists). If you also enter a loss percentage, the tool adds the Mathis limit: throughput ≈ (MSS × 8) / (RTT × √p) with a 1460-byte MSS, an upper bound for classic TCP (Reno/NewReno) under packet loss.

Example: 100 Mbps WAN with 80 ms RTT and a 64 KB window

  1. BDP: 100,000,000 × 0.08 / 8 = 1,000,000 bytes ≈ 977 KB. That much data must be in flight to fill the link.
  2. Throughput with 64 KB: 65,536 × 8 / 0.08 ≈ 6.55 Mbps.
  3. Verdict: the connection uses only 7% of the link. With window scaling and a window around 977 KB, the full 100 Mbps would be usable.

Frequently asked questions

Why is my transfer slow even though the link has plenty of bandwidth?
Almost always because of the bandwidth-delay product: with 80 ms of RTT and a 64 KB window, TCP cannot exceed about 6.5 Mbps even if the link is 100 Mbps or 1 Gbps. The fix is a larger window (window scaling, operating system buffers) or several parallel connections.
What is the BDP and what is it for?
The bandwidth-delay product is the amount of data that fits in transit inside the link: bandwidth times RTT, divided by 8 to express it in bytes. It is the minimum TCP window (and buffer) size needed to saturate the link. A 50 Mbps satellite link with 600 ms RTT has a BDP of 3.75 MB, far above the classic 64 KB.
How much does packet loss hurt TCP throughput?
Much more than intuition suggests, because it enters as a square root: the Mathis formula says the maximum throughput is roughly MSS × 8 divided by RTT × √p. With 80 ms RTT and only 0.1% loss, classic TCP is capped at about 4.6 Mbps, no matter how large the window or the link. Modern congestion controls such as BBR or CUBIC tolerate loss much better.
Why is the classic TCP window 64 KB?
Because the window field in the TCP header is 16 bits wide, with a maximum of 65,535 bytes. The window scaling option (RFC 7323) multiplies that value by a power of 2 negotiated when the connection opens and allows windows up to 1 GB. Every modern operating system enables it by default, but firewalls or legacy devices can break the negotiation.
Was this tool useful?
Disclaimer We take great care to keep every tool accurate and review it thoroughly; even so, we can't guarantee it is free of errors or take responsibility for how the results are used. We recommend double-checking anything critical.
Found an error? Let us know →