Bandwidth Delay Product Calculator

Introduction:

A fast link can still move data slowly when the sender has to pause for acknowledgments too often. The limiting factor is not only how many bits per second the path can carry, but also how long a round trip takes. A transfer over a nearby 1 Gbps LAN and a transfer over a 1 Gbps inter-region path have the same headline bandwidth, yet the long-distance path needs far more unacknowledged data in flight before it can stay busy.

Bandwidth-delay product, usually shortened to BDP, is the amount of data that fits in the network path at a chosen rate and round-trip time. It turns a speed-and-latency pair into a byte target that can be compared with TCP receive windows, socket buffers, application buffers, and multi-stream transfer settings. The idea is simple, but the unit shift matters: bandwidth is normally entered in bits per second, while the window that limits a TCP sender is sized in bytes.

The term becomes important when latency is no longer tiny. A backup over a private WAN, a database replication stream between cloud regions, an object-store upload through a VPN, or a research transfer over a national network may need window sizes measured in mebibytes instead of kilobytes. Satellite, mobile, encrypted tunnel, and congested routes can increase the delay side of the product even when the access link looks generous.

BDP is not the same thing as measured throughput. It only answers whether the window can hold enough bytes for a target rate and RTT. Packet loss, congestion control, host CPU, disk speed, encryption, path MTU, queueing, and application pacing can all keep real throughput below the calculated window-limited ceiling.

The result is most useful as a first sizing check. When the calculated per-stream target is far above the current receive window, tuning buffers or using a transfer that opens several streams may remove one limiter. When the window already fits, the next investigation should move to loss, retransmissions, host limits, or the application itself instead of adding buffer space blindly.

How to Use This Tool:

Use this calculator as a window-sizing pass before changing host buffers, transfer settings, or stream counts. Enter the path numbers you want to model, then compare the per-stream target with the effective receive window available to one TCP flow.

1. Enter Path bandwidth as the usable bottleneck rate for the transfer. Use a shaped WAN, VPN, private link, or measured rate when it is lower than the advertised link speed.
2. Enter Round-trip latency in milliseconds. Start with measured idle RTT; if loaded latency rises during real transfers, rerun the sizing with the higher value.
3. Set Target utilization to the share of bandwidth you want the window to support. Values from 80% to 95% usually leave more planning room than a perfect 100% target.
   A target above 95% triggers a warning because jitter, loss recovery, and shared-link bursts can make a full-pipe target brittle.
4. Set Parallel streams to the number of TCP flows the transfer can actually open. The Per-stream window target divides aggregate BDP by this count.
5. Enter Current receive window in MiB for one flow. If you are testing an old unscaled baseline, 0.064 MiB is close to a 64 KiB receive window.
6. Open Advanced only when those assumptions matter. MSS changes Packets in flight; Protocol overhead lowers the payload-rate target before the byte window is calculated.
7. Check Input audit, Window Metrics, and Tuning Guidance. If the audit says Adjusted, fix the clamped input before using the window recommendation.

Interpreting Results:

The value to compare first is Per-stream window target. If it is larger than Current receive window, one TCP flow cannot keep enough bytes outstanding for the selected rate and RTT. Aggregate BDP target is the path-wide in-flight byte requirement, while Current aggregate ceiling estimates the throughput cap caused by the entered window and stream count before other bottlenecks are considered.

• window fits means the entered per-flow receive window meets the calculated per-stream target.
• window short means the current window is below the target and may cap throughput.
• TCP window scaling marked Required means the target exceeds the original unscaled TCP receive-window range.
• Needed streams with current window is useful only when the application can open that many independent flows without harming the service.

A fitting window removes one common limiter, not every limiter. If live throughput is still low, verify loss, retransmits, congestion control, CPU, storage, encryption overhead, path MTU, and application pacing before increasing buffers again.

Technical Details:

BDP is a capacity-time product. The capacity term should be the bandwidth available to the transfer, not every link speed on the topology. The time term is round-trip time in seconds, because TCP data flow depends on acknowledgments returning before the sender can safely advance beyond the advertised window.

TCP receive windows matter because the receiver advertises how many bytes it is prepared to accept. The sender cannot exceed that advertised window even if the path has spare bandwidth. For targets above the original 16-bit TCP window range, the endpoints need TCP window scaling negotiated during connection setup so larger receive windows can be represented.

Formula Core:

The aggregate byte target is the adjusted payload rate multiplied by RTT. The per-stream target divides that byte target by the selected stream count, and the current-window ceiling estimates how much bandwidth the entered window and stream count can support.

For the default 1,000 Mbps path, 80 ms RTT, 90% utilization, four streams, and no overhead reserve, the payload target is 900 Mbps. The aggregate BDP is 9,000,000 bytes, or about 8.58 MiB. Four streams split that into about 2.15 MiB per stream. A 16 MiB current receive window therefore fits the modeled target.

The chart tabs use the same equations. RTT Capacity Map changes RTT while holding the other inputs steady, so the target grows linearly with latency. Stream Scaling Curve changes stream count, so the modeled fill improves until the current receive windows can cover the aggregate BDP or the path bandwidth cap is reached.

Accuracy Notes:

BDP sizing is deterministic for the numbers entered, but the numbers themselves may be noisy. Use measurements from the same path, direction, VPN state, and time window you care about.

• Idle RTT can understate the delay seen during loaded transfers when queues build.
• Bandwidth tests may hit a nearby test endpoint instead of the remote service that matters.
• The calculation does not detect packet loss, congestion-control behavior, host limits, storage speed, or application pacing.
• The calculations run from the values entered in the browser and do not measure the network by themselves.

Worked Examples:

These examples show how the same formula can point to different next checks depending on latency, window size, and stream count.

FAQ:

Glossary:

Bandwidth-delay product

The amount of data that fits in a path at a given bandwidth and RTT.

Bottleneck bandwidth

The usable rate of the slowest relevant part of the transfer path.

Round-trip time

The time for a packet and its acknowledgment or response to complete a round trip.

Receive window

The amount of data a TCP receiver advertises that it can accept.

TCP window scaling

A TCP option that allows receive windows larger than the original 16-bit window field.

MSS

Maximum segment size, used here to estimate how many packets are in flight.

References:

• RFC 6349: Framework for TCP Throughput Testing, RFC Editor, August 2011.
• RFC 7323: TCP Extensions for High Performance, RFC Editor, September 2014.
• Determining the Bandwidth-Delay Product, Oracle Database Net Services Administrator's Guide.
• What is latency?, Cloudflare Learning Center.
• How to test internet speed in Linux, Simplified Guide.