Calculate network latency from distance, fiber speed, equipment delay, jitter, and an application SLA. Use the
quick WAN RTT calculator for a fast propagation estimate or the advanced budget for packet and TCP planning.
All calculations run locally in your browser. Use the result for planning, then validate production links with real path measurements and application telemetry.
Quick estimate
Simple WAN and fiber RTT calculator
Estimate the theoretical round trip through fiber, including route stretch, local access, and equipment delay.
Estimated RTT-
Inputs
Use the actual cable, radio, or routed path length when known.
Adds slack for conduit routes, metro rings, carrier paths, and non-geodesic routing.
Used for packet serialization and bandwidth-delay product.
Count links where a packet is transmitted at the entered bottleneck rate.
Include QoS, shaping, firewall, encryption, and congestion allowance here.
Applied to the latency subtotal before comparing with the SLA.
Use 1 for a simple request-response, higher for chatty protocols.
Cloud and city-pair presets are planning archetypes, not current provider measurements. Override them with carrier routes, cloud telemetry, or measured region-to-region RTT whenever available.
Optional browser HTTPS latency test
Times five small HTTPS requests. This includes DNS/TLS reuse, browser, endpoint, and server overhead, so it is an application-path observation—not ICMP ping or a provider-region guarantee.
Not tested
Results
SLA status-
One-way p95-
Estimated RTT-
SLA margin-
Distance floor-
Dominant cause-
Latency components
Effective path distance:-
Signal speed in medium:-
One-way propagation delay:-
Packet serialization delay:-
Hop processing delay:-
Queueing and policy allowance:-
Latency before jitter and margin:-
Safety margin added:-
Application and jitter budget
Jitter / delay variation p95:-
Jitter tolerance remaining:-
Application network turns:-
Application transaction estimate:-
Bandwidth-delay product:-
BDP in bits / bytes:-
Minimum TCP receive window:-
Receive-window throughput limit:-
Loss-adjusted TCP estimate:-
Estimated transfer time:-
Measured RTT variance:-
Planning insight
Dominant delay component:-
Theoretical one-way floor:-
How to use this latency budget calculator
Model the path: enter the link or route distance, then add path stretch for real carrier routing, slack loops, and non-direct paths.
Choose the medium: fiber is often modeled near 0.67c, while microwave and satellite paths are closer to free-space speed but may travel farther.
Account for packet transmission: enter packet size, bottleneck rate, and serialization points where that rate applies.
Add operational delay: include forwarding, encryption, firewall, shaping, queueing, and measured jitter allowances.
Compare to the right SLA: choose one-way, RTT, or a multi-turn application transaction depending on what the application promise measures.
The model assumes a symmetric forward and return path for RTT. Use separate budgets for each direction when paths, QoS, access circuits, or cloud regions differ.
Application latency guidance
Planning ranges are starting points, not universal standards. Measure the complete application and follow contractual or product-specific requirements.
Application
Preferred target
Degraded range
Planning focus
VoIP / interactive video
<150 ms one way
150–400 ms
One-way delay, loss, jitter, and buffer depth
Gaming / remote desktop
<50 ms RTT
50–150 ms RTT
RTT, jitter, frame pacing, and loss
Trading / control systems
<10 ms one way
10–50 ms
Tail latency and deterministic paths
Web applications
<100 ms RTT
100–300 ms RTT
Reduce DNS/TLS and request-response turns
Database calls
<5 ms RTT
5–20 ms RTT
Transaction chattiness and consistency protocol
File transfer
<100 ms RTT
100–250 ms RTT
BDP, receive window, loss, and parallelism
Replication
<50 ms RTT
50–150 ms RTT
Synchronous write latency, RPO, and change rate
Backup
<200 ms RTT
200 ms+ may still work
Throughput, window sizing, loss, and completion window
Worked network latency examples
Case
Exact inputs
Formula
Output
Metro fiber
50 km, 25% stretch, 0.67c
62.5 / 200,861 × 1,000 × 2
0.622 ms propagation RTT; equipment and queueing increase it
Cross-country WAN
4,500 km, 25% stretch, 0.67c
5,625 / 200,861 × 1,000 × 2
56.01 ms propagation RTT floor
Intercontinental fiber
12,000 km, 15% stretch, 0.67c
13,800 / 200,861 × 1,000 × 2
137.41 ms propagation RTT floor
GEO satellite
72,000 km path, 0.99c
72,000 / 296,795 × 1,000 × 2
485.18 ms propagation RTT before gateways
Chatty application
80 ms RTT, 5 network turns, 30 ms processing
80 × 5 + 30
430 ms transaction estimate
Latency, jitter, RTT, and application turns
Network latency is not a single source of delay. Propagation delay comes from distance and signal speed.
Serialization delay comes from packet size and link rate. Processing and queueing delay come from equipment,
policy, congestion, encryption, and buffering. The calculator keeps those pieces separate so the limiting
component is visible.
Packet delay variation is often called jitter. It matters most for real-time media, control loops, market data,
remote desktops, and any protocol that uses tight timing assumptions. A jitter buffer can mask variation, but it
also increases end-to-end delay.
RTT matters because many applications are conversational. Authentication, TLS setup, database queries, file
metadata lookups, and legacy client-server protocols may need several network turns. When a transaction needs
five turns, every additional 20 ms of RTT can add about 100 ms before server processing is considered.
Packet delay variation follows RFC 3393, where variation is derived from differences between one-way delays.
ITU-T Y.1541 provides IP performance objectives and packet delay variation guidance.
The propagation model uses the NIST/CODATA speed of light in vacuum, 299,792,458 m/s, multiplied by the selected medium velocity factor. The 0.67c fiber value is a planning approximation based on light traveling near c/1.5 in glass.
Fiber velocity factors, forwarding delays, queueing delays, and jitter are planning assumptions. Use measured values or provider commitments when available.
Methodology
The calculator first converts the entered distance and path stretch into an effective one-way route length. It
divides that length by media signal speed for the propagation floor, then adds packet serialization time,
hop-level processing, queueing/policy allowance, measured or planned jitter, and a safety margin. The selected
SLA metric is compared against one-way p95, symmetric RTT p95, or a multi-turn application transaction estimate.
Last reviewed: June 2026. Calculations are deterministic planning estimates and run locally in your browser.
FAQs
How many ms per km is fiber latency?
At 0.67c, fiber propagation is about 0.00498 ms (4.98 µs) per km one way, or 0.00996 ms per km RTT. Real cable routes are longer than map distance and add equipment delay.
How do I estimate WAN RTT from distance?
Convert the route to kilometers, divide by roughly 200,861 km/s for one-way fiber delay, double it for RTT, then add local access, equipment, queueing, jitter, and a planning margin.
What is good network latency for voice, video, gaming, web apps, and backups?
Voice and interactive video commonly plan below 150 ms one way; gaming and remote desktop feel best below roughly 50 ms RTT; web apps benefit from below 100 ms RTT. Backups tolerate more latency when TCP windows and throughput are sized correctly. Use the guidance table above as a starting point.
Why is ping different from application latency?
Ping usually measures an ICMP RTT. An application can also include DNS, TCP and TLS setup, server processing, browser work, retransmissions, and multiple network turns.
How do packet loss and jitter affect latency?
Jitter makes arrival time unpredictable and may require a delay-adding buffer. Loss causes retransmission or recovery; even low loss can sharply restrict TCP throughput on a long-RTT path.
Should I use one-way latency or RTT for an SLA?
Use the metric named in the contract. One-way delay suits directional delivery and media; RTT is easier to measure and suits request-response systems. Do not derive one from the other unless path symmetry is a stated assumption.
Disclaimer
This tool is an infrastructure planning aid, not a carrier SLA certification or application performance guarantee.
Validate production designs with provider contracts, device telemetry, packet captures, active probes, and
application-level measurements.
Starlight Tools