Bandwidth Delay Product Calculator

A fast link with a long round trip is a wide river that still delivers late. The bandwidth delay product tells you how much data must be in flight — unacknowledged, somewhere on the wire — to keep such a link completely full. Enter your bandwidth and round-trip time, and this calculator returns the BDP in bits and bytes, plus the throughput ceiling a standard TCP window imposes on that same link.

The Pipe Has a Volume

The bandwidth delay product is the answer to a plumber's question asked about light: how much is inside the pipe right now? A sender can only learn that data arrived one round trip later, so to keep the pipe continuously full it must have, at every instant, one round trip's worth of data outstanding — BDP = bandwidth × RTT. At 100 Mbps with a 50 ms round trip, that is 100,000,000 × 0.05 = 5 megabits of data perpetually in flight, 0.625 MB spread along the fibre like water along a hose. The quantity is called a "long fat network" problem when it grows large, and its tyranny is multiplication's: double the bandwidth alone and you must double the in-flight data to use it, which is why upgrading a transoceanic link so often disappoints until the endpoints' buffers and windows are upgraded to match — the river widens, but the cup you pour with does not.

Worked Example: The 64 KiB Window's Revenge

The defaults expose the classic case. BDP at 100 Mbps and 50 ms is 5.00 megabits (0.625 MB) — but a TCP connection limited to the original 64 KiB window can only have 65,535 bytes (0.524 megabits) unacknowledged at once. Its throughput ceiling is therefore window ÷ RTT = 524,280 bits ÷ 0.05 s ≈ 10.5 Mbps — a tenth of the purchased link, delivered by a protocol limit from 1981. This is not a museum problem: it is the recurring diagnosis behind "we upgraded to gigabit but the transfers did not move," whenever an old device, a misconfigured stack or a single-stream application caps the window beneath the path's BDP. RFC 7323's window scaling (multiplying the window by up to 2^14) exists precisely to lift the ceiling above modern BDPs, and the calculator's note performs the ceiling check on any path you enter — the most useful ten seconds in home and office networking diagnostics.

Buffers: Too Small Starve, Too Large Bloat

The BDP also sizes the queues at the pipe's ends, and its rule of thumb has caused a generation of engineering arguments. A bottleneck router needs roughly a BDP's worth of buffering to keep the link busy through TCP's sawtooth cycles (the classic rule: buffer = bandwidth × RTT of the paths it serves) — too little, and the link idles between bursts; too much, and the standing queue inflates delay for everyone, the bufferbloat disease that made video calls stutter on fast connections. Modern practice shrinks the rule with smarter queue management (the many-flow statistics of big routers need far less per-flow buffer), but the BDP remains the unit the argument is conducted in — the pipe's volume, against which every queue is judged generous or stingy. Enter a satellite path into the calculator (say 50 Mbps at 600 ms) and watch the BDP swell to 30 megabits: geosynchronous networking is a different profession largely because of that one product.

The Transatlantic Classroom

The BDP's favourite teaching example is the research-network path from Chicago to Amsterdam: about 6,000 km of fibre, a round trip near 90 ms, and links that climbed from 1 to 10 to 100 Gbps while the geography refused to move. At 10 Gbps and 90 ms the product is 900 megabits — over 100 MB of data in flight at every instant, on a path whose endpoints once shipped with buffers sized in single megabytes; the early demonstrations of "gigabit internet that transfers at 50 Mbps" were this arithmetic exacting its toll in public. The lesson generalised into an engineering maxim the calculator embodies: never quote a link's speed without its distance, because the product of the two — not either factor alone — decides what the endpoints must hold, buffer and forgive. Fibre made light fast; it could not make the Atlantic narrow, and the BDP is the receipt for the difference.

Data Centres: The Product at Microscopic Distances

Inside a data centre the same product rules at the opposite extreme: links of 100–400 Gbps with round trips measured in single microseconds produce BDPs of mere tens of kilobytes — small numbers with outsized consequences, because at those speeds the endpoint is a CPU trying to feed the pipe, and a single software hiccup of 10 microseconds starves a 400 Gbps link of half a megabyte of flight. The industry's responses are the BDP's usual children dressed for speed: enormous socket buffers, hardware pacing, and congestion schemes (DCTCP and its successors) that treat the tiny in-facility BDP as a quantity to be measured per-flow, continuously. It is the signature of a fundamental quantity that the transatlantic engineer's 100-megabyte problem and the data-centre engineer's 50-kilobyte problem are the same equation — the calculator spans both with two fields and no change of costume, which is the entire argument for learning the product once, properly, instead of memorising either regime's folklore.

Related Tools

More from the Other Calculators hub: the Bandwidth Calculator for transfer times on the same links, and the Uptime Calculator for the availability side of network promises.

Frequently Asked Questions

What is a "long fat network"?

Any path whose BDP is large — conventionally beyond about 10⁵ bits — which is to say: fast, far, or (the expensive case) both. Data centres are short and fat (enormous bandwidth, microsecond trips, modest BDPs); intercontinental research links and satellite hops are the canonical LFNs. The engineering consequences all trace to the product: windows must scale, buffers must be deliberate, loss becomes catastrophic to throughput (a dropped packet on an LFN wastes a fortune in flight capacity), and protocols earn their keep by how gracefully they keep a very large pipe continuously full.

Why does a single lost packet hurt so much on fast long links?

Because classic TCP treats loss as congestion and halves its window — and on a high-BDP path, refilling the pipe from half a window at one window per round trip takes many round trips of climbing, during which the link runs part-empty. The mathematics (the Mathis equation and its descendants) caps a lossy TCP flow's throughput at roughly MSS ÷ (RTT × √loss-rate): on a 50 ms path, even 0.01% loss cramps a single flow far below a gigabit. Modern congestion controls (BBR and friends) model the BDP explicitly rather than waiting for loss — a generational repair of exactly the quantity this page computes.

How do I measure my RTT?

Ping the far endpoint and read the average round-trip time — that is the RTT this formula wants, in milliseconds, under conditions resembling your transfer (an idle ping to a nearby CDN node flatters a path whose real bottleneck is a loaded transoceanic hop; measure to the actual destination, ideally while the network is ordinarily busy). Application-level round trips (an HTTP request's time to first byte) include server thinking time and overstate the network RTT; the network figure is the one the BDP's physics consumes, and the difference between the two pings is itself a useful diagnosis.

Does BDP apply to UDP and streaming?

The product exists on any path, but its discipline differs: UDP has no acknowledgements, so nothing forces the sender to hold an RTT's worth in flight — a streaming sender paces itself by the application's own clock, and the BDP instead sizes the receiver's jitter buffer (which must absorb at least the path's variation, conceptually anchored to the same product). Real-time media therefore fears RTT itself (delay is unwatchable) more than the product, while bulk TCP fears the product most. Same pipe, same volume — different professions worrying about different ends of it.

What window do I actually need for gigabit at 80 ms?

The BDP: 1,000 Mbps × 0.08 s = 80 megabits = 10 MB of window — about 153 times the classic 64 KiB, requiring a window-scale shift of at least 8 (2^8 = 256) negotiated at connection start. Modern operating systems autotune to this as a matter of course, which is why the failure mode survives mainly in embedded devices, ancient stacks, and middleboxes that strip the scaling option — the calculator's ceiling line will tell you in one glance whether a path's BDP has outgrown a 64 KiB window's ambitions (at 80 ms, that ceiling is about 6.6 Mbps, a humbling figure to set beside a gigabit invoice).

Is BDP the same as latency times bandwidth on the box?

Yes — with the standing warning that "latency" on consumer packaging usually means the one-way or the idle figure, while the formula wants the loaded round-trip time to the real destination. The difference is not pedantry at these magnitudes: a path advertised at "20 ms latency" that delivers 90 ms round trips under load has four and a half times the BDP its brochure implied, and every window, buffer and expectation set from the brochure inherits the error. Measure, do not quote: the calculator is only as honest as the RTT you feed it.