Network Latency Bandwidth Calculator

Enter a link rate, round-trip time and transfer size to see a single TCP flow’s real ceiling — with the bottleneck named, the transfer time and every substitution.

Path

The slowest hop on the path — often your plan’s rated speed.
Ping time to the far end — use the largest value you expect under load.

Transfer

The payload to move — a file, a backup, a dataset.

TCP parameters

Bytes the receiver can buffer. 65,535 is the unscaled maximum; empty = no window limit.
Payload bytes per packet — 1,460 fills a standard Ethernet frame. Empty = ignore overhead and loss.
Average packet loss probability. Empty or 0 = no loss limit.

Throughput and transfer time

Expected TCP throughput

—

Enter the link rate, round-trip time and data size.

Formulas and substitution

throughput = min(rate × eff, window ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = rate × RTT

    Every value you enter is computed in this browser — nothing is sent anywhere.

    FAQ

    Why is my transfer slower than the link rate I pay for?

    A single TCP flow faces three independent ceilings, and the lowest one wins. Protocol overhead trims the link itself by about 5% — a standard Ethernet frame carries 1,460 payload bytes out of 1,538 on the wire. The receive window caps throughput at window ÷ RTT, so the classic 65,535-byte window holds a 50 ms path to about 10.5 Mbit/s however fast the link is. And loss caps it at (MSS ÷ RTT) ÷ √loss. The result above names which ceiling is binding on your numbers.

    What is the bandwidth-delay product, and why does it set the window size?

    The BDP — link rate × round-trip time — is the amount of data in flight at any moment. TCP can have at most one unacknowledged window outstanding, so a window smaller than the BDP leaves the pipe partly empty: at 100 Mbit/s with a 50 ms RTT the pipe holds 625 kB, and a 65,535-byte window fills barely a tenth of it. That is why fast, long paths need TCP window scaling (RFC 7323), which raises the negotiable maximum from 65,535 bytes to about 1 GB.

    How does packet loss limit TCP throughput?

    TCP treats loss as congestion and halves its sending rate on every loss event, so even tiny loss rates matter on fast paths. The Mathis model estimates the ceiling as (MSS ÷ RTT) ÷ √p — at 0.01% loss on a 50 ms path with a 1,460-byte MSS that is about 23 Mbit/s, regardless of link speed. The model assumes evenly spread, independent loss events; below roughly 1% it tracks reality well, and for bursty loss it is optimistic.

    Are the megabytes here the same as in my file manager?

    Not quite. This page uses decimal units, the networking convention: 1 kbit = 1,000 bits and 1 MB = 1,000,000 bytes. Most file managers count in 1024-based units, often mislabeled MB — a “100 MB” file there is usually 100 MiB ≈ 104.86 decimal MB, so it takes about 5% longer to move than the decimal figure suggests. Enter 104.86 MB here to match it exactly.

    Written and reviewed by the BroBroGo editorial team.Last updated:

    Understanding TCP Throughput Ceilings

    A single TCP flow faces three independent performance ceilings, and the lowest of these limits dictates the actual transfer speed. These limits are determined by the physical link capacity, the receive window, and packet loss.

    The Network Latency Bandwidth Calculator computes the real-world performance ceiling of a single TCP flow based on network path conditions. By evaluating these three constraints, the tool identifies the active bottleneck limiting your connection, calculates the Expected TCP throughput, and estimates the total Transfer time.

    The calculations are based on the following primary formula: throughput = min(rate × eff, window ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = rate × RTT

    The active bottleneck is dynamically identified as one of the following constraints:

    • link capacity
    • the receive window
    • packet loss

    Input Parameters and Constraints

    To configure the network path, transfer payload, and TCP parameters, the tool requires specific inputs:

    • Link rate: The slowest hop on the path, which is often your plan's rated speed. This value must be greater than zero.
    • Round-trip time (RTT): The ping time to the far end, representing the largest value expected under load. This value must be greater than zero.
    • Data size: The payload to move, such as a file, backup, or dataset. This value must be greater than zero.
    • Receive window: The bytes the receiver can buffer. This value must be greater than zero and cannot exceed 1,073,725,440 bytes. Leaving this field empty indicates no window limit.
    • MSS (bytes): Payload bytes per packet. This must be a whole number of bytes between 1 and 65,495. Leaving this field empty ignores overhead and loss.
    • Packet loss (%): The average packet loss probability. This must be between 0 and 100 percent. Leaving this field empty or entering 0 indicates no loss limit.
    • Displayed decimals: Controls the decimal precision of the output values.

    The interface includes a Load example button to populate fields with sample data, a Clear button to reset the inputs, and a Copy result button to copy the computed data.

    Network Protocol Overhead and Efficiency

    Protocol overhead is modeled on standard Ethernet, which adds 78 bytes of overhead per packet. This consists of 40 bytes for TCP/IP headers and 38 bytes of physical wire overhead. This overhead reduces the raw link rate to a lower payload ceiling.

    The tool derives protocol efficiency and the link ceiling using these formulas:

    • Protocol efficiency = MSS ÷ (MSS + 78 B) (40 B packet headers + 38 B on the wire)
    • Link ceiling = rate × efficiency

    Because of this overhead, a standard Ethernet frame carrying 1,460 payload bytes out of 1,538 bytes on the wire trims the link capacity by approximately 5%.

    The Bandwidth-Delay Product and Window Scaling

    The Bandwidth-delay product (BDP) represents the volume of data "in flight" on a network path at any given moment. It determines the buffer sizes required to keep the network pipe full.

    The BDP and the window required to fill the path are calculated as follows:

    • BDP = rate × RTT
    • Window to fill the path = BDP ÷ 8

    If the receive window is too small, the connection cannot fully saturate the path. The window-limited throughput is calculated using the window ceiling formula:

    • Window ceiling = window ÷ RTT

    Window Scaling Rules (RFC 7323)

    • Unscaled Limit: The unscaled TCP window maximum is 65,535 bytes. If filling the path requires a window above this limit, both ends must negotiate TCP window scaling (RFC 7323). The tool displays this notice: "Filling this path needs a ‹window› window — above the 65,535-byte unscaled maximum, so both ends must negotiate TCP window scaling (RFC 7323)."
    • Absolute Limit: The absolute maximum window size TCP can negotiate via RFC 7323 window scaling is 1,073,725,440 bytes. If the required window exceeds this limit, the tool displays this notice: "Filling this path needs ‹window› — beyond the largest window TCP can negotiate (1,073,725,440 bytes). A single flow on this path can never exceed ‹value›."
    • Optimization Note: If a larger window would improve performance, the tool displays: "Raising the receive window to ‹window› would let this transfer reach up to ‹value›."

    The Impact of Packet Loss (The Mathis Model)

    TCP interprets packet loss as network congestion and reduces its sending rate. The tool uses the Mathis model to estimate the loss-limited throughput ceiling:

    • Loss ceiling (Mathis) = MSS ÷ RTT ÷ √p

    The Mathis loss model assumes evenly spread, independent packet loss. It is only reliable for loss rates below approximately 1%. If packet loss exceeds 1%, the tool flags the loss ceiling as optimistic and displays the warning: "Loss above 1% is outside the Mathis model’s reliable range — treat the loss ceiling as optimistic."

    Transfer Time Calculations and Model Exclusions

    The total estimated transfer time is calculated by adding the time to first byte (1 RTT) to the bulk transfer time:

    • Transfer time = RTT + 8 × size ÷ throughput = ‹rtt› + 8 × ‹size› ÷ ‹throughput› = ‹time›

    These calculations assume a steady-state, single TCP flow. Real-world factors such as TCP slow start, congestion-control tuning, slow receivers, and TLS handshakes are outside the scope of this model. Consequently, actual transfers will start slower and may perform below the calculated ceilings. No universal safety margin applies; every figure should be treated as an upper bound.

    All units in the calculator are decimal-based (e.g., 1 kbit = 1,000 bits, 1 MB = 1,000,000 bytes). File managers typically use 1024-based binary units, meaning a "100 MB" file in a file manager is actually 100 MiB (approximately 104.86 decimal MB).

    Local Processing and Privacy

    Every value you enter is computed locally in your browser — nothing is sent anywhere. The tool runs entirely in your web browser, performing all calculations locally without sending any of your entered data to external servers.

    Error Handling

    The calculator validates all inputs and displays specific error messages when constraints are violated:

    • If an input cannot be parsed: "Link rate: “abc” is not a number."
    • If the link rate is zero or negative: "The link rate must be greater than zero."
    • If the round-trip time is zero or negative: "The round-trip time must be greater than zero."
    • If the data size is zero or negative: "The data size must be greater than zero."
    • If the receive window is zero or negative: "The receive window must be greater than zero."
    • If the receive window exceeds the RFC 7323 limit: "TCP cannot negotiate a window above 1,073,725,440 bytes (RFC 7323 window scaling)."
    • If the MSS is out of bounds: "The MSS must be a whole number of bytes between 1 and 65,495."
    • If the packet loss is out of bounds: "The loss rate must be between 0 and 100 percent."
    • If calculations exceed system limits: "A value or intermediate result exceeds the supported number range."

    Frequently Asked Questions

    Why is my transfer slower than the link rate I pay for?

    A single TCP flow faces three independent ceilings, and the lowest one wins. Protocol overhead trims the link itself by about 5% — a standard Ethernet frame carries 1,460 payload bytes out of 1,538 on the wire. The receive window caps throughput at window ÷ RTT, so the classic 65,535-byte window holds a 50 ms path to about 10.5 Mbit/s however fast the link is. And loss caps it at (MSS ÷ RTT) ÷ √loss. The result above names which ceiling is binding on your numbers.

    What is the bandwidth-delay product, and why does it set the window size?

    The BDP — link rate × round-trip time — is the amount of data in flight at any moment. TCP can have at most one unacknowledged window outstanding, so a window smaller than the BDP leaves the pipe partly empty: at 100 Mbit/s with a 50 ms RTT the pipe holds 625 kB, and a 65,535-byte window fills barely a tenth of it. That is why fast, long paths need TCP window scaling (RFC 7323), which raises the negotiable maximum from 65,535 bytes to about 1 GB.

    How does packet loss limit TCP throughput?

    TCP treats loss as congestion and halves its sending rate on every loss event, so even tiny loss rates matter on fast paths. The Mathis model estimates the ceiling as (MSS ÷ RTT) ÷ √p — at 0.01% loss on a 50 ms path with a 1,460-byte MSS that is about 23 Mbit/s, regardless of link speed. The model assumes evenly spread, independent loss events; below roughly 1% it tracks reality well, and for bursty loss it is optimistic.

    Are the megabytes here the same as in my file manager?

    Not quite. This page uses decimal units, the networking convention: 1 kbit = 1,000 bits and 1 MB = 1,000,000 bytes. Most file managers count in 1024-based units, often mislabeled MB — a “100 MB” file there is usually 100 MiB ≈ 104.86 decimal MB, so it takes about 5% longer to move than the decimal figure suggests. Enter 104.86 MB here to match it exactly.

    Data Rate ConverterConvert between Mbps, MB/s, Gbps, Kbps and other data transfer rate units.Data Storage ConverterConvert between bytes, KB, MB, GB, TB and their binary units (KiB, MiB, GiB) instantly.IPv4 Subnet CalculatorEnter an IP and CIDR or subnet mask to get the network, usable range, broadcast address and host counts.What Is My IPSee the public IP address this connection is using, with the network, region and edge details visible from it.