WAN Latency Calculator
Estimate WAN round-trip latency from route distance and path overhead to compare target headroom, dominant delays and serial application wait.{{ summaryTitle }}
{{ summaryLine }}
{{ summaryCopyAnnouncement }}
Latency plan
{{ guidanceTitle }}
{{ guidanceText }}
Application turn cost
{{ transactionGuidance }}
Calculation trace:
- {{ row.label }}:
{{ row.value }}{{ row.note }}
{{ formulaCopyAnnouncement }}
The chart renderer is unavailable. The same delay values remain in the planning ledger.
| Signal | Value | Planning meaning | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.display }} | {{ row.detail }} |
A wide area network can have ample bandwidth and still feel slow. Bandwidth describes how much data a path can carry, while latency describes how long a packet and its reply take to cross that path. Interactive applications notice the wait because each dependent request may have to finish before the next one begins.
Distance sets a floor that equipment cannot tune away. Light travels more slowly through glass than through a vacuum, and a carrier route is normally longer than a straight line on a map. Access loops, conduit routes, cable landings, peering locations, and a different return path can all extend the distance actually travelled.
- Round-trip time (RTT)
- The elapsed time for a packet to reach the far endpoint and for a reply to return.
- Propagation delay
- The physical time of flight through the route medium.
- Serialization delay
- The time required to place all packet bits onto the slowest modeled access link.
- Delay variation
- The amount by which observed delay changes, often because queues and paths are not constant.
Routers, firewalls, encryption devices, queues, and slow access circuits add operational delay above the distance floor. These additions do not behave alike. Fixed processing can often be estimated, serialization follows packet size and link rate, and queueing may change sharply with load. A planning reserve can cover uncertainty, but it does not turn a modeled path into a measured service guarantee.
Application design determines how strongly RTT affects the user. Six serial request-response turns across a 100 ms path impose at least about 600 ms of network waiting before server work is counted. Parallel requests, fewer round trips, caching, and placing services closer together may reduce that wait even when the carrier route is unchanged.
How to Use This Tool:
Start with a defensible path length, then add only the overhead and uncertainty that apply to the planned route.
- Choose a Route preset for an editable example or keep Custom path for your own assumptions.
- Enter the one-way Route distance in km or mi and select the Fiber model. Prefer carrier route length over map distance when it is available.
- Set Transit hops, Delay per hop, and Fixed device delay for known forwarding and processing overhead.
- Enter the Target RTT and the number of Serial application turns. The latter estimates only accumulated network waiting, not server or client processing.
- Open Advanced when access loops, route contingency, return asymmetry, queue reserve, delay variation, or bottleneck serialization materially change the plan.
- Compare Budgeted RTT with the target gap, then inspect the delay mix to see which assumptions dominate. A negative target gap means the estimate exceeds the target.
Interpreting Results:
Budgeted RTT is the base estimate plus the selected delay-variation reserve. Propagation share shows how much of base RTT comes from distance. A high share points toward geography and routing; a lower share makes hop, device, queue, or serialization assumptions more influential.
- A positive Target gap is remaining headroom. A negative value is the amount that must be removed to reach the target.
- Transaction floor multiplies budgeted RTT by serial application turns. It excludes computation, database work, rendering, retransmissions, and unrelated protocol setup.
- A favorable estimate does not prove the live path will meet an SLA. Measure representative traffic in both directions and during relevant load periods.
Technical Details:
The model separates physical travel from operational overhead. Signal speed is derived from the fixed speed of light in vacuum and the selected effective refractive index. Forward and return distance are then adjusted independently before their propagation time is added to hops, devices, queueing, and optional serialization.
Formula Core:
Signal speed in fiber is the vacuum speed divided by refractive index.
The adjusted route distance accounts for contingency, two access loops, and return-path asymmetry.
Propagation RTT is time of flight over both legs. Optional serialization counts one packet on each leg.
Base RTT adds the operational terms. The reserve is applied only after that sum, and serial application turns multiply the budgeted result.
| Symbol | Meaning | Unit |
|---|---|---|
| c | 299,792.458 km/s, the speed of light in vacuum | km/s |
| n | Selected refractive index: 1.467, 1.468, 1.474, or a custom value from 1 to 2 | ratio |
| D, r, A, a | One-way core distance, route contingency, access loop per site, and return asymmetry | km, %, km, % |
| B, R | Packet size and bottleneck access rate; serialization is zero when rate is zero | bytes, Mbps |
| H, h, E, Q | Hop count, delay per hop, fixed device delay, and queue reserve | count, ms/hop, ms, ms |
| j, N | Delay-variation reserve and serial application turns | %, count |
Calculations retain full numeric precision; displayed milliseconds are rounded for readability. The model does not infer congestion, packet loss, retransmission, route changes, protocol handshakes, or server time.
Accuracy Notes:
Presets and per-hop delay are planning assumptions. Replace them with carrier route data and measurements when possible. Ping results also depend on packet type, endpoint behavior, route direction, sampling time, and network load, so compare like with like and use a series of observations rather than one sample.
Worked Examples:
Regional path with four serial turns
An 800 km symmetric route on the 1.468 fiber model, with eight hops at 0.05 ms each and 1.5 ms of fixed device delay, produces about 9.735 ms of budgeted RTT when all reserves and serialization are zero. Four serial application turns therefore add about 38.939 ms of network waiting. The 20 ms RTT target retains about 10.265 ms of headroom, but that margin still needs measurement under representative load.
References:
- Meter and the fixed speed of light, National Institute of Standards and Technology, updated May 28, 2026.
- RFC 2681: A Round-trip Delay Metric for IPPM, RFC Editor, September 1999.
- Practical Latency in a Fiber Optic Network, Cisco.