Where Cross-Border Latency Comes From: Submarine Cables, Detours, and Congestion

"My ping to a US server is only 40ms — is that fake?" Behind that doubt lies a set of physics and engineering facts that are often misunderstood. This article takes cross-border latency apart: what it's made of, which parts are laws of physics, which parts are engineering problems, and how to pinpoint them with tools.

Layer one: the speed of light is the ceiling

Light actually travels through fiber at about two-thirds of its vacuum speed (roughly 200,000 km/s). Between China and the US via Pacific submarine cables, the actual cable route is 11,000–16,000 km (not a straight line on the map), so one-way propagation alone is 55–80ms, and the round trip (RTT) has a theoretical floor of about 110–160ms.

So before judging whether a cross-border latency is "reasonable", do the physics: Singapore→Los Angeles starts around 160ms, Singapore→Frankfurt around 170ms, Shanghai→Singapore around 70ms. A "US IP" measuring below the physical floor is either mislabeled geolocation (GeoIP error) or actually a nearby anycast node — check the ASN with geolocation lookup and it's obvious at a glance.

Layer two: detours — thousands of extra kilometers

The actual path is almost always longer than the cables' shortest route. Common reasons for detours:

• Physical cable routing: submarine cables come ashore at landing stations and continue over terrestrial fiber, so the path runs in zigzags
• Routing policy: carriers pick paths according to commercial interconnection agreements, and the "cheap" path is often not the "near" path. China Telecom's 163 backbone detouring through the US at evening peak is the classic case (AS4134 traffic regularly goes origin→Los Angeles→back to Asia-Pacific)
• Politics and cable cuts: when a route segment fails or is restricted, traffic shifts to backup paths, which can add an entire loop out of nowhere

How to detect a detour: look at the gap between RTT and the physical floor. Shanghai to Singapore has a 70ms floor; if you measure 250ms, the extra 180ms is very likely a detour (commonly via the US, turning the path into Shanghai→US→Singapore).

Layer three: congestion — evening-peak queuing

Beyond the speed of light, the biggest variable is queuing. Routers queue packets before forwarding them; the higher a link's utilization, the longer the queue:

• During the international-gateway evening peak (20:00–23:00), utilization can spike past 90%, and queuing delay climbs from a few ms to hundreds of ms
• Congestion doesn't just raise the floor — it creates jitter: queues grow and shrink, and latency bounces up and down
• Cross-border dedicated lines (IEPL/IPLC) cost a premium precisely for "dedicated bandwidth", which essentially removes queuing from the equation

The same network at 80ms by day and 300ms by night isn't broken — that's the congestion pattern of a shared link. There's no pill for this kind of problem: change the path (dedicated line / quality transit) or shift your hours.

Layer four: device and protocol overhead

Every router hop adds one round of forwarding processing (hardware forwarding at roughly 50–200μs per hop); a cross-border trip of a dozen-plus hops totals about 1–3ms — a small share. The real bulk is always propagation distance (physics) and queuing (congestion). Also mind the protocol stack: a TCP handshake costs 1 RTT and TLS 1.3 adds another — which is why a "300ms-latency website" takes several seconds to open, and why HTTP/3's 0-RTT claws a bit of that feel back.

Segmenting the problem with ping

The ping tool gives you round-trip data from this site (Singapore) to the target. Use it to isolate the problem:

1. Check against the physical floor: measured RTT near the floor → good path, no problem
2. Over the floor by 50% or more → very likely a detour; use MTR / traceroute to inspect each hop — a US detour is recognizable at a glance
3. Compare morning vs. evening: a night-time spike → congestion-type; only changing routes (dedicated line) fixes it
4. Jitter > 30ms → unstable link; rule out local WiFi first, then look at the cross-border segment

The four numbers (latency, jitter, packet loss, and the gap to the physical floor) each point to a different ailment; add a speed test for bandwidth and the quality picture of a cross-border line is complete.

Summary

• Light at two-thirds speed in fiber plus real cable routes set the 110–160ms physical floor between China and the US
• Detours (routing policy / cable cuts) push real measurements far above the floor; the 163 backbone's US detour is the classic case
• Evening-peak congestion is a queuing problem; jitter hurts the experience more than absolute latency
• How to pinpoint: ping against the physical floor → over the floor, inspect routes → compare times of day to separate congestion from detours