{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}

{{ gate.label }}
Presets are planning baselines, not measurements of the current route.
Network rate units are decimal bits per second.
Higher RTT requires more data in flight to fill the same link.
ms
The model applies this window independently to each stream.
Small loss percentages can dominate long-RTT TCP transfers.
%
Start with one stream unless the application deliberately uses concurrency.
streams
GB and TB are decimal; GiB and TiB are binary.
Custom uses zero overhead and a 1460-byte MSS; presets are planning estimates.
The default 100% is neutral.
%
The default 0% is neutral and avoids double-counting entered loss.
%
Zero disables the packet-rate ceiling.
kpps
This value is inactive while the packet-rate ceiling is zero.
bytes
MetricValuePlanning meaningCopy
{{ row.metric }}{{ row.value }}{{ row.note }}

{{ guidance.heading }}

{{ guidance.summary }}

Next test
{{ guidance.nextTest }}
Window target
{{ formatBytes(model.required_window_bytes) }} per stream
Stream target
{{ formatInteger(model.required_streams) }} stream{{ model.required_streams === 1 ? '' : 's' }}

Calculation record

{{ formulaText }}
  • This is a planning estimate, not a live path measurement or provider-performance verdict.
  • Endpoint CPU, storage, encryption, shaping, burst loss, and application limits can reduce real throughput.
  • Compare tests only when direction, protocol, payload size, route, and competing traffic are similar.
WAN Latency Calculator Estimate WAN round-trip latency from route distance and path overhead to compare target headroom, dominant delays and serial application wait.
Bandwidth Delay Product Calculator Calculate bandwidth-delay product and per-stream TCP window targets from path rate and RTT, then compare current buffers and stream counts.
LACP Bundle Capacity Calculator Calculate usable LACP bundle capacity after failed links, reserve, and hash-efficiency discounts while checking aggregate and single-flow headroom.
File Transfer Time Calculator Estimate file transfer time from size and sustained bandwidth while accounting for TCP limits, overhead, compression and a required finish window.

A 1 Gbps link does not promise a 1 Gbps file transfer. The line rate is only the upper boundary before framing, shared use, latency, TCP flow control, packet loss, packet-processing limits, and application overhead reduce the useful rate.

Throughput is the amount of useful data delivered per unit of time. Bandwidth or link capacity describes how much the link can carry under ideal conditions. Transfer time follows from useful throughput, not from the label on the interface or service plan. This distinction matters when sizing backup windows, replication jobs, storage migration, remote builds, or wide-area application traffic.

LimitWhat causes itTypical clue
Payload linkFraming overhead, traffic share, shapingMany flows stop near the same aggregate rate
TCP window and RTTNot enough unacknowledged data in flightOne flow is slow on a high-delay path and improves with a larger window or more streams
Packet lossCongestion response and retransmissionThroughput falls sharply even though capacity and window appear sufficient
Packet rateFirewall, tunnel, NIC, virtual router, or CPU packets-per-second ceilingSmall packets hit a limit before link bandwidth

Round-trip time (RTT) controls how long a sender waits for acknowledgements. The bandwidth-delay product is the amount of data that must be in flight to fill a path at a chosen rate. A 1 Gbps path with 100 ms RTT needs far more window space than a same-rack path, even though both links may advertise the same capacity.

Loss changes the picture again. TCP reduces its sending rate when it interprets packet loss as congestion. A small sustained loss percentage can dominate a long-RTT path. Multiple streams may overcome a per-stream window limit, but they do not repair a lossy route and can add more contention.

Packets per second provide another independent ceiling. The same bit rate requires more packets when useful payload per packet is smaller. Tunnels, encryption, network address translation, and security inspection often expose a packet-processing limit that is invisible in a pure bandwidth calculation.

  • Keep bits and bytes distinct: network rates use bits per second, while file and window sizes are entered as bytes.
  • Compare decimal MB, GB, and TB separately from binary MiB, GiB, and TiB.
  • Use measured RTT, loss, and packet rate from the affected path when available; presets are only planning examples.
  • Treat modeled transfer time as a lower-bound estimate before storage, protocol, encryption, and application delays.

A useful forecast names the active bottleneck and the assumptions behind it. The result should be tested from the actual endpoints with the same route, packet size, concurrency, and traffic conditions as the intended workload.

How to Use This Tool:

