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

CHECK

9766 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.

Diagnostic telemetry
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

Bandwidth-Delay Product / TCP Window on RunTheTests — free browser-based netmath tools, no sign-up.