Logo

MonoCalc

/

BDP Calculator

Networking

Quick presets:

BDP Results

BDP (bytes)

18750000

raw byte count

BDP (human)

17.88 MB

KB / MB / GB

BDP (bits)

150.000 Mb

megabits

Recommended Buffer

17.88 MB

per TCP socket (send + recv)

TCP Window Scaling (RFC 7323)

wscale 9

Window scaling required

Max window with wscale 9: 32.00 MB (65,535 × 2^9)

About This Tool

Bandwidth Delay Product (BDP) – TCP Buffer Sizing Guide

The Bandwidth Delay Product (BDP) is one of the most important metrics in network performance engineering. It quantifies the maximum amount of data that can be "in flight" across a network path at any given moment — from the instant the first bit leaves the sender until the first acknowledgement arrives back. Understanding BDP is essential for anyone tuning TCP performance on high-bandwidth or high-latency links such as satellite connections, transoceanic fibre circuits, and intercontinental VPNs.

The Core Formula

The BDP formula is straightforward:

BDP (bytes) = (Bandwidth ÷ 8) × RTT

where Bandwidth is measured in bits per second and RTT (Round-Trip Time) is in seconds. The result tells you exactly how large your TCP socket buffers must be to keep the link fully utilised. For example, a 1 Gbps link with 150 ms RTT has a BDP of18,750,000 bytes (≈ 18.75 MB). Each TCP socket on this link needs send and receive buffers of at least 18.75 MB to sustain 1 Gbps throughput.

Why Small Buffers Throttle High-Latency Links

TCP uses a sliding-window flow control mechanism. The sender can push at most one window's worth of unacknowledged data into the pipe before it must pause and wait for ACKs. When the window is smaller than the BDP, the sender exhausts its window allowance before the first ACK returns, leaving the pipe idle for the remainder of the RTT. This cycle — send a window's worth, wait, send again — produces dramatic throughput degradation.

The classic example is the long fat network (LFN): a satellite link with 25 Mbps bandwidth and 600 ms RTT. Its BDP is roughly 1.875 MB. With the legacy 65,535-byte TCP window (no window scaling), the achievable throughput is limited to:

Max throughput = (65,535 bytes × 8) / 0.600 s ≈ 0.87 Mbps

This represents less than 4% of the available bandwidth — a severe under-utilisation caused entirely by an undersized buffer.

TCP Window Scaling (RFC 7323)

The original TCP specification limits the window field to 16 bits, capping it at 65,535 bytes. RFC 7323 introduced the Window Scale option (wscale), which shifts the window field left by 0–14 bits during the TCP three-way handshake, raising the effective maximum window to 65,535 × 2^wscale bytes — up to approximately 1 GB with wscale 14.

This calculator computes the minimum wscale factor your link requires using:

wscale = ceil(log₂(BDP ÷ 65,535)), clamped to 0–14

Modern operating systems (Linux, macOS, Windows Vista+) negotiate window scaling automatically when both endpoints support it. However, misconfigured firewalls or middleboxes sometimes strip the Window Scale option, silently capping throughput at the legacy limit.

Buffer Efficiency Analysis

If you know your current TCP socket buffer or window size, the tool calculates buffer efficiency: the percentage of the link's theoretical capacity that is actually reachable. An efficiency below 20% indicates severe under-buffering; above 80% is considered optimal. The tool also shows the effective throughput and bandwidth wasted due to the window limit.

Segments in Flight

For deeper analysis, enter the link's MTU (typically 1500 bytes for Ethernet, up to 9000 bytes for jumbo frames). The tool subtracts the TCP/IP header overhead (default 40 bytes) to find the payload per segment and divides the BDP by this value to show how many full TCP segments can be simultaneously in transit across the pipe.

Linux sysctl Tuning

On Linux, the kernel's default socket buffer limits are often too small for high-BDP links. The sysctl Commands mode generates ready-to-apply kernel tuning parameters, including:

  • net.core.rmem_max and net.core.wmem_max — maximum socket buffer sizes
  • net.ipv4.tcp_rmem and net.ipv4.tcp_wmem — min/default/max per-socket buffers
  • net.ipv4.tcp_window_scaling=1 — ensure window scaling is enabled

Generated values use a 2× safety margin over the raw BDP to account for protocol overhead and ensure consistent throughput under varying conditions.

Link Profile Comparison

The Link Profiles mode compares BDP and required wscale across five representative link types — Gigabit LAN, Corporate WAN (100 Mbps / 80 ms), Satellite (25 Mbps / 600 ms), Transoceanic Fibre (10 Gbps / 200 ms), and 5G Mobile (1 Gbps / 10 ms). Clicking a row loads that profile into the main calculator for detailed analysis.

Practical Applications

Network engineers, SREs, and system administrators use BDP calculations to: size TCP buffers on WAN accelerators and MPLS circuits; diagnose throughput problems on VPN tunnels; evaluate whether a proposed link will sustain required application SLAs; configure TCP buffer autotuning ranges; and validate that window scaling is correctly negotiated end-to-end. Students and developers use it to understand why latency — not just bandwidth — determines the ceiling of any TCP-based transfer.

Frequently Asked Questions

Is the BDP Calculator free?

Yes, BDP Calculator is totally free :)

Can I use the BDP Calculator offline?

Yes, you can install the webapp as PWA.

Is it safe to use BDP Calculator?

Yes, any data related to BDP Calculator only stored in your browser (if storage required). You can simply clear browser cache to clear all the stored data. We do not store any data on server.

How does the Bandwidth Delay Product Calculator work?

Enter your link bandwidth and round-trip time (RTT). The tool computes BDP = (Bandwidth ÷ 8) × RTT, giving you the number of bytes that can be in transit simultaneously. It then derives the recommended TCP buffer size, the RFC 7323 window scale factor, and optionally shows buffer efficiency if you supply your current window size.

What is the Bandwidth Delay Product (BDP)?

BDP is the maximum amount of data that can be 'in flight' on a network path at any instant — from the moment the first bit is sent until the sender receives the first acknowledgement. It equals bandwidth × RTT (in bytes). Engineers use it to size TCP socket buffers, evaluate WAN links, and diagnose throughput ceilings on high-latency connections.

Why does a high-bandwidth satellite link feel slow?

A GEO satellite link typically has 600 ms RTT. At 25 Mbps, BDP ≈ 1.875 MB, but the legacy TCP window cap of 65,535 bytes is only 3.5% of BDP. Without TCP window scaling, the sender must stop and wait for ACKs thousands of times per second, achieving only ~0.87 Mbps — less than 4% of the available bandwidth. Enabling window scaling and setting buffers ≥ BDP fixes this.

What is the TCP Window Scale Factor (wscale)?

TCP's original 16-bit window field caps at 65,535 bytes. RFC 7323 defines a window scaling option — the `wscale` value — that shifts the window field left by 0–14 bits, raising the maximum window to 65,535 × 2^wscale bytes (up to ~1 GB). This tool calculates the minimum wscale you need so your TCP window can equal or exceed the BDP.

How is buffer efficiency calculated?

Buffer efficiency = (current TCP window size ÷ BDP) × 100, capped at 100%. A value below 100% means the sender is stalled waiting for ACKs before the pipe is full. For example, a 64 KB window on a 1 Gbps / 100 ms link (BDP = 12.5 MB) yields only 0.52% efficiency — the link operates at roughly 5 Mbps instead of 1 Gbps.

What do the sysctl commands generated by this tool do?

The generated Linux sysctl commands set the kernel's maximum TCP receive and send socket buffer sizes (net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmem) to twice the calculated BDP, providing a safety margin. They also enable TCP window scaling (net.ipv4.tcp_window_scaling=1). These settings allow the OS to allocate buffers large enough to keep high-latency links fully saturated.