📡 Bandwidth Delay Product Calculator
Calculate BDP and optimal TCP buffer/window sizes for any link speed and latency
| Link Type | Bandwidth | RTT | BDP | Window Needed |
|---|---|---|---|---|
| Local LAN | 1 Gbps | 0.5 ms | 62.5 KB | Default OK |
| Metro Ethernet | 1 Gbps | 5 ms | 625 KB | 1 MB buffer |
| Cross-country US | 1 Gbps | 40 ms | 5 MB | 8 MB buffer |
| Trans-Atlantic | 10 Gbps | 80 ms | 100 MB | 150 MB buffer |
| Trans-Pacific | 10 Gbps | 150 ms | 187.5 MB | 300 MB buffer |
| GEO Satellite | 100 Mbps | 600 ms | 7.5 MB | 15 MB buffer |
| Data Center Spine | 100 Gbps | 0.1 ms | 1.25 MB | 2 MB buffer |
| VPN Tunnel (WAN) | 100 Mbps | 100 ms | 1.25 MB | 2 MB buffer |
| sysctl Parameter | Purpose | Typical Value |
|---|---|---|
| net.core.rmem_max | Max receive socket buffer | 134217728 (128 MB) |
| net.core.wmem_max | Max send socket buffer | 134217728 (128 MB) |
| net.ipv4.tcp_rmem | TCP receive buffer (min/default/max) | 4096 87380 134217728 |
| net.ipv4.tcp_wmem | TCP send buffer (min/default/max) | 4096 65536 134217728 |
| net.ipv4.tcp_window_scaling | Enable window scaling | 1 (enabled) |
| net.ipv4.tcp_congestion_control | Congestion algorithm | bbr / cubic |
The bandwidth-delay product, or BDP, is the product of a data link’s capacity in bits per second and its round-trip delay time in seconds. The result is an amount of data measured in bits or bytes. It equals the biggest amount of data on the network circuit at any moment
Imagine it this way: data travel through the network, and the sender must wait for acknowledgment before sending more. The BDP shows how much data can be “in flight” or unacknowledged at any moment. It gives the maximum amount of data the sender can send in a set time before waiting for acknowledgment.
What is the Bandwidth-Delay Product (BDP)?
The formula is really simple. You only need two variables: the bandwidth B in bits per second and the round-trip time RTT in seconds. You can also write it as bandwidth-delay product equals 2 times propagation delay times bandwidth.
That is basically it.
Here is a sample. A link of 512 kilobits per second with 900 milliseconds RTT gives you 512 times 10 to the third bits per second times 900 times 10 to the negative third seconds. That works out to 460,800 bits, so 57,600 bytes or 56.25 kibibytes.
The best window size depends on the bandwidth and delay of the link. You often use the BDP as the window size. When the BDP is larger than the TCP window size, the system cannot use all the available bandwidth.
Because TCP waits for acknowledgment before sending more data, the amount of data in flight stays limtide.
When your window equals 2 times delay times bandwidth, by the time you have sent a window of data, you have received the first acknowledgment from the receiver. This way you can continue to send more data without pausing.
Here is where things get a bit weird. The default maximum TCP buffer sizes in Linux are sometimes still too small. Then you see how the BDP effect limits your throuput.
Speeds suffer especially if a small receive window is used. Paradoxically, if the bandwidth is higher, a single connection uses a smaller part of the potential throughput. The TCP window was only 65 kilobytes, so on a 50 megabit link it takes only 10 milliseconds to send those bytes, and then the sender simply waits.
The round-trip delay can be 40 times that for a satellite link.
BDP matters for TCP and any synced protocols with bidirectional communication and acknowledgment. With a protocol with end-to-end flow control like TCP the total latency can affect the throughput.
