[ CHECK / [BDP] ]

Bandwidth-delay product calculator

Estimate bytes in flight and the effect of a TCP receive window on throughput.

◉ Stays in your browser

01 / Your rate and round-trip time

Bottleneck transfer rateRate unitRound-trip time (ms)For example, 50 ms is 0.05 seconds. Use RTT, not the one-way delay.TCP receive window (optional)Enter a window to estimate its throughput limit, or leave blank for BDP only. Must convert to whole bytes, up to 1 TB.Receive window unit

Uses round-trip time (RTT), not one-way delay: window bytes = bits/second × RTT seconds ÷ 8. The window estimate assumes one flow, enough congestion window, and no loss or protocol overhead. RTT must be 0.001–60,000 ms and rate no more than 1,000 Tbps. Actual protocol and OS limits may apply.

Processed in your browser. No files are uploaded and no connection speed test is run.

Reference: RFC 6349: window, rate, and RTT ↗

02 / Your result

Your result will appear here.
Start with your own input or try an example.

What it does

Explore how bottleneck bandwidth and round-trip time determine an ideal amount of data in flight. Enter the rate and RTT to calculate the bandwidth-delay product in bytes and KiB, plus a whole-byte flight-window estimate. Optionally enter a receive window to compare its theoretical throughput ceiling with the link rate. No network probes or system settings are changed.

Useful when

Compare the data in flight on low-latency and high-latency paths.
Check whether a proposed receive window would limit one flow in an ideal model.
Work through network-performance examples using explicit RTT and rate units.

How to use it

Enter the bottleneck transfer rate and round-trip time in milliseconds.
Optionally supply a TCP receive-window size to model its throughput limit.
Calculate the BDP, review the assumptions, and copy or download the results.

A few useful details

Does delay mean one-way latency or round-trip time?

This TCP-oriented calculation uses round-trip time: BDP bytes = bits per second × RTT seconds ÷ 8. Enter milliseconds; the tool converts them to seconds before calculating.

How is the receive-window throughput limit calculated?

The ideal window limit is receive-window bytes × 8 ÷ RTT seconds. The tool also caps that value at the entered link rate and shows the resulting link utilization.

Is the result a recommended operating-system setting?

No. It is a simplified single-flow estimate assuming sufficient congestion window and no loss or overhead. Protocol and operating-system limits, congestion control, and competing traffic affect performance. The tool changes no settings.