TCP Throughput & Window Size Calculator
Enter link speed, RTT, packet loss, MSS, overhead, and receive window to estimate single-stream TCP throughput. The calculator also sizes the window, loss budget, and stream count needed for a target utilization.
Single-stream TCP throughput (Mbps)17.81
- Payload-capable link rate (Mbps)
- 949.28
- Primary limiting factor
- Packet loss
- Bandwidth-delay product (KiB)
- 9,270.36
- Receive window needed for target (KiB)
- 8,343.32
- Packet-loss throughput ceiling (Mbps)
- 17.81
- Receive-window throughput ceiling (Mbps)
- 1,677.72
- Maximum tolerable loss for target
- 0%
- Parallel streams needed
- 48
- One-stream transfer time
- 1 hour, 20 minutes, 23 seconds
- Transfer time with recommended streams
- 1 minute, 40 seconds
Payload efficiency is 94.93% after the entered per-packet overhead.
The tolerable-loss result assumes the receive window and link ceiling can meet the target.
How to use this calculator
- Enter the slowest link speed on the path and the measured round-trip time.
- Enter packet loss as an end-to-end packet probability, then set MSS and per-packet overhead.
- Set the effective TCP receive window, payload size, and target utilization.
- Use the limiting factor, window size, loss budget, and stream count to plan the transfer.
How TCP throughput is calculated
This calculator separates three ceilings that often get mixed together: the payload rate the link can carry after packet overhead, the loss-limited TCP rate from the Mathis model, and the rate allowed by the receive window over the measured round-trip time.
Let B be link speed in bits per second, R be RTT in seconds, m be MSS bytes, h be non-payload bytes per packet, p be packet-loss probability, W be receive-window bits, and S be payload bits to transfer. Payload efficiency is:
E = m / (m + h)
The payload-capable link rate is:
L = B x E
The packet-loss ceiling uses the common Mathis approximation:
T_loss = 1.22 x 8m / (R x sqrt(p))
When packet loss is zero, the Mathis ceiling is treated as unbounded. At 100% packet loss, the calculator reports no usable TCP transfer. The receive-window ceiling is:
T_window = W / R
Single-stream throughput is the minimum of L, T_loss, and T_window. Bandwidth-delay product is L x R / 8 bytes, which is the one-way amount of payload data needed in flight to fill the path. The window needed for a target is T_target x R / 8 bytes, where T_target = L x utilization.
What moves the result most
RTT and packet loss dominate long-distance TCP estimates. A small loss probability can cut the Mathis ceiling sharply because loss appears under a square root in the denominator. Receive window matters when the sender cannot keep enough bytes in flight to cover the bandwidth-delay product. Overhead matters most when MSS is small or when tunnels, VPNs, VLAN tags, or other encapsulation add bytes to every packet.
The reverse loss calculation solves the Mathis equation for p at the target throughput. If the entered receive window is already below the target, the loss number is labeled conditional because reducing loss alone is not sufficient; the window must also be increased or more streams must be used.
What this calculator leaves out
The result is a planning estimate for a long-lived flow. It does not model slow start, retransmission timeouts, delayed acknowledgments, application pacing, disk speed, CPU limits, socket buffers, traffic shaping, competing flows, or middlebox behavior. Modern congestion controls such as CUBIC and BBR may respond differently from the classic loss-based behavior represented by the Mathis equation.
Worked example
For the default case, use a 1,000 Mbps path, 80 ms RTT, 0.01% packet loss, 1,460-byte MSS, 78 bytes of per-packet overhead, a 16,384 KiB receive window, a 10 GiB transfer, and a 90% target utilization.
The payload efficiency is 1,460 / (1,460 + 78), or 94.93%, so the payload-capable link rate is about 949.28 Mbps. The receive-window ceiling is about 1,677.72 Mbps, but the Mathis loss ceiling is only about 17.81 Mbps, making packet loss the primary limiter. The bandwidth-delay product is about 9,270.36 KiB, and a 90% target needs about 8,343.33 KiB of receive window per stream.
At 17.81 Mbps, one stream transfers 10 GiB in about 1 hour, 20 minutes, 23 seconds. Reaching the 90% target takes 48 similar streams, which cuts the estimated transfer time to about 1 minute, 40 seconds, capped by the payload-capable link rate.
Common questions
Why does a small amount of packet loss reduce TCP throughput so much?
Classic TCP congestion avoidance treats loss as a signal to reduce the congestion window. In the Mathis approximation, throughput is inversely related to the square root of packet-loss probability, so moving from almost no loss to a measurable loss rate can reduce one-stream throughput by a large amount.
What TCP window size do I need for a high-latency connection?
Start with the bandwidth-delay product: payload-capable link rate multiplied by RTT, then divided by eight to convert bits to bytes. A single stream needs at least that much effective receive window to fill the path before loss and other bottlenecks are considered.
What is the bandwidth-delay product?
Bandwidth-delay product is the amount of data that can be in flight on a path. For TCP, it is a useful window-size target because a sender cannot keep a high-rate, high-latency path full unless enough unacknowledged data is allowed on the wire.
Why can multiple TCP streams transfer faster than one stream?
Each stream has its own congestion and receive-window limits. Several streams can add their ceilings together until the aggregate reaches the payload-capable link rate, although real networks may not scale linearly or share capacity fairly.
Should I use 1460 bytes for MSS?
Use 1460 bytes for a typical IPv4 TCP path over a 1500-byte Ethernet MTU with no TCP options counted in MSS. Lower the value when tunnels, VPNs, PPPoE, IPv6 headers, or path MTU limits reduce the TCP payload carried in each segment.
Why might an iperf test differ from this estimate?
iperf measures the actual sender, receiver, operating system, congestion control, buffers, CPU, and path conditions at the time of the test. This calculator is a model, so slow start, retransmission timeouts, traffic shaping, interrupt limits, or a modern congestion controller can move the measured result above or below the estimate.