Enter the path as it will operate during the transfer, then compare the independent ceilings instead of assuming the link rate controls everything.

  1. Set the Link capacity and unit, then choose a Framing profile and realistic Link share. The payload-link ceiling falls when overhead or competing traffic rises.
  2. Choose a Path profile or enter measured Round-trip latency and Packet loss. Editing those values makes the path custom.
  3. Enter the TCP receive window and Parallel streams. Use the window available to each stream, not a host-wide memory limit.
  4. Enter the transfer size with the correct decimal or binary unit. This changes transfer time, not the throughput ceilings.
  5. Add a packet-rate ceiling only when a device or host has a measured packets-per-second limit. Pair it with the expected useful packet payload. Zero leaves that ceiling out of the minimum.
  6. Read Estimated effective throughput, Primary bottleneck, required window, required streams, and transfer time together. Test the indicated constraint before buying bandwidth or changing every setting at once.

Interpreting Results:

The primary bottleneck is the smallest modeled ceiling before the separate retry penalty. A link-limited result points to payload capacity or link share. A window result points to bytes in flight relative to RTT. Loss and packet-rate results identify their corresponding planning formulas as the lowest bound.

Estimated effective throughput applies the entered retry penalty after choosing the smallest ceiling. Utilization compares that final rate with the payload-link ceiling, not with the raw line rate. A low percentage therefore means another modeled constraint is active; it does not identify every real-world cause of slowness.

Confirm the result with a sustained transfer. Keep the endpoints, route, test direction, stream count, packet size, and test window consistent. Storage throughput, CPU, encryption, shaping, Wi-Fi, and application behavior can all lower the measured rate without appearing in the model.

Technical Details:

The model converts every rate to bits per second and every size to bytes. It computes four independent ceilings, selects the smallest, applies an optional retry penalty, and divides transfer bits by the resulting throughput.

Formula Core

Payload capacity is reduced by framing overhead and the usable link share before transport limits are compared.

Cpayload =C×(1−O) ×S Cwindow =W×8×nRTT Closs = 1.22×MSS×8 RTT×p Cpacket =K×1000×L×8 Ceffective =min( Cpayload, Cwindow, Closs, Cpacket) ×(1−R) ttransfer =F×8Ceffective
SymbolMeaningCanonical unit
CRaw link capacitybps
OFraming-overhead percentage divided by 100ratio
SLink-share percentage divided by 100ratio
WTCP receive window per streamB
nParallel TCP streamscount
RTTRound-trip times
pPacket-loss percentage divided by 100probability
KPacket-rate ceilingkpps
LUseful payload per packetB
RRetry-penalty percentage divided by 100ratio
FTransfer sizeB

Zero packet loss removes the finite Mathis/Reno loss ceiling from the minimum. A packet-rate value of zero likewise leaves packet processing unmodeled. The displayed comparison uses the payload-link ceiling as a visual reference for either inactive limit.

The bandwidth-delay product is payload-link bits per second multiplied by RTT seconds and divided by eight. Required receive window divides that byte count by the stream count. Required streams round up the payload-link ceiling divided by one stream's window-and-RTT ceiling.

Framing profileOverheadMSS used for loss formula
Custom / no overhead0%1460 B
Ethernet TCP payload3%1460 B
TLS file copy5%1448 B
VPN / tunnel12%1360 B
Jumbo-frame LAN1%8960 B

Intermediate values keep full numeric precision. Displayed rates and durations are rounded for readability, while the transfer-time calculation uses the unrounded effective throughput.

Accuracy Notes:

The loss equation is a planning approximation associated with congestion-avoidance behavior, not a complete model of every TCP version, recovery algorithm, queue, or burst pattern. Preset RTT, loss, overhead, and MSS values are illustrative and should be replaced with measured values for a real path.

  • Application framing, encryption, compression, storage speed, CPU, and kernel tuning are outside the calculation.
  • Average loss does not describe burst length, reordering, jitter, or asymmetric conditions.
  • Parallel streams can change contention and fairness; the model scales window capacity linearly and does not simulate competing flows.

Worked Examples:

Short metro transfer

A 1 Gbps link with the 3% Ethernet TCP planning overhead leaves a 970 Mbps payload ceiling. At 2 ms RTT, a 4 MiB receive window and one stream provide ample window capacity, while 0.001% loss still leaves a higher planning ceiling. The link is therefore the modeled bottleneck, and 25 GB takes about 206 seconds at 970 Mbps.

High-latency window limit

On a 1 Gbps path with 100 ms RTT, no modeled loss, and a 1 MiB receive window, one stream is limited to 83.886 Mbps. The bandwidth-delay product is 12.5 MB, and the estimate calls for about 12 such streams or a larger per-stream window to approach the payload-link ceiling.

References: