Bandwidth vs Throughput Calculator
Estimate real achievable throughput from rated bandwidth accounting for overhead.
Reviewed by the ToolNestr Editorial Team — July 2026
Bandwidth vs Throughput Calculator
Estimated Throughput
—
Mbps
Efficiency
—
% of rated
Max Throughput (unlimited window)
—
Mbps
How throughput is calculated
This calculator estimates real-world TCP throughput using two fundamental constraints: protocol overhead and the bandwidth-delay product (BDP). The TCP throughput formula based on the BDP is:
The window size is in bytes, the factor of 8 converts to bits, and RTT is in seconds. This formula gives the theoretical maximum throughput imposed by the TCP sliding window — the sender cannot transmit more than one window full of data per round trip. After computing this limit, the result is further reduced by the protocol overhead percentage to account for TCP/IP headers, Ethernet framing, and any additional encapsulation.
Worked example
Take a typical office internet connection with the following parameters:
In this case, throughput is limited by the TCP window (64 KB) combined with the 20 ms RTT, not by the link bandwidth. Increasing the window size or reducing latency would improve throughput. With TCP window scaling enabled (up to 1 MB or more), throughput could approach the bandwidth limit.
Network performance testing
When running iperf3 or Speedtest, compare results against this calculator to understand whether TCP window limits or bandwidth is your bottleneck. If estimated throughput matches your iperf results, your window size or RTT is the constraint.
VPN throughput planning
VPNs add encapsulation overhead and often increase RTT due to the extra tunnel hop. This calculator helps you predict the realistic throughput before deploying a VPN, so you can size your links and choose the right protocol (WireGuard typically has lower overhead than OpenSSL).
Server capacity planning
When provisioning servers for high-bandwidth applications (streaming, file transfers, backups), use this tool to estimate whether your server's TCP stack configuration can saturate the available link. Tuning the TCP window, enabling window scaling, and using jumbo frames can dramatically improve throughput.
Cloud interconnect sizing
For Direct Connect, ExpressRoute, or other cloud interconnects, the RTT between your on-premises network and the cloud provider determines the BDP. Use the calculator to find the minimum TCP window needed to saturate your link, then configure your OS and firewall accordingly.
Tips for improving throughput
Enable TCP window scaling
TCP window scaling (RFC 7323) allows the receive window to grow beyond the default 64 KB limit, up to 1 GB. This is essential for high-bandwidth long-distance links. On Linux, check with sysctl net.ipv4.tcp_window_scaling. It is enabled by default on modern OS kernels, but some enterprise firewall policies may disable it, severely capping throughput on high-latency paths.
Use jumbo frames
Jumbo frames increase the MTU from the standard 1500 bytes to 9000 bytes, reducing the number of packets needed for a given data transfer. Fewer packets means less per-packet header overhead and lower CPU utilization. On a 100 Mbps link with standard MTU, the Ethernet/IP/TCP header overhead is roughly 7%. With jumbo frames, this drops below 1.5%. Jumbo frames require end-to-end support across all switches, routers, and NICs in the path.
Real-world vs theoretical
Theoretical calculations assume ideal conditions — no packet loss, no congestion, no queueing delay, and perfect TCP behaviour. In practice, packet loss triggers TCP congestion control (AIMD) which halves the window on each loss event, dramatically reducing throughput. Real-world throughput is typically 50–80% of the theoretical BDP limit on well-managed networks, and much lower on lossy or congested links. Tools like iperf3 and tcptrace help measure the actual throughput and loss rate.
Optimize the buffer size
The optimal TCP buffer (window) size is at least the bandwidth-delay product: BDP = Bandwidth (bps) × RTT (s). For a 100 Mbps link with 20 ms RTT, BDP = 100,000,000 × 0.02 = 2,000,000 bits = 244 KB. Ensure your OS's TCP buffer settings (net.ipv4.tcp_rmem and tcp_wmem on Linux) are set high enough to accommodate the BDP for your link.
Understanding the bandwidth-delay product
The bandwidth-delay product (BDP) is a fundamental concept in TCP performance. It represents the amount of data that can be "in flight" — transmitted but not yet acknowledged — on a network path at any given moment. The BDP is calculated as the link bandwidth in bits per second multiplied by the round-trip time in seconds. For a transatlantic link with 100 Mbps bandwidth and 100 ms RTT, the BDP is 100 Mbps × 0.1 s = 10 Mb or roughly 1.22 MB. To fully utilize this link, the TCP send buffer must be at least 1.22 MB. If the buffer is only 64 KB, the sender will spend most of its time waiting for acknowledgments, and throughput will be limited to roughly 64 KB / 100 ms = 5.2 Mbps — far below the link's 100 Mbps capability.
The BDP concept explains why high-latency links (satellite, intercontinental fibre) are particularly challenging for TCP performance. On a geostationary satellite link with 600 ms RTT, even the full BDP utilization with a 64 KB window yields only about 0.87 Mbps. Modern TCP implementations use window scaling, selective acknowledgments (SACK), and congestion control algorithms like BBR or CUBIC to improve performance on high-BDP paths. BBR, in particular, is designed to achieve high throughput on long-fat networks (LFNs) by pacing packets based on the estimated bandwidth and RTT, rather than relying solely on loss-based window adjustments.
The relationship between window size, RTT, and throughput also explains why short-lived connections (many HTTP requests for small resources) are disproportionately affected by latency. Each new TCP connection starts with a small initial window (typically 10 segments) and grows via slow-start. Connections that complete before the window grows large enough never reach peak throughput. This is why persistent connections (HTTP keep-alive, HTTP/2 multiplexing) and connection pooling are important strategies for latency-sensitive web applications. By keeping TCP connections open and reusing them, the window can stay in a large steady state, and the BDP limit is the only remaining throughput constraint.
Related tools
MTU Calculator
Find the optimal MTU size for your network path to minimize fragmentation and reduce overhead.
Subnet Mask Cheat Sheet
Quick reference for CIDR notation, subnet masks, and usable host counts.
DNS Record Builder
Construct A, AAAA, CNAME, MX, TXT, and SRV records with syntax validation.
Frequently asked questions
What is the difference between bandwidth and throughput?
Bandwidth is the theoretical maximum data transfer rate of a network link, while throughput is the actual rate achieved after accounting for protocol overhead, latency, congestion, and other real-world factors. Throughput is always lower than or equal to bandwidth.
How much overhead is typical?
TCP/IP overhead is about 5–10% for large transfers using standard 1500-byte MTU, but can be 20–50% for small packets where header-to-payload ratio is worse. Encryption (TLS/SSL) adds 5–15% more. VPN protocols like WireGuard or OpenSSL add their own encapsulation overhead.
Does latency affect throughput?
Yes — high latency limits throughput due to the TCP congestion window mechanism. With a fixed window size, the sender cannot transmit more than one window's worth of data per round-trip time. This is known as the bandwidth-delay product (BDP) problem. The formula is: Throughput ≤ Window Size / RTT.
What is TCP window size?
The TCP receive window is the amount of data (in bytes) a receiver is willing to accept before the sender must wait for an acknowledgment. The default window on many systems is 64 KB. TCP window scaling (RFC 7323) allows much larger windows, up to 1 GB, which is essential for high-throughput long-distance links.