Bandwidth Delay Product Calculator - BDP and TCP Window Size

A bandwidth delay product calculator multiplies a link's bandwidth by its round-trip time to find the maximum bytes in flight on the wire at any moment. It returns the BDP in bits and bytes, suggests a TCP receive window that fills the pipe, and back-calculates the throughput cap a fixed window creates. Use it to size socket buffers, configure window scaling, and explain why a 1 Gbps link with 80 ms of latency only delivers about 6.4 Mbps at the 64 KiB default.

• • Size a TCP receive window: Pick a link bandwidth and measured RTT, read the bytes in flight, and set the socket buffer to at least that value.
• • Diagnose slow throughput: Compare the BDP against the current window size to see whether the bottleneck is the link or the receive window.
• • Plan satellite or transcontinental links: Estimate the buffer a 600 ms RTT satellite or 80 ms RTT transcontinental fiber needs before window scaling kicks in.
• • Compare IPv4 and IPv6: Show why IPv4 still needs window scaling above 64 KiB while IPv6 advertises its window in bytes without that cap.

The BDP is the canonical quantity introduced in IETF RFC 1323 and carried forward in IETF RFC 7323, where the 16-bit TCP window field was extended with a scale option because the BDP of a long fat network regularly exceeded 65535 bytes.

The same two-input shape (a network parameter and a time value) is shared by the Upload Time Calculator; the BDP is the inverse question.

The calculator converts the bandwidth input to a single bits-per-second value, converts the delay to seconds, and multiplies the two to get the BDP in bits. It then divides by 8 for bytes and by 1024, 1,048,576, and 1,073,741,824 for KiB, MiB, and GiB, and uses the same delay to back out the maximum throughput the supplied window can sustain.

• bandwidth: Link capacity. bps, kbps, Mbps, Gbps, and Tbps convert to a single bits-per-second value.
• delayType: RTT is the standard BDP denominator; OWT is doubled automatically to match the RFC 1323 / RFC 7323 RTT-based definition.
• delay: Delay in milliseconds, divided by 1000 to seconds for the BDP multiplication.
• windowSize: TCP receive window in KiB, converted to bytes and divided by the delay in seconds for the throughput back-calc.

Round-trip time and one-way delay are interchangeable only on symmetric links. The calculator doubles the OWT input to match the RFC 1323 and RFC 7323 convention.

According to RFC 1323 - TCP Extensions for High Performance, the original 16-bit TCP window field limits the receiver to a 65535-byte advertised window, and the window-scale option exists so a sender can fill a pipe whose BDP exceeds 65535 bytes.

The same time-versus-throughput tradeoff shows up in the Data Transfer Calculator, which takes a fixed file size and a fixed bandwidth and reports how long the transfer takes; the BDP is the bridge between the two.

Four ideas make the bandwidth-delay product match what a real TCP connection experiences on a long fat network and explain why a fast link can still feel slow.

RFC 7323 retains window scaling, PAWS, and the byte-counting approach introduced in RFC 1323. Both documents are the canonical source for the BDP formula and the rule that the receive window should be at least as large as the BDP for a single connection to reach the link's full capacity.

The same byte-versus-bit distinction shows up in the Baud Rate Calculator, where kbps, Mbps, and Gbps always refer to bits per second.

Five short steps take you from a measured link speed and round-trip time to a TCP window size that fills the pipe and a throughput cap that explains any gap to the headline speed.

1. 1 Enter the link bandwidth: Type the link capacity and pick the matching unit (Mbps for residential broadband, Gbps for backbones).
2. 2 Enter the delay as RTT or OWT: Pick RTT for the standard ping measurement or OWT for a traceroute. The calculator doubles OWT automatically.
3. 3 Type the delay value: Enter the delay in ms. Transatlantic fiber is 30-80 ms RTT, geostationary satellite 500-700 ms, residential cable 10-30 ms, metro fiber 1-5 ms.
4. 4 Set the TCP receive window: Enter the current receive window in KiB. Linux and Windows default to 64 KiB; macOS autotunes up to several MiB.
5. 5 Read the BDP and the suggested window: The primary result is the BDP in bits and bytes; secondary rows show KiB and MiB readouts, the suggested TCP window, and the throughput cap a fixed window creates.

Practical example: a CDN engineer needs to size the receive buffer on edge servers pulling software updates over a 10 Gbps link with 80 ms RTT. They enter 10 Gbps, RTT, 80 ms, and 64 KiB. The calculator returns a BDP of 100 MB and shows the 64 KiB window caps throughput at 800 KB/s, or 6.55 Mbps. They raise net.ipv4.tcp_rmem max to at least 100 MB and confirm throughput now matches the link.

An engineer at a content delivery network also needs the byte and MiB readouts in familiar storage units, and the Data Storage Converter handles the cross-check between the KiB, MiB, and GiB numbers the calculator returns and the same units a kernel-tuning recipe expects.

Six practical reasons to reach for this calculator instead of guessing at window sizes or chasing phantom throughput bugs.

• • Right-sized TCP windows: Returns the smallest receive window that fills the link, so the engineer sets net.ipv4.tcp_rmem or SO_RCVBUF to a value that matches the pipe.
• • Faster long fat network throughput: Reveals the gap between link bandwidth and the throughput a 64 KiB window can sustain, the most common cause of slow transfers on transcontinental fiber and geostationary satellite links.
• • Diagnoses apparent ISP shortfalls: Shows whether a slow download is the link or the window.
• • Plan satellite and intercontinental links: Quantifies the cost of long latency on a fast link, so a satellite ISP customer knows in advance that 600 ms RTT will need multi-megabyte buffers.
• • Compare IPv4 and IPv6 behavior: Uses the same BDP output to show why IPv4 still requires window scaling above 64 KiB while IPv6 advertises its window in bytes.
• • Reference for protocols beyond TCP: The same bytes-in-flight quantity shows up in BBR, QUIC, and SCTP buffer sizing.

Window scaling is opt-in on IPv4, so a connection that never negotiates the option is stuck at a 65535-byte window. The calculator makes that limit explicit by reporting both the suggested window size and the throughput cap a fixed window creates.

Once the BDP shows the bytes in flight, the next network decision is which IP version carries that window, and the IP Address Converter translates the IPv4 and IPv6 representations a sysadmin has to compare when tuning the same link on both stacks.

Four practical variables change the bandwidth-delay product and three caveats explain why a calculator reading is not always a perfect stand-in for a live TCP throughput measurement.

• • The calculator assumes the link is the bottleneck. On shared or wireless links, retransmissions lower effective bandwidth, so the BDP overstates actual bytes in flight.
• • The throughput back-calc uses window / delay, the steady-state ceiling. Slow-start, congestion avoidance, and packet loss keep a real TCP connection below it.
• • Round-trip time varies with route changes and queueing, so the BDP and suggested window row should be recomputed when the measured RTT changes by more than 10 ms.

Used inside its limits, the BDP ties bandwidth, latency, and buffer sizing together. Outside those limits, it is a starting point for tuning, not a precise predictor of throughput.

For the time-and-rate size math that underlies the BDP, the Time Lapse Calculator combines a shooting interval with an event duration to estimate photo storage.

According to RFC 7323 - TCP Extensions for High Performance, a modern TCP sender advertises a window in octets (bytes) and counts throughput in octets per second, which is why the calculator divides the bit-rate BDP by 8 before comparing it with a socket buffer.

According to Wikipedia - Bandwidth-delay product, the bandwidth-delay product is the product of a link's capacity (in bits per second) and its end-to-end delay (in seconds), and represents the maximum amount of data that can be in transit on the wire.