Estimate a single TCP connection’s sustained throughput from effective window size, round-trip time, packet
loss, MSS, and optional link capacity. Compare the receive-window ceiling with a Reno-style loss model, size
the window for a target rate, and estimate transfer time.
Private by design: calculator inputs and results stay in your browser.
Connection inputs
Estimated throughput
Combined estimate-
Window / RTT ceiling-
Reno loss estimate-
Limiting factor-
Target and path sizing
Target status:-
Required effective window for target:-
Current window headroom vs target:-
Modeled maximum loss for target:-
Bottleneck bandwidth-delay product:-
TCP Window Scale requirement:-
Transfer estimate
Transfer size:-
Ideal sustained transfer time:-
Estimated payload per RTT:-
How to use the TCP throughput calculator
Enter the effective window: use the smallest practical per-flow limit imposed by receive-window, send-buffer, or other known configuration.
Measure RTT: use a representative end-to-end round-trip time rather than one-way latency.
Add packet loss and MSS: use a sustained path loss rate and the payload MSS after IP and TCP headers.
Set the target and link: the optional bottleneck rate caps the estimate and lets the calculator determine the BDP.
Read all three ceilings: the combined estimate is the lowest of window/RTT, Reno loss, and optional link capacity.
Combined estimate:minimum(window ceiling, loss estimate, optional link rate)
Required target window / BDP:target bits per second × RTT seconds ÷ 8
Modeled loss budget:(factor × MSS × 8 ÷ (RTT × target bits per second))²
The Mathis model describes a long-lived TCP Reno-style flow in congestion avoidance with sufficient data,
independent loss, and no retransmission timeouts. The default coefficient is 1.22. When loss is zero, the
calculator does not treat the loss formula as an infinite promise; window size and the optional link remain
the active ceilings.
Worked examples
Window
RTT
Loss
Window ceiling
Reno estimate (MSS 1460, factor 1.22)
64 KiB
40 ms
0%
13.11 Mbps
Not loss-limited
1 MiB
40 ms
0.01%
209.72 Mbps
35.62 Mbps
16 MiB
80 ms
0.001%
1.68 Gbps
56.32 Mbps
32 MiB
10 ms
0.0001%
26.84 Gbps
1.42 Gbps
Values are payload-rate planning estimates before application overhead and real implementation behavior.
How to interpret the limiting factor
Window / RTT
The connection cannot keep enough data in flight to fill the target path. Increase the effective receive
window and sender buffer, confirm Window Scale was negotiated, or reduce RTT. A window at least as large as
the bandwidth-delay product is necessary but does not guarantee the target rate.
Reno packet-loss model
The selected loss rate makes a classic Reno-style congestion window the smaller modeled constraint. Find and
fix congestion or physical loss, check retransmissions and ECN behavior, and compare with the actual congestion
controller. Parallel flows may change aggregate throughput but also compete with other traffic.
Bottleneck link
The configured path capacity is the smallest ceiling. A TCP payload rate will normally remain below raw line
rate because Ethernet, IP, TCP, acknowledgments, encryption, and application protocols consume capacity.
Last reviewed: July 2026. All calculations are deterministic and run locally in the browser.
TCP throughput FAQs
How does TCP window size limit throughput?
A sender can keep only the effective window of unacknowledged data in flight. In the ideal no-loss case, the window-limited ceiling is window bytes multiplied by 8 and divided by RTT in seconds.
Why does packet loss reduce TCP throughput?
Loss signals congestion to loss-based TCP and reduces its congestion window. This calculator uses the Mathis square-root model as a steady-state Reno-style estimate for independent, light-to-moderate loss.
What is bandwidth-delay product?
BDP is bottleneck bits per second multiplied by RTT seconds. Divide it by 8 for the minimum bytes of in-flight data needed to fill the path in an ideal steady state.
Does a window larger than 65,535 bytes require Window Scale?
Yes. The header window field is 16 bits. RFC 7323 Window Scale negotiates a multiplier during the handshake so effective receive windows can exceed 65,535 bytes.
Is this accurate for CUBIC or BBR?
The window and link ceilings still matter, but the Mathis loss model describes Reno-style congestion avoidance. CUBIC and BBR react differently, so measure the actual path and TCP implementation.
Should I enter receive window, congestion window, or socket buffer?
Enter the effective in-flight window available to one flow. In practice throughput is constrained by the smaller of the sender limit, advertised receive window, congestion window, and implementation limits.
Why can a speed test differ from this estimate?
Real transfers include slow start, changing RTT, application behavior, protocol overhead, retransmission timeouts, burst or correlated loss, host limits, competing traffic, and possibly multiple TCP flows.
Are my inputs uploaded?
No. Calculations run locally in the browser and the tool does not submit calculator inputs to a backend.
Planning limits
This calculator is an infrastructure planning aid, not a capacity guarantee. Validate important designs with
host TCP statistics, packet captures, retransmission counters, path MTU tests, controlled single-flow and
multi-flow measurements, and the actual congestion-control algorithm used in production.
Starlight Tools