Bandwidth-Delay Product Calculator

Find the bandwidth-delay product of a link.

How it is calculated

The product is computed in bits and then converted: bits = bandwidth × 1,000,000 × (RTT / 1000). Bandwidth is in megabits per second (Mbps) and RTT is the round-trip time in milliseconds. Bytes are bits / 8, and the kilobyte figure is bytes / 1024, so KB here means 1,024 bytes while Mbps uses the decimal million. The bytes figure is rounded to a whole number and the KB figure to two decimals. Both inputs must be above zero. The result is the amount of data that can be in flight on the link; it is the TCP window needed to keep it full. It does not include protocol overhead or packet loss.

Worked example

A 1,000 Mbps (1 Gbps) link has a round-trip time of 150 ms. Bits in flight: 1,000 × 1,000,000 × 0.150 = 150,000,000 bits. Divide by 8 to get 18,750,000 bytes, which is 18,750,000 / 1,024 = 18,310.55 KB. A sender therefore needs a window of about 18.75 MB to fill this link. A TCP window of 65,535 bytes, which is the maximum without window scaling, could carry only 65,535 × 8 / 0.150 ≈ 3.5 Mbps over the same path.

Try this example →

Common mistakes

  • Entering RTT in seconds. The field is in milliseconds, so 0.15 s must be typed as 150; typing 0.15 gives a result a thousand times too small.
  • Using one-way delay. The product needs the round-trip time, which is what a ping reports, not the single-direction latency.
  • Mixing up megabits and megabytes. A 100 MB/s disk or link is 800 Mbps; enter the Mbps value.
  • Expecting the KB figure to be exactly bytes / 1000. The tool divides by 1,024, so a 1,000,000-byte result is shown as 976.56 KB.

About this calculator

The bandwidth-delay product (BDP) is the amount of data "in flight" on a network link at any moment: BDP = bandwidth × round-trip time (RTT). It represents the maximum amount of unacknowledged data that can be in transit before the sender must wait for an acknowledgment, and it defines the ideal TCP send/receive window size needed to fully utilize the link's capacity.

If a TCP window is smaller than the BDP, the connection can't fill the "pipe" and throughput suffers regardless of available bandwidth — this is exactly why long-distance, high-bandwidth links (like satellite or transcontinental fiber) need window scaling enabled to reach their theoretical speed, a problem known as the "long fat network" (LFN) problem.

Network engineers tuning TCP window sizes and buffer configurations, systems administrators diagnosing why a high-bandwidth link isn't reaching expected throughput, and students studying computer networking all use this calculation to find the BDP from a link's bandwidth and latency.

Was this helpful?

You can pick up to 3 reactions.

Comments (1)

  • Editorial team

    The result is the window a single connection needs to fill the link. A 100 Mbps link at 50 ms comes to 625,000 bytes, but a 50 Mbps link at 600 ms, like a geostationary satellite path, needs 3,750,000 bytes, which is why long-distance transfers can crawl with a small default window. Which link speed and round-trip time are you testing, and what throughput do you actually see?

Popular calculators

All Calculators