Network Latency Calculator

Network Latency Calculator

This calculator estimates how long data takes to travel across a network based on physics, not guesswork. Light in a fiber-optic cable moves at roughly 200,000 km/s — about two-thirds of the speed of light in a vacuum, because the glass core has a refractive index near 1.5. That works out to about 5 ms of one-way latency per 1,000 km of cable, a hard floor no amount of bandwidth can beat. The tool turns a distance (or a city pair, a measured ping, or a file size) into the latency and transfer time you should expect.

How latency is calculated

The core formula is simple:

one-way latency (ms) = distance (km) / propagation speed (km/s) x 1000

Round-trip time (RTT) is double that, because a request has to go out and the response has to come back. Real-world latency is always higher than the theoretical minimum — routers, switches, queuing, and serialization add delay — so the calculator applies a configurable multiplier (a value of 2 is a reasonable default for internet paths) to estimate practical latency on top of the propagation floor.

The three modes

• Latency from distance / cities: enter two locations and the tool resolves their coordinates, computes the great-circle distance, and returns one-way, round-trip, and real-world latency.
• Distance from ping: enter a measured RTT and it works backwards to estimate the maximum geographic distance that ping could represent.
• Data-transfer time: combine file size, bandwidth, latency, and protocol overhead to estimate how long a transfer actually takes — transfer time = file size in bits / effective bandwidth, plus the latency component.

Transmission media

Worked examples

New York to London is about 5,585 km. At 5 ms per 1,000 km that is roughly 28 ms one-way and 56 ms RTT theoretically; with a real-world multiplier you should expect 70–90 ms in practice. A geostationary satellite link sits ~36,000 km up, so even at light speed the round trip to orbit and back is around 480–600 ms — which is why satellite gaming and VoIP feel laggy regardless of bandwidth.

Common use cases and pitfalls

• Sizing acceptable latency for VoIP (under ~150 ms one-way), gaming, or database replication between regions.
• Sanity-checking a CDN or edge deployment: if users are 8,000 km from your origin, no caching tier will get you under the propagation floor.
• Remember that bandwidth and latency are independent — a fat pipe does not lower latency, and bufferbloat can raise it under load. The calculator gives the physics-bound minimum; live conditions add the rest.