Network latency calculator
Light in fibre travels at about two thirds of its speed in vacuum, so a signal covers roughly 200 km per millisecond. London to New York is about 5,570 km, giving a round-trip floor near 56 ms before any equipment is involved.
How to use the network latency calculator
A floor, not a prediction
Real latency adds switching, routing, queuing and the fact that fibre does not run in straight lines; actual London to New York round trips run 70 to 80 ms against the 56 ms physics allows. What the floor is good for is knowing when optimisation is pointless. If your API is 90 ms away and physics says 56, there is 34 ms of engineering to attack. If it says 56 and you are getting 58, the only remaining move is to put the data closer to the user, and a CDN is exactly that move. It also explains why interactive applications feel different across an ocean no matter how good the servers are.
Four things add to the floor, and only one is physics
Propagation is the part this page computes: distance divided by signal speed, and nothing shortens it except a shorter path. Serialisation is the time to clock the bits onto the wire, which is the packet size over the link rate, so a 1,500-byte frame takes 12 microseconds at 1 Gbit/s and 1.2 milliseconds at 10 Mbit/s. Processing is what each router spends looking at a header, now measured in microseconds. Queuing is everything else, and on a congested or badly buffered link it dwarfs the other three; a saturated home uplink can add hundreds of milliseconds on its own, which is the effect bufferbloat describes. When a measured ping is wildly above the floor and varies from second to second, queuing is the first suspect rather than distance.
The cable is longer than the great circle
The distance to enter is the straight-line great circle, because that is the shortest path light could take. Real routes are longer: submarine cables follow seabed corridors and land at existing stations, terrestrial fibre follows railways, motorways and pipelines, and traffic often crosses an exchange point some way off the direct line. Assuming a real path around a third to a half longer than the great circle is a reasonable first correction, and comparing that against a measured round trip usually explains most of the gap without needing a traceroute.
Round trips, not milliseconds, are what an application spends
Latency hurts applications through the number of round trips they need before anything useful happens. A TCP connection costs one round trip to open before a byte of request is sent. TLS 1.2 adds two more, TLS 1.3 adds one, and QUIC folds the transport and cryptographic handshakes together so a fresh connection costs one and a resumed one can cost none. Slow start then limits the first response to roughly ten segments, so a large payload needs several further round trips to ramp up regardless of bandwidth. On a 56 ms link a page needing six sequential round trips has spent a third of a second before rendering begins, and no amount of extra bandwidth changes it. The other half of the same arithmetic is the bandwidth-delay product: bandwidth multiplied by round-trip time gives the data that must be in flight to keep a link full, which is 12.5 MB on a 1 Gbit/s path at 100 ms and is why an untuned single stream cannot saturate a long fat pipe.
What people use it for
- Deciding whether an API is slow or only far away
- Making the case for a server region closer to the users
- Setting a realistic latency target for a cross-continent call
- Estimating what a CDN edge can actually save before paying for one
- Explaining why a remote desktop feels laggy across an ocean
- Sanity-checking a provider's quoted inter-region latency against what physics permits
- Working out how many round trips a protocol handshake is costing you
- Sizing a TCP window from the bandwidth-delay product of a long link
Questions
About 200 km per millisecond: roughly two thirds of the speed of light in vacuum, because glass has a refractive index near 1.5 and a signal slows in proportion.
Four things sit on top of propagation delay: serialising the packet onto the link, per-hop processing, queuing, and a cable route longer than the straight line. Queuing is usually the biggest and the only one that varies minute to minute.
Not over that distance in that medium. Financial trading routes beat fibre on some legs by switching to microwave, which crosses air at nearly full light speed and can be aimed in a straighter line than a cable can be laid.
Because the limit is the medium's refractive index rather than the material being metal or glass. A signal on coaxial cable travels at roughly two thirds of light speed as well, so the choice between them is about bandwidth and distance, not delay.
The great circle, because the tool is answering what is physically possible. If you want a realistic expectation rather than a floor, add a third to a half to the distance before entering it.
Only when both directions take the same path. Internet routing is often asymmetric, so a path can be materially longer one way, and a round-trip measurement cannot tell you which half is which.
Under 30 ms feels instant, 30 to 80 is fine for most things, and above 150 is noticeable in anything interactive. Competitive games are the strictest case and want the low end of that.
It cuts the distance. Physics fixes the floor for a given path, so the only way under it is to serve the response from somewhere nearer.
Barely. Extra bandwidth shortens serialisation, which is microseconds on a fast link, and does nothing to propagation or queuing. Once a link is not congested, upgrading it leaves the ping where it was.
Because pages spend round trips rather than milliseconds. Connection setup, the cryptographic handshake and TCP slow start each cost at least one, and six sequential round trips on a 56 ms link is a third of a second before anything renders.
One for the TCP handshake, plus two for TLS 1.2 or one for TLS 1.3. QUIC combines them into one, and a resumed QUIC connection can send data in the first packet.
Bandwidth multiplied by round-trip time: the amount of data that has to be in flight to keep a link busy. A 1 Gbit/s path at 100 ms needs 12.5 MB in flight, so a single stream with a small window leaves most of the link idle.
A geostationary satellite orbits 35,786 km up, so a signal climbs and descends about 71,600 km each way. That is roughly 240 ms one way and 480 ms for a round trip, before any equipment. Low-orbit constellations fly a few hundred kilometres up instead, which brings the floor back down to a few milliseconds.
No. Jitter is how much the latency varies between packets, and it comes from queuing rather than distance. A call can be unusable at a low average ping if the variation is high, because the receiver has to buffer for the worst case.
Routers generate those replies as a low-priority side job and rate-limit them. A slow-looking hop in the middle with a fast final line is normal and means nothing.
Much less than the distance. Modern forwarding costs microseconds a hop, so a route with twenty hops on a short path beats a route with eight across an ocean.
A page can hide latency by fetching in parallel and showing something early. A conversation cannot: every exchange is a full round trip that a person is waiting through, and the point where people start talking over each other sits around 150 ms one way.