Bandwidth Delay Product Calculator

Network rate and round-trip time belong in the same capacity question. A 1 Gbit/s path with a short local round trip needs little unacknowledged data to stay busy. The same rate across a long-distance route needs a much larger amount in flight while acknowledgments travel back.

Bandwidth-delay product (BDP) expresses that in-flight amount. Multiplying path rate by round-trip time gives bits in flight; dividing by eight gives the byte window associated with that rate and delay. The result is commonly compared with TCP receive windows and socket buffers.

Bottleneck bandwidth

The usable rate of the slowest relevant part of the path, not necessarily the advertised access speed.

Round-trip time

Elapsed time for data to travel out and the corresponding acknowledgment to return.

Aggregate BDP

The total target bytes in flight across the modeled path.

Per-stream target

Aggregate BDP divided across the TCP flows a transfer can actually open.

A high-bandwidth, high-latency path is where the number becomes operationally important. Inter-region backups, research transfers, private WANs, VPNs, and satellite routes can need receive windows measured in mebibytes. More parallel streams do not reduce aggregate BDP; they divide the required in-flight data among flows.

BDP describes one possible limiter, not achieved throughput. Packet loss can shrink the congestion window, host buffer limits can prevent the requested receive window, and storage, encryption, CPU, path MTU, queueing, or application pacing can become the slower stage.

Use the result to decide what to verify next. A window below the per-stream target is a concrete sizing shortfall. A window that already covers the target shifts attention toward loss, effective socket limits, the sender, storage, and application behavior.

How to Use This Tool:

Model the path the transfer really uses, then compare one flow's current receive window with the required per-stream target.

1. Enter Path bandwidth as the measured or shaped bottleneck rate. Use the lower VPN, WAN, private-link, or service limit when it constrains the transfer.
2. Enter Round-trip latency from the same end-to-end path. Rerun with loaded RTT when queueing raises delay during real transfers.
3. Set Target utilization and Parallel streams. The first sets the payload-rate goal; the second divides aggregate BDP into a per-stream requirement.
4. Enter the Current receive window for one flow. Compare like with like: the displayed target is per stream, not the combined buffer across all flows.
5. Use Advanced when maximum segment size, protocol-overhead reserve, or display precision needs to match the test. Overhead reduces the modeled payload rate before BDP is calculated.
6. Review Current window fits or Current window short, then verify effective socket buffers and run a live transfer test before changing production settings.

Interpreting Results:

Per-stream window target is the main comparison value. A fit means the entered receive window is at least as large as that target. A short result reports how many more bytes one flow needs under the selected rate, utilization, overhead, RTT, and stream count.

• Aggregate BDP is the total payload window across all modeled streams.
• Current aggregate ceiling is the window-and-RTT ceiling capped at path bandwidth. It assumes all entered streams can use their windows fully.
• Parallel streams reports the smallest whole number of current windows that covers aggregate BDP.
• Packets in flight divides aggregate target bytes by the entered maximum segment size; it is a planning count, not a packet capture.

A fit does not predict transfer speed. Confirm the effective advertised window, sender buffer, loss and retransmissions, congestion control, host load, and storage throughput on the actual path.

Technical Details:

The model starts with decimal bits per second and converts RTT to seconds. Target utilization and protocol-overhead reserve reduce the payload-rate target before the in-flight byte requirement is calculated.

Formula Core:

Payload rate V and aggregate BDP in bytes are:

B is path bandwidth in bits per second, u is target utilization percent, o is protocol-overhead reserve percent, and t is RTT in seconds. For n parallel streams, the per-stream target is:

The modeled ceiling for an entered per-stream window W is limited by either the path rate or the amount those windows can release each RTT:

Needed streams are the ceiling of aggregate BDP divided by the current per-stream window. Packets in flight are aggregate BDP divided by maximum segment size.

Rule Core:

Bandwidth inputs use decimal kilobits, megabits, or gigabits per second. Receive windows use binary KiB, MiB, or GiB. Results keep full precision and apply the selected one, two, or three decimal places only when formatting displays.

Accuracy Notes:

Use bandwidth and RTT measured on the same route and under a relevant load. Idle ping can understate RTT during queueing, while a provider's advertised rate can overstate the bottleneck available to one application.

• The overhead percentage is a planning reserve, not packet-by-packet protocol accounting.
• Dividing BDP by stream count assumes flows share the target evenly and can all run concurrently.
• The 65,535-byte rule checks the classic unscaled TCP window field; actual negotiated scaling and operating-system buffer behavior must be observed on the connection.
• Loss, congestion control, path MTU, CPU, encryption, storage, and application limits remain outside the arithmetic.

Worked Examples:

References:

• RFC 6349: Framework for TCP Throughput Testing, RFC Editor, August 2011.
• RFC 7323: TCP Extensions for High Performance, RFC Editor, September 2014.
• How to test internet speed in Linux, Simplified Guide.