Starlight Tools
WAN, RTT & Fiber Latency Budget Calculator
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.
Simple WAN and fiber RTT calculator
Estimate the theoretical round trip through fiber, including route stretch, local access, and equipment delay.
Inputs
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.
Results
Advertisement
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.
Formula and assumptions
Effective path distance: distance km * (1 + path stretch % / 100)
Propagation delay: effective distance / (299,792.458 km/s * velocity factor)
Serialization delay: packet bytes * 8 / (link Mbps * 1,000,000) * serialization points
Base one-way delay: propagation + serialization + hop processing + queueing allowance
One-way p95 estimate: (base one-way + jitter p95) * (1 + safety margin % / 100)
RTT p95 estimate: one-way p95 * 2 for a symmetric path assumption.
Application transaction estimate: RTT p95 * application round trips + app processing budget
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.
Reference notes
- One-way delay terminology follows RFC 7679: A One-Way Delay Metric for IPPM.
- 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.