Network Throughput Calculator

Path preset:

Use Custom for measured RTT/loss; presets include LAN, metro, regional, oceanic, and GEO satellite paths.

Link capacity:

Enter the advertised or shaped rate, such as 500 Mbps, 1 Gbps, or 10 Gbps.

Round-trip latency:

Enter idle RTT in milliseconds from ping, mtr, traceroute, or path monitoring.

TCP receive window:

Enter the effective per-stream receive window, for example 1 MiB, 16 MiB, or 64 MiB.

Packet loss:

Enter measured packet loss from 0 to 30%; use 0 only for a clean sustained path.

Parallel streams:

Use a whole number from 1 to 128; start with 1 for a single-stream copy.

flows

Transfer size:

Enter payload size such as 700 MB, 10 GiB, 250 GB, or 1 TB.

Framing preset:

Choose Ethernet TCP, TLS file copy, VPN tunnel, jumbo LAN, or Custom.

Loss profile:

Keep Reno unless you are deliberately modeling a more conservative or aggressive stack.

Planning target:

Choose the payload-link fill target to budget: 60%, 75%, 85%, 95%, or 100%.

Protocol overhead:

Enter 0 to 40%; TLS file copy is often near 5%, VPN tunnels can be higher.

Link share: {{ link_share_pct }}%

Use 100% for a dedicated path; lower it for shaped, contended, or policy-limited links.

TCP MSS:

Enter 256 to 8960 bytes; 1460 is common Ethernet, jumbo paths can be larger.

bytes

Packet-rate ceiling:

Enter thousands of packets per second; set 0 when no packet-rate ceiling is known.

kpps

Planner packet payload:

Enter average payload bytes per packet, 64 to 16384; use MSS-sized values for full-size TCP.

bytes

Retransmission penalty:

Enter 0 to 30%; keep 0 when the loss percentage already covers retransmits.

Observed throughput:

Enter an iperf or file-copy payload rate with units; set 0 for estimate-only mode.

Loaded RTT:

Enter loaded RTT in milliseconds from the same test, or 0 to skip delay comparison.

Throughput precision:

Enter an integer from 0 to 8 decimal places; 3 keeps Mbps readable.

Metric	Value	Copy
{{ row.label }}	{{ row.value }}

Area	Badge	Finding	Detail	Copy
{{ card.heading }}	{{ card.badge }}	{{ card.title }}	{{ card.detail }}

Planning line	Value	Copy
{{ row.label }}	{{ row.value }}

Target Fill	Needed Throughput	Window / Stream	Streams @ Current Window	Needed Packet Rate	Max Packet Loss	Window Scale	Readiness	Copy
{{ row.targetFillLabel }}	{{ row.targetThroughput }}	{{ row.windowPerStream }}	{{ row.streamsNeededLabel }}	{{ row.packetRateNeededLabel }}	{{ row.lossBudget }}	{{ row.scaleLabel }}	{{ row.readiness }}

Action	Expected Throughput	Gain	Est. Transfer Time	New Bottleneck	Copy
{{ row.action }}	{{ row.throughput }}	{{ row.gain }}	{{ row.transferTime }}	{{ row.newLimiter }}

Metric	Value	Copy
{{ row.label }}	{{ row.value }}

