Bandwidth-Delay Product Calculator

Formula: BDP bytes = bandwidth × RTT ÷ 8. Window-limited throughput = window × 8 ÷ RTT. Loss-limited throughput (Mathis et al.) = (MSS × 8 ÷ RTT) × √(3/2) ÷ √loss. Achievable = the smallest of link, window, and loss limits.

Worked example:A 1,000 Mbps path with 80 ms RTT has a 10,000,000-byte BDP (9.54 MiB). A 64 KiB window caps one flow at 6.55 Mbps, and the window needs a scale shift of at least 8.

Common mistake or edge case:Use round-trip time, not one-way latency, and distinguish decimal MB from binary MiB. The Mathis model assumes Reno-style congestion control; CUBIC and BBR behave differently under loss.

Additional official references:

• Mathis et al., The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm (ACM SIGCOMM CCR, 1997)
• RFC 6349 framework for TCP throughput testing

Read the supporting guide and worked examples.

Frequently asked questions

Why does a fast link still transfer slowly over a long distance?

TCP can only have one window of unacknowledged data in flight. If the window is smaller than the bandwidth-delay product, the sender stalls waiting for acknowledgments however fast the link is: the long fat network problem.

How do I fix a BDP that exceeds my TCP window?

Enable TCP window scaling (RFC 7323), which modern operating systems do by default, and raise the maximum socket buffer sizes so the window can grow to the BDP. The calculator shows the minimum scale shift.

How much does packet loss matter?

A lot on long paths. Under the Mathis model, throughput falls with the square root of loss and inversely with RTT, so 0.01% loss on an 80 ms path limits one Reno-style flow to roughly 18 Mbps. The calculator shows the loss rate you can tolerate to fill the link.