Bandwidth-delay product calculator.

Worked example

A 100 Mbps link with a 50 ms round-trip time holds 100,000,000 x 0.05 / 8 = 625,000 bytes (610.4 KiB) in flight. The largest unscaled TCP window is 65,535 bytes, so without window scaling throughput is capped at 65,535 x 8 / 0.05 = 10.49 Mbps. A 64 KiB window reaches 10.49 Mbps, 10.5% of the link. Filling it needs a window of at least 625,000 bytes, which is a scale shift of 4 (65,535 x 2^4 = 1,048,560 bytes).

How it works

BDP is the amount of data in flight on a full pipe: capacity times delay. TCP can have at most one receive window of unacknowledged data outstanding, so throughput cannot exceed window / RTT. RFC 7323 defines the window scale option: the 16-bit window field is shifted left by a scale of up to 14, giving windows up to 1 GiB (2^30). The tool finds the smallest shift where 65,535 x 2^shift covers the BDP.

Notes. Bandwidth is the usable rate (decimal: 1 Mbps = 1,000,000 bits per second), RTT is the round trip including queueing, and sizes are shown in binary KiB and MiB. Real throughput is also limited by loss, congestion control, buffers and sender settings, so the result is the window needed to fill the pipe, not a measured speed.

FAQ

What is the bandwidth-delay product?

The product of a link's data rate and its round-trip time: how many bits can be in flight at once. It is the TCP window size needed to keep the link full.

Why is my TCP transfer slow on a fast long-distance link?

If the receive window is smaller than the BDP, the sender stalls waiting for acknowledgments. Throughput is capped at window / RTT regardless of link speed.

What is TCP window scaling?

A TCP option (RFC 7323) that multiplies the 16-bit window field by 2^shift, with a shift of up to 14, so windows can reach 1 GiB.

Should I use the one-way or round-trip delay?

Use round-trip time. The sender waits for an acknowledgment that has crossed the link twice.