LATENCY GUIDE
<1ms = Local LAN | 1–20ms = Excellent | 20–50ms = Good | 50–100ms = Acceptable | 100–200ms = Noticeable | >200ms = Poor. VoIP needs <150ms. Gaming needs <60ms. Real-world latency is always higher than theoretical due to queuing, processing, and routing.
Network Ping & Latency Estimator — Calculate Round Trip Time by Distance
Our free ping and latency estimator calculates the theoretical minimum round-trip time (RTT) between two locations based on the physical distance, transmission medium and number of router hops. Use this tool to understand why latency exists, plan VoIP and video conferencing quality, design distributed systems and set realistic SLA expectations for geographically separated sites.
Why Can't Ping Be Faster Than the Speed of Light?
Network signals travel at approximately 200,000 km/s through fibre optic cable — about two-thirds of the speed of light in a vacuum (299,792 km/s). This physical limit means a signal between London and New York (approximately 5,500 km) takes a minimum of about 27ms one-way — giving a minimum round-trip time of around 55ms, regardless of how much you upgrade your network hardware. Real-world latency is higher due to routing, processing delays and network congestion.
Latency by Physical Medium
- Fibre optic: ~200,000 km/s — lowest latency for long-distance transmission
- Copper Ethernet: ~200,000 km/s — similar to fibre for short distances
- Satellite (GEO): ~35,786 km altitude — minimum 600ms RTT — unsuitable for real-time traffic
- Satellite (LEO — Starlink): ~550 km altitude — 20–60ms RTT — usable for most applications
- 4G/LTE: 30–100ms typical — acceptable for most business applications
- 5G: 1–10ms theoretical — sub-10ms for edge computing applications
Latency Impact on Application Performance
A database-driven web page making 50 queries on a connection with 100ms latency will take a minimum of 5 seconds to render — even if each query runs instantly. This is why database servers must be co-located with application servers on the same LAN (sub-1ms latency). For distributed microservices, high latency between services multiplies across service-to-service calls — a key argument for service mesh architectures and careful service topology design.