Network Latency Calculator
Calculate expected network latency based on distance, transmission medium, and protocol overhead. Understand RTT, ping, and propagation delay.
Latency is the one network metric that money can't simply fix. You can buy more bandwidth, add more servers, use faster disks — but the speed of light is a hard ceiling, and for geographically distributed systems, the physics of signal propagation sets a floor on how fast your app can ever be.
Components of Network Latency
Total latency (round-trip time, or RTT) is the sum of several contributors:
| Component | Typical Range | Description |
|---|---|---|
| Propagation delay | 1–300ms | Speed of signal through medium |
| Transmission delay | <1ms (LAN) to ~10ms (slow WAN) | Time to serialize bits onto the wire |
| Processing delay | 0.1–5ms | Router/switch forwarding decisions |
| Queuing delay | 0–50ms+ | Time waiting in router buffers |
| Protocol overhead | 50–300ms | TCP handshakes, TLS setup, DNS lookup |
Using the CalcHub Latency Calculator
On CalcHub, you can:
- Distance-based estimate — enter source and destination cities or coordinates, choose medium (fiber, copper, satellite), and get theoretical minimum and realistic expected RTT
- Protocol analysis — model the latency cost of adding DNS lookup, TCP handshake, TLS 1.3 handshake, and HTTP/2 connection setup
- Hop analysis — enter a traceroute output and the calculator breaks down latency per hop
Expected Latencies by Route
| Route | Fiber RTT (min) | Realistic RTT |
|---|---|---|
| Same city | <1ms | 1–5ms |
| New York → Los Angeles | 30ms | 40–60ms |
| London → New York | 56ms | 65–85ms |
| New York → Tokyo | 100ms | 120–160ms |
| London → Sydney | 170ms | 180–260ms |
| Any → Geostationary satellite | 600ms | 600–700ms |
| Any → LEO satellite (Starlink) | 30–60ms | 40–80ms |
Protocol Overhead: The Hidden Latency
A fresh HTTPS request to a server involves:
- DNS resolution: 20–100ms (first time; cached ~0ms)
- TCP handshake: 1 RTT = 60ms (New York → London)
- TLS 1.3 handshake: 1 RTT = 60ms
- HTTP request/response: 1 RTT = 60ms
- Total for first request: ~240ms
HTTP/2 multiplexing eliminates per-request handshakes after the connection is established. HTTP/3 with QUIC eliminates the TCP handshake entirely (0-RTT resumption). The calculator models the difference, which helps quantify the value of protocol upgrades.
Latency Targets by Application
| Application | Acceptable RTT | Why |
|---|---|---|
| Competitive online gaming | < 30ms | Frame-accurate input |
| VoIP / video calls | < 150ms | MOS score degrades above this |
| Interactive web apps | < 100ms (to server) | Feels instant to user |
| Database queries | < 10ms | Apps make many queries per page load |
| Bulk file transfer | Doesn't matter much | Throughput is the bottleneck |
Tips
- TCP throughput is latency-dependent. With a 100ms RTT, TCP's slow-start phase can cap your throughput well below the link capacity. The Throughput Calculator shows how RTT limits actual transfer speeds.
- CDN placement matters more than server power. Reducing the physical distance between your users and content servers directly reduces propagation delay. A 2× faster server 5,000 km away loses to a 1× server 500 km away for interactive applications.
- Queuing delay is the one you can control. Active queue management (AQM) in routers like CAKE or FQ-CoDel dramatically reduces bufferbloat, which is often the difference between "feels fast" and "technically fast."
What is bufferbloat and why does it cause latency?
Bufferbloat happens when routers have oversized buffers that fill up under load, delaying packets. A link can simultaneously show 0% packet loss and 500ms added latency under heavy load. Run the Bufferbloat test at waveform.com to check if this affects your connection.
Why does my traceroute show latency decreasing at later hops?
Latency should generally increase hop by hop. If it decreases, it usually means routers are deprioritizing ICMP responses (which traceroute uses) or MPLS tunnels are obscuring intermediate hops. The last RTT to the destination is the most reliable figure.
How does 5G affect mobile latency?
5G sub-6GHz achieves 10–30ms latency in real conditions, compared to 40–80ms for 4G LTE. 5G mmWave can achieve <5ms in ideal conditions but has very limited range and penetration. For most mobile users, 5G latency gains are modest compared to the bandwidth improvements.
Related Calculators
- Throughput Calculator — latency affects TCP throughput
- Bandwidth Calculator — complement latency with capacity planning
- Network Uptime Calculator — reliability alongside performance