Practical guide
TCP window and bandwidth-delay product reference
Calculate the TCP window needed for a bandwidth and RTT target, with decimal and binary unit conversions and practical limits.
By StackCalcs · Updated
Bandwidth-delay product (BDP) is the amount of unacknowledged data needed in flight to fill a path: bandwidth in bits/second × round-trip time in seconds. Divide by eight to express the result in bytes.
Worked calculation
For a 500 Mbps path with 40 ms round-trip time, BDP is 500,000,000 × 0.040 ÷ 8 = 2,500,000 bytes, or about 2.384 MiB. A single TCP flow generally needs at least that much usable receive window to fill the path under ideal conditions.
The bandwidth-delay product calculator converts the units. The transfer-time calculator estimates elapsed time for a payload after applying an efficiency factor.
Limits and common mistakes
BDP does not predict application throughput by itself. Congestion control, loss, sender and receiver buffers, parallel connections, server limits, and application behavior all matter. Use round-trip time rather than one-way latency, and label MB versus MiB when recording the result.
Why a fast link can still transfer slowly
TCP’s flow control lets a sender have only one window’s worth of data unacknowledged at a time. If the configured receive window is smaller than the path’s BDP, the sender is forced to pause and wait for acknowledgments before the link is even close to saturated — this is the “long fat network” problem RFC 7323 was written to address. A gigabit link with 150 ms RTT has a BDP of roughly 18.75 MB; without window scaling, TCP’s original 16-bit window field tops out at 64 KiB, so a single unscaled connection could use well under 1% of the available bandwidth.
Checking and raising the window size
Most modern operating systems enable window scaling (RFC 1323/7323) by default, extending the usable window well past 64 KiB. If throughput is still capped:
- Confirm scaling is enabled (
sysctl net.ipv4.tcp_window_scalingon Linux; it should read1). - Increase the socket receive/send buffer limits (
net.core.rmem_max/net.ipv4.tcp_rmemon Linux) so the OS can grow the window to match the BDP. - Consider multiple parallel TCP streams for bulk transfers, since each stream gets its own window and can collectively use more of the path than one under-windowed connection.
Source
RFC 7323 defines TCP window scaling and the extensions this reference relies on.