Bandwidth-Delay Product / TCP Window
Find how much data must be in flight to keep a long link busy.
What you provide
A ping to the far end gives you this. Use the typical value, not the best one.
64 KB is the unscaled maximum. Modern stacks auto-tune well beyond it when both ends agree.
Result
CHECK9766 KB in flight to fill 1000 Mbps at 80 ms
A 64 KB window on a 80 ms path tops out at 7 Mbps, which is 1% of what the link can carry. This is the classic long fat network problem, and it is why a single file transfer across an ocean crawls while the link itself measures fine. Raising the socket buffers at both ends is what fixes it, since window scaling has to be agreed by both.
- Bandwidth-delay productData that must be in flight to keep the link full
- 9766 KB
- In megabytes
- 10.00 MB
- Your window
- 64 KB
- Throughput at that windowWindow-limited to 1% of the link
- 6.6 Mbps
- Without window scalingThe 65,535 byte ceiling of the unscaled TCP header field
- 6.6 Mbps
- Window scale factor needed
- 2^8
What this cannot tell you
- Arithmetic on the bandwidth and latency you enter. It does not measure your connection or inspect any TCP session.
- The window sets a ceiling, not the actual rate. Congestion control, packet loss and the far end all decide what a real transfer achieves, and none of them are modelled here.
Take this with you
How this calculation works
TCP can only have one window of data outstanding before it has to wait for an acknowledgement, so throughput is capped at the window size divided by the round-trip time no matter how much bandwidth sits underneath. The bandwidth-delay product is the amount of data that has to be in flight to keep the pipe full. The calculator works it out, compares it against the window you are using, and shows the ceiling that the unscaled 16-bit TCP window field would impose on the same path.
What the results mean
- Bandwidth-delay product
- Data that must be unacknowledged at any moment to keep the link saturated. Think of it as the volume of the pipe rather than its width.
- Throughput at that window
- What a single TCP stream can actually reach with the window you specified. If it is well below the link speed, the window is your bottleneck.
- Window scale factor
- The multiplier TCP needs to negotiate to advertise a window this large. It is agreed once during the handshake and cannot be changed mid-session.
Common problems and fixes
- A single file transfer is slow but a speed test is fast
- Speed tests open many parallel connections, so each one only needs a small window and the aggregate fills the link. A single stream has to fill the pipe alone, which is exactly the case this calculation covers. Raise the socket buffer limits at both ends, since window scaling is negotiated and the smaller of the two ends wins.
- Buffers are already large and throughput is still poor
- Look for packet loss next. On a long path, a single loss costs at least one round trip to detect and recover, and classic congestion control halves the window each time it happens. A loss rate too low to notice on a short link can cut long-distance throughput by more than half. A path with low loss and high latency behaves very differently from one with the reverse.
Frequently asked questions
Why does 64 KB matter?
The window field in the TCP header is 16 bits, which tops out at 65,535 bytes. Without the window scaling option, that is the hard maximum, and it caps a 100 ms path at roughly 5 Mbps regardless of the link. Window scaling was standardised in 1992 and every modern stack uses it, but middleboxes that strip the option still exist and produce exactly this symptom.
Does this apply to UDP or QUIC?
The physics do. Any protocol needs data in flight to fill a long path, so the bandwidth-delay product is the same. QUIC implements its own flow control with the same idea, and because it lives in userspace it is often better tuned than the operating system defaults.
Can I get around it with parallel streams?
Yes, and it is what transfer tools do. Several connections each with a modest window can collectively fill the pipe. The trade-off is that parallel streams compete more aggressively for shared capacity, which is fine on a dedicated link and antisocial on a congested one.
Put this on your own site
Free to embed, no attribution required beyond the source link the frame carries itself. It runs entirely in your visitor's browser, sets no cookies and loads no third-party script.
<iframe src="https://runthetests.com/embed/bandwidth-delay-product/" width="100%" height="560" style="border:1px solid #e5e5e5;border-radius:8px" title="Bandwidth-Delay Product / TCP Window" loading="lazy"></iframe>
Preview it at https://runthetests.com/embed/bandwidth-delay-product/. Embedded pages are marked noindex, so yours stays the canonical copy — not this one.