Field	Value	Copy
{{ row.label }}	{{ row.value }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A large transfer can cross a fast circuit and still arrive slowly. The rate that matters to the application is throughput, often called goodput when only useful payload bytes are counted. It sits below advertised bandwidth whenever headers, encryption, queueing, retransmissions, small packets, or transport limits consume part of the path.

Throughput is easiest to misread when bandwidth is treated as the only ceiling. A 1 Gbps link can move close to 1 Gbps on a clean local path, yet the same port may deliver a small fraction of that rate across a high-latency WAN. The difference is not only distance. TCP has to keep enough unacknowledged data in flight, recover from loss, and fit the transfer through any firewall, tunnel, overlay, or shaper in the route.

The bandwidth-delay product, or BDP, gives the first useful mental model. It is the amount of data needed in flight to fill the path while acknowledgments travel back. If the receive window is smaller than the BDP, a single stream pauses for acknowledgments before the link is full. Parallel streams can help a window-limited transfer because each stream contributes another window, but they do not remove packet loss, tunnel overhead, or packet-rate limits.

A network path passing through link, window, loss, and packet-rate gates before reaching effective throughput.

Several different ceilings can dominate the same transfer. Bandwidth decides the raw upper bound. Framing overhead and link sharing decide how much of that bandwidth remains for payload. RTT and window size decide how much one or several TCP streams can keep in flight. Packet loss lowers the congestion-avoidance ceiling, especially over long RTTs. Packet-rate processing can be the limit on firewalls, VPNs, virtual routers, small-packet workloads, and CPU-bound overlays.

Bandwidth is capacity. It describes the line or policy rate before payload overhead, sharing, and transport behavior are considered.
Throughput is sustained delivery. It is the useful rate a transfer actually carries after the active ceiling is applied.
Transfer time depends on payload size. The same rate may be acceptable for a small backup and impossible for a multi-terabyte copy window.
Field tests need matching conditions. Direction, protocol, payload size, time of day, and competing traffic all change whether two measurements can be compared.

A network throughput estimate is a planning baseline, not a verdict by itself. It can point toward the most likely limiter and help choose the next test, but provider claims, application performance disputes, and capacity purchases still need sustained measurements from the real endpoints and path.

How to Use This Tool:

Start with measured path values when you have them. Presets are useful for early planning, but live RTT, loss, and observed throughput give the estimate more weight.

Choose Path preset when you need a starting point, or keep Custom and enter measured Round-trip latency and Packet loss. The path-gate visual will update to show which ceiling is active after the model runs.
Set Link capacity to the shaped, committed, or physical rate you want to test. Use Link share in Advanced when the transfer only receives part of a shared circuit.
Enter TCP receive window and Parallel streams. Watch Window needed per stream for full link and Streams needed with current window to see whether more in-flight data is required.
Set Transfer size so Transfer time at estimated throughput reflects the job you are planning, not just an abstract rate.
Choose a Framing preset or set Protocol overhead and TCP MSS manually. Tunnel and TLS assumptions change both the payload ceiling and the loss calculation.
Use Packet-rate ceiling only when you know a packets-per-second limit for a firewall, tunnel, virtual appliance, or CPU path. A value of 0 leaves that ceiling out of the estimate.
Add Observed throughput and Loaded RTT after a comparable test. Field Check then compares the measured rate with the modeled rate and flags queue growth when loaded RTT rises above the baseline RTT.

If the result shows No effective throughput, or if a number looks wildly different from your test, first check units: Mbps versus MB/s, decimal GB versus binary GiB, percent loss versus fraction loss, and kpps versus pps are common causes of wrong planning numbers.

Interpreting Results:

Estimated effective throughput is the modeled payload rate after overhead, link share, transport ceilings, packet-rate limits, and any retransmission penalty. Primary bottleneck names the smallest active ceiling, and Transfer time at estimated throughput turns that rate into a schedule estimate.

Payload link ceiling is the usable payload rate after protocol overhead and link share, not the raw port speed.
Window-limited ceiling is the aggregate rate allowed by receive window, RTT, and stream count.
Loss-limited ceiling is a planning estimate from packet loss, RTT, MSS, and the selected loss profile. When Packet loss is 0%, this ceiling is not constrained.
Packet-rate ceiling appears only when a kpps limit is entered. When Packet-rate ceiling is 0, the output reports it as not modeled.
Planning target readiness explains the first missing requirement for the selected fill target: lower loss, larger window, more streams, or more packet-rate headroom.
Field-check status matters only when Observed throughput is from a comparable sustained test on the same direction, protocol, and path.

A healthy estimate does not prove the application will finish on time. Endpoint CPU, disk speed, encryption, application throttles, asymmetric routes, microbursts, and competing traffic can still lower the real rate. Use Observed vs modeled throughput, Loaded RTT delta, and the active bottleneck together before deciding what to change.

Technical Details:

Payload throughput is governed by the smallest ceiling that the transfer reaches. A capacity ceiling starts with raw link speed and removes non-payload overhead and any configured share of the link. A window ceiling follows directly from BDP: bytes in flight multiplied by eight, divided by RTT. A loss ceiling uses a Mathis-style TCP congestion-avoidance approximation, where higher RTT, smaller MSS, or larger packet-loss probability lowers the sustainable rate. A packet-rate ceiling converts a packets-per-second cap into bits per second by multiplying packets by average payload bytes.

The model treats the ceilings as concurrent limits and then applies the retransmission penalty after the smallest ceiling is found. That order matters. If loss already reduces the model to 25 Mbps, a 1 Gbps link upgrade alone does not move the estimate. If the packet-rate ceiling is 160 Mbps, larger TCP windows do not help until packet processing or payload size changes.

Formula Core:

The main calculation compares payload capacity, window capacity, loss capacity, and packet-rate capacity, then uses the smallest value as the modeled ceiling.

\begin{array}{lcl} R_{payload} & = & R_{link} \times (1 - \frac{overhead}{100}) \times \frac{share}{100} \\ R_{window} & = & \frac{W \times 8 \times N}{RTT} \\ R_{loss} & = & \frac{C \times MSS \times 8}{RTT \times \sqrt{p}} \\ R_{packet} & = & kpps \times 1000 \times payloadBytes \times 8 \\ R_{effective} & = & \min (R_{payload}, R_{window}, R_{loss}, R_{packet}) \times (1 - \frac{retryPenalty}{100}) \\ time & = & \frac{fileBytes \times 8}{R_{effective}} \end{array}

Here W is the per-stream TCP receive window in bytes, N is the number of parallel streams, RTT is seconds, C is the selected TCP loss coefficient, MSS is bytes, and p is packet-loss probability as a fraction. The loss ceiling is ignored when loss is exactly 0%. The packet-rate ceiling is ignored when the kpps input is 0. Display precision rounds visible and exported numbers but does not change the calculation.

A clean 1 Gbps path with 12 ms RTT and one 1 MiB receive window has a window ceiling near 699.051 Mbps, because 1 MiB can only keep about 8.39 million bits in flight for each RTT. Filling the same payload link at that RTT needs about 1.431 MiB per stream, or 2 streams at the current window size.

Throughput ceilings and the evidence to verify
Ceiling	What makes it active	Output to verify
`Link Capacity`	Payload capacity after overhead and link share is lower than the transport and packet limits.	`Payload link ceiling`, `Link utilization at estimate`, and shaping or competing-traffic evidence.
`TCP Window/RTT`	The current receive window and stream count cannot cover the BDP for the target fill rate.	`Window needed per stream for full link`, `Current window coverage of full-link target`, and `TCP window scaling posture`.
`Packet Loss`	The Mathis-style loss ceiling falls below link, window, and packet-rate ceilings.	`Loss-limited ceiling`, `Max packet loss for planning target`, and sustained retransmission or drop counters.
`Packet Rate`	The entered kpps cap multiplied by average packet payload is below the other ceilings.	`Packet-rate ceiling`, `Estimated packet rate`, and packet counters on the suspected device.
`Mixed Constraints`	Several ceilings sit close together or the estimate reaches zero, so one change may not explain the result.	`Bottleneck Brief`, `Scenario Ladder`, and one controlled retest after changing a single assumption.

Window scaling matters when the receive-window target exceeds the classic 65,535 byte TCP window field. Modern TCP can negotiate a scale factor during connection setup, but middleboxes, operating-system policy, small application buffers, or disabled autotuning can still leave a high-BDP path short of the required in-flight bytes.

Accuracy Notes:

The estimate is a deterministic planning model. It does not send test traffic, discover the route, read device counters, or prove service-provider performance.

Average packet loss can hide burst loss, retransmission storms, and congestion episodes that harm real transfers more than a single percentage suggests.
The Mathis-style loss ceiling is a heuristic for TCP behavior, not a full simulation of every congestion-control algorithm, receiver policy, or offload feature.
Packet-rate estimates depend on the average payload bytes per packet. Small-packet workloads can hit a kpps ceiling far earlier than full-size TCP streams.
Observed throughput is only comparable when the test direction, protocol, payload size, endpoint load, route, and time window match the entered assumptions.

Worked Examples:

A cross-country file copy with 1 Gbps capacity, 40 ms RTT, 5% overhead, 0.02% packet loss, four 16 MiB streams, and a 250 GB transfer still lands near 24.983 Mbps. Primary bottleneck should read Packet Loss, and Transfer time at estimated throughput is about 22.24 hours, so adding more streams is not the first fix.

A branch VPN with 500 Mbps capacity, 25 ms RTT, 12% tunnel overhead, very low 0.0001% loss, a 40 kpps appliance limit, and 512 byte packet payloads becomes packet-rate limited. Packet-rate ceiling is about 163.840 Mbps, below the 440.000 Mbps payload link ceiling, so larger TCP buffers would not remove the active constraint.

A clean regional path at 1 Gbps, 12 ms RTT, one 1 MiB receive window, one stream, and 0% loss is a window example. Window-limited ceiling is about 699.051 Mbps, while Streams needed with current window is 2. Raising stream count or receive window can move the estimate until the payload link becomes the limiter.

A field test that records 320 Mbps on a modeled 950 Mbps clean path should be treated as a troubleshooting signal. When Loaded RTT rises from 35 ms to 70 ms, Field-check status should report that the observed test trails the model, and Loaded RTT delta points toward queueing, shaping, or shared-path pressure before a bandwidth upgrade is blamed.

FAQ:

Why is the estimate lower than the link speed?

The estimate starts from link capacity, removes overhead and link share, then compares the payload link with window, loss, and packet-rate ceilings. The smallest active ceiling becomes Estimated effective throughput.

Why does tiny packet loss matter so much?

The loss formula worsens as RTT rises and as the square root of loss probability rises. A small loss percentage can therefore dominate long-distance TCP transfers even when the raw circuit is fast.

When should I increase parallel streams?

Increase streams when Primary bottleneck is TCP Window/RTT and Streams needed with current window is higher than the current stream count. More streams will not fix packet loss or a packet-rate cap by themselves.

Why does packet-rate ceiling say not modeled?

A Packet-rate ceiling value of 0 disables that ceiling. Enter a kpps limit only when you have a device, tunnel, firewall, or CPU packet-processing limit to test.

Should I compare Mbps with MB/s?

Network rates are usually bits per second, while file-copy tools often show bytes per second. Compare Estimated effective throughput with Estimated payload rate before deciding whether a test result is low.

Can this prove a provider is underperforming?

No. It creates a planning baseline and a bottleneck hypothesis. Use sustained tests, endpoint counters, device counters, and comparable field evidence before turning the estimate into an operational claim.

Glossary:

Throughput: Useful data delivered per second across the path.
Goodput: Application payload rate after overhead, sharing, retries, and other non-payload costs.
BDP: Bandwidth-delay product, the amount of data needed in flight to fill a path at a given RTT.
RTT: Round-trip time, the delay for a packet to travel out and for the acknowledgment to return.
MSS: Maximum segment size, the TCP payload bytes used by the loss calculation.
Packet-rate ceiling: A packets-per-second processing cap that can limit throughput before bandwidth is exhausted.
Loaded RTT: Round-trip latency measured while the path is carrying the test transfer.
Window scaling: A TCP option that lets modern connections advertise receive windows larger than the classic 65,535 byte field.

References:

RFC 6349: Framework for TCP Throughput Testing, RFC Editor, August 2011.
RFC 7323: TCP Extensions for High Performance, RFC Editor, September 2014.
The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm, ACM SIGCOMM Computer Communication Review, July 1997.
Invoking iperf3, ESnet, November 2025.
How to test internet speed in Linux, Simplified Guide.
How to check network latency in Linux, Simplified Guide.

Network Throughput Calculator

{{ result.summaryTitle }}

Current result

How to Use This Tool:

Interpreting Results:

Technical Details:

Formula Core:

Accuracy Notes:

Worked Examples:

FAQ:

Glossary:

References:

Network Throughput Calculator

{{ result.summaryTitle }}

Current result

Introduction:

How to Use This Tool:

Interpreting Results:

Technical Details:

Formula Core:

Accuracy Notes:

Worked Examples:

FAQ:

Glossary:

References: