search

Found

info Overview

Size your TCP window from the bandwidth-delay product: enter link speed and RTT for BDP in bytes, KiB, MiB and packets, a 64 KiB cap and a scaling check.

📘 How to Use

  1. Enter the bandwidth and pick a unit (Kbps / Mbps / Gbps)
  2. Enter the RTT (round-trip time) in milliseconds
  3. Pick a preset link if useful and read the BDP and window verdict

TCP Bandwidth-Delay Product (BDP) Calculator

ms
BDP (bytes)
KiB
MiB
Packets
TCP window status
Cap with default 64 KiB window

※ Formula: BDP (bits) = bandwidth (bps) × RTT (seconds). MSS = 1460 bytes (IPv4 / Ethernet) for packet count

※ Without window scaling, throughput is capped at 64 KiB / RTT

Article

TCP Bandwidth-Delay Product (BDP) Calculator | Size Windows and Find the Link Cap

Work out the TCP bandwidth-delay product from link speed and RTT, shown in bytes, KiB, MiB, and packets. See at a glance whether the default 64 KiB window throttles the link and whether window scaling is needed.

💡 About this tool

You provision a 1 Gbps circuit, run a single transfer across the country, and watch it crawl at 30 Mbps. The link is fine — the bottleneck is the TCP window. When the bandwidth-delay product (BDP = bandwidth × RTT) is larger than the send window, the sender keeps stalling for ACKs and the pipe sits half empty.

This calculator takes bandwidth (Kbps / Mbps / Gbps) and RTT (ms) and returns the BDP in bytes, KiB, and MiB. It converts that into packet count using MSS = 1460 bytes (IPv4 over Ethernet), and reports the throughput ceiling you would hit with a default 64 KiB window and no window scaling. Six presets — LAN, metro, intercontinental, trans-Pacific, GEO satellite, and 4G LTE — let you drop in a link close to yours and sanity-check the numbers before you touch socket buffers like net.ipv4.tcp_rmem or an application's SO_RCVBUF.

🧐 Frequently Asked Questions

Q. What is the BDP actually telling me? A. It is the amount of data that must be "in flight" to keep the pipe full. Size your TCP send window (or receive buffer) to at least the BDP and the sender never stalls waiting for ACKs.

Q. Why does 64 KiB keep coming up as a limit? A. The TCP header's window field is 16 bits, so it tops out at 65,535 bytes (~64 KiB). Any BDP above that needs window scaling (RFC 7323), which left-shifts the advertised window to reach gigabyte-scale values.

Q. How do I measure RTT? A. The round-trip time from ping is the usual proxy. It drifts with routing and congestion, so plug in a peak-load value for a conservative estimate.

Q. Where does MSS = 1460 come from? A. Ethernet's 1500-byte MTU minus a 20-byte IPv4 header and a 20-byte TCP header. With IPv6, PPPoE, or tunnels the MSS shrinks and the packet count rises.

Q. Does it handle jumbo frames or a different MSS? A. The packet count assumes a fixed MSS of 1460. With jumbo frames the real packet count is lower than shown, but the BDP in bytes is independent of MSS, so that figure stays valid.

Q. Why three bandwidth units? A. Some mobile and legacy links sit in the Kbps range while data-center fabric runs in Gbps. Three units let you enter the value without juggling zeros.

📚 Long fat networks and the pipe analogy

A link with both high bandwidth and high latency has a name: a Long Fat Network, or LFN. RFC 1323 (now superseded by RFC 7323) was written specifically to make TCP behave on these links, introducing window scaling and TCP timestamps. The classic mental model is a garden hose: a hose that is both wide and long holds a lot of water before any reaches the far end, and you must keep pumping that volume to keep the flow steady. Swap "water in the hose" for "bytes in flight" and you have the BDP. On a local LAN the RTT is under a millisecond and the BDP is a few dozen KiB, so the default window is plenty. Stretch the path across an ocean — say a 1 Gbps trans-Pacific link at 150 ms — and the BDP balloons past 18 MB, far beyond any default buffer. That gap is exactly why high-throughput transfers over long distances feel slow until someone tunes the window.