TCP Throughput & BDP Calculator

Calculate the bandwidth-delay product and the maximum a single TCP stream can achieve given window size, latency and packet loss.

Calculator Bandwidth & Data Runs in your browser

Result

Bandwidth-delay product

9.54 MiB

in-flight data needed to fill the pipe

Required window size

9.54 MiB

minimum for full rate

Window-limited throughput

6.55 Mbit/s

Loss-limited throughput

17.8 Mbit/s

Achievable single stream

6.55 Mbit/s

Bottleneck

TCP window size

Window size versus throughput at 80 ms RTT

Window size	Max throughput	% of link
16 KiB	1.64 Mbit/s	0.2%
32 KiB	3.28 Mbit/s	0.3%
64 KiB	6.55 Mbit/s	0.7%
128 KiB	13.1 Mbit/s	1.3%
256 KiB	26.2 Mbit/s	2.6%
512 KiB	52.4 Mbit/s	5.2%
1024 KiB	104.9 Mbit/s	10.5%
2048 KiB	209.7 Mbit/s	21%

The maths

BDP formula: BDP = capacity (bit/s) × RTT (s) ÷ 8
Window-limited rate: throughput = window (bits) ÷ RTT (s)
Mathis equation: throughput ≈ (MSS × 1.22) ÷ (RTT × √loss)

Window too small

A 64 KiB window cannot fill this link at 80 ms RTT - you need at least 9.54 MiB. Enable TCP window scaling (RFC 7323); without it the 16-bit window field caps you at 64 KiB regardless of the tuning you apply.

Loss is the bottleneck

At 0.01% loss, a single TCP stream is capped near 17.8 Mbit/s no matter how much capacity exists. On long paths, loss is far more damaging than latency alone - chase the loss first.

About TCP Throughput & BDP Calculator

A single TCP connection is limited by three things: the link, the amount of unacknowledged data allowed in flight, and packet loss. On a long path the second and third dominate, which is why a 10 Gbit/s intercontinental link can deliver 60 Mbit/s per stream and still be working exactly as designed.

Tuning the stack for a long path

Three things have to line up. Window scaling must be enabled at both ends and not stripped by a middlebox, or the window is capped at 64 KiB regardless of buffer settings. Socket buffers must be allowed to grow to at least the bandwidth-delay product: on Linux that means raising net.ipv4.tcp_rmem and tcp_wmem maxima, since autotuning will not exceed them. And congestion control should be BBR rather than CUBIC on paths with low but non-zero loss, because CUBIC treats every loss as congestion and backs off.

Long fat networks

The bandwidth-delay product is how much data must be in flight to keep the pipe full. At 1 Gbit/s and 80 ms that is about 10 MiB - far beyond the 64 KiB an unscaled TCP window can address. Window scaling fixes the ceiling; loss is harder, because TCP's congestion response means throughput falls with the square root of the loss rate. A 0.01% loss on a 100 ms path caps a stream near 180 Mbit/s.

Common use cases

Explaining why a backup across a WAN link does not use the bandwidth you bought.
Sizing window and buffer tuning for a data replication path.
Deciding whether parallel streams will help - they will, if the limit is window rather than loss.

Edge cases and gotchas

Window scaling must be enabled at both ends; a middlebox stripping the option silently caps you at 64 KiB.
Loss below 0.1% is invisible on a latency graph and devastating for single-stream throughput.

Frequently asked questions

Will more parallel streams fix it?

If the limit is the window, yes - n streams get roughly n times the throughput. If the limit is loss caused by congestion, more streams mostly add more loss.

Which congestion control should I use?

BBR is markedly better than CUBIC on long paths with low but non-zero loss, because it does not treat every loss as congestion. It is the standard answer for WAN replication today.