Calculate TCP throughput, bandwidth-delay product and optimal window size from bandwidth and RTT. Free BDP calculator with MSS and packet-loss math.
This TCP throughput calculator works out how fast a single TCP connection can actually go over a given path, and what window size it needs to get there. Enter bandwidth and round-trip time and it returns the bandwidth-delay product, the maximum throughput your current window permits, the MSS implied by your MTU, recommended socket buffer sizes, and a loss-adjusted throughput estimate. It answers the question that puzzles most people the first time they meet it: why a 1 Gbps link between two continents delivers 3 Mbps per stream.
BDP is the amount of data that fits “in flight” on the wire between sender and receiver — capacity multiplied by round-trip time. TCP is an acknowledged protocol: a sender may transmit at most one window's worth of unacknowledged data before it must stop and wait. If the window is smaller than the BDP, the sender idles while waiting for ACKs, and the link runs empty for part of every round trip.
BDP (bits) = bandwidth (bits/sec) × RTT (seconds)BDP (bytes) = BDP (bits) ÷ 8
Worked example. A 1 Gbps path with a 150 ms RTT — roughly US west coast to Asia:
Now invert it. The classic default receive window is 64 KB (65,535 bytes, the maximum the 16-bit window field can express without scaling). Maximum throughput from a fixed window is:
Throughput (bits/sec) = window (bytes) × 8 ÷ RTT (seconds)
Three and a half megabits on a gigabit link — 0.35% utilisation. Not one packet was lost and no device was overloaded. The window was simply 286 times too small. This is why the BDP number matters more than the link speed on any long path.
The TCP header's window field is 16 bits, capping the advertised window at 65,535 bytes. RFC 1323 / RFC 7323 window scaling adds a shift factor negotiated in the SYN handshake, multiplying the advertised value by up to 2^14 and raising the ceiling to roughly 1 GB. Two consequences follow. First, scaling must be agreed by both ends during the handshake — it cannot be enabled mid-connection. Second, a middlebox that rewrites or strips the SYN option leaves you permanently pinned to 64 KB, which looks exactly like a bandwidth problem in a speed test and is a very common cause of “the WAN link is fine but transfers are slow”.
Maximum segment size is what is left of the MTU after the headers:
MSS = MTU − IP header − TCP header (including options)
With a standard 1500-byte Ethernet MTU, a 20-byte IPv4 header, a 20-byte TCP header and 12 bytes of TCP options (the usual timestamps), MSS = 1500 − 20 − 32 = 1448 bytes. Over IPv6 the header is 40 bytes rather than 20, so MSS = 1428 bytes. Jumbo frames at MTU 9000 give an MSS of 8948 — a much better payload-to-overhead ratio, but only inside a datacentre where every device on the path supports them. The calculator also converts a window size into packets in flight (window ÷ MSS), which is the figure you compare against a switch's per-port buffer when you are chasing incast drops.
The BDP calculation assumes a clean path. Real paths drop packets, and a loss-based congestion control algorithm reacts by halving its window. The Mathis equation captures the resulting ceiling:
Throughput ≈ (MSS ÷ RTT) × (C ÷ √loss), with C ≈ 1.22
Worked example. MSS 1448 bytes, RTT 150 ms, packet loss 0.1% (0.001):
One tenth of one percent loss caps a single stream near 3 Mbps on that path, no matter how large the window or how fat the pipe. The square root is the point: cutting loss from 1% to 0.1% roughly triples throughput. Chasing a bad cable or a congested queue almost always beats buffer tuning.
Socket buffers must be at least BDP, and in practice a multiple of it, so the sender can keep transmitting while ACKs return. The calculator recommends a minimum equal to BDP, a maximum of 4× BDP, and a middle recommendation that varies by role — 1.5× for servers handling many concurrent connections, 2× for a general client, 4× for bulk transfer. Oversizing is not free: buffers that dwarf the BDP produce bufferbloat, where queues fill, latency climbs and loss-based algorithms are slow to notice.
The congestion control algorithm matters as much as the numbers. CUBIC is the Linux default and performs well on high-BDP paths with low loss. BBR models bandwidth and RTT rather than treating loss as congestion, which makes it markedly better on lossy long-haul and wireless paths. Reno is the conservative baseline. The tool's scenario presets pair realistic path profiles — long-haul WAN, satellite, datacentre with jumbo frames — with a recommended algorithm and MTU for each.
Measure RTT with ping or the network latency calculator before you start; an assumed RTT makes every number downstream wrong. For addressing and path work, the subnet calculator is the companion tool.
Divide the window size in bits by the round-trip time in seconds: throughput = window × 8 ÷ RTT. A 64 KB window over a 100 ms RTT yields about 5.2 Mbps regardless of link capacity.
BDP is bandwidth multiplied by round-trip time — the volume of data in flight on the path at any instant. It is the minimum window and buffer size needed to keep the link fully utilised.
Yes. Free, no account, and every calculation runs in your browser.
At least the BDP. For a 1 Gbps path at 150 ms RTT that is about 17.9 MB — far beyond the unscaled 64 KB maximum, so window scaling is mandatory.
Almost always a window smaller than the BDP, window scaling blocked by a middlebox, or a small amount of packet loss. Run the numbers on all three tabs before blaming the circuit.
Maximum segment size is the TCP payload per packet: MTU minus the IP header minus the TCP header and options. For a 1500-byte MTU with IPv4 and timestamps that is 1448 bytes; with IPv6 it is 1428.
Roughly by the square root of the loss rate. Using the Mathis equation, 1448-byte segments at 150 ms RTT reach about 3 Mbps at 0.1% loss and about 0.94 Mbps at 1% loss.
Inside a datacentre where every device on the path supports MTU 9000, yes — MSS rises from 1448 to 8948 and per-packet overhead falls sharply. Across the internet, no: a single hop with a 1500-byte MTU causes fragmentation or black-holing.
CUBIC is the Linux default and strong on high-BDP paths with little loss. BBR estimates available bandwidth and RTT instead of inferring congestion from loss, so it usually wins on lossy long-haul, satellite and wireless paths.
Yes. Bandwidth, RTT, window size, MTU, loss rate and the other inputs are encoded into the page URL, so copying the link reproduces the exact scenario.
Calculate optimal TCP window size for your network conditions to maximize throughput.
Window Size = Bandwidth × Round Trip Time
The bandwidth-delay product is the amount of data that can be in transit on a network path at any given time. It is calculated by multiplying the link bandwidth by the round-trip time (RTT). Understanding your BDP is essential because your TCP window size must be at least equal to the BDP to fully utilize your available bandwidth.
TCP window scaling is an extension that allows window sizes larger than 64 KB. It is required when your BDP exceeds 64 KB, which is common on high-bandwidth or high-latency links. Without window scaling enabled, your throughput will be severely limited regardless of your actual bandwidth.
Packet loss significantly reduces TCP throughput because the protocol must retransmit lost packets and reduce its sending rate. The Mathis formula shows that throughput is roughly proportional to 1 divided by the square root of the loss rate. Even a 1 percent loss rate can reduce throughput to a fraction of the available bandwidth.
MTU (Maximum Transmission Unit) is the largest packet size that can be sent on a network link, typically 1500 bytes for Ethernet. MSS (Maximum Segment Size) is the largest amount of TCP data that can fit in a packet after subtracting IP and TCP headers. For IPv4 with standard headers, MSS equals MTU minus 40 bytes.
Each operating system has different commands for TCP tuning. On Linux, use sysctl commands to adjust tcp_rmem and tcp_wmem values. On Windows, use netsh interface tcp commands to configure auto-tuning levels. On macOS, use sysctl to modify net.inet.tcp settings. The Buffer Tuning tab provides specific commands for each OS.
BBR (Bottleneck Bandwidth and Round-trip propagation time) is recommended for high-latency or lossy networks as it adapts better to real-world conditions. CUBIC is the default on most Linux systems and works well for general use. The Congestion Control tab helps you choose the right algorithm based on your network characteristics and operating system.