Enter link bandwidth and round-trip time. Get the bandwidth-delay product — the amount of data in flight — which is the receive window TCP needs to keep the pipe full.
The bandwidth-delay product is exactly what it sounds like: bandwidth × round-trip time. It's the number of bits "on the wire" at any instant — the capacity of the pipe itself. To keep a TCP connection running at full speed, the sender must be able to have at least one BDP of unacknowledged data outstanding, which means the receiver's advertised window must be at least the BDP.
Example: a 1 Gbps link with 40 ms RTT has a BDP of 1×10⁹ × 0.040 = 40,000,000 bits = 5,000,000 bytes ≈ 4.77 MB. If the window is smaller than that, throughput is capped at window ÷ RTT regardless of how fast the link is.
The original TCP window field is 16 bits, capping the window at 65,535 bytes. On a "long fat network" (high bandwidth × high latency) that's far below the BDP, so throughput collapses. Window scaling (RFC 1323/7323) multiplies the window by a power of two, up to 2¹⁴, allowing windows up to ~1 GB. This tool reports the scale factor your BDP needs.
Almost always a window smaller than the BDP. Max throughput = window ÷ RTT. Enable window scaling and raise the receive buffer.
A path with a large bandwidth-delay product — high bandwidth and/or high latency (satellite, intercontinental links). These need large, scaled windows.
This is the raw layer-1/2 figure (bandwidth × RTT). Real goodput is a bit lower after TCP/IP overhead; size buffers a little above the BDP for headroom.