The Latency Floor: Why Region Choice Is Arithmetic

The region you deploy in sets a hard floor on how fast your users can reach you, and that floor is arithmetic you can compute in a minute before you ever open a console. Almost nobody does it. Teams pick a region from a map, run a ping from their own laptop, see a number, and either accept it or blame the provider. Without the floor you have no way to tell which of those two things you are looking at, and those two things have completely different fixes.

This article gives you the floor calculation, the one measurement that tells you how much of your latency is physics and how much is a fixable detour, and a table of three failure modes that all look identical from a single ping number.

The floor is arithmetic, not opinion

Light in a vacuum travels at 299,792 kilometres per second. That is 3.34 microseconds per kilometre. Nothing in a network changes this. It is the ceiling on how fast any signal can move, and every routing decision, every peering agreement, and every cable upgrade operates strictly underneath it.

Light in a fibre optic cable is slower than light in a vacuum, because the glass has a refractive index above 1. A typical single-mode telecom fibre has a refractive index near 1.468, which puts the propagation speed at roughly 200,000 kilometres per second. Stated the way network engineers state it: about 5 microseconds per kilometre, one way.

That number is the whole article. Five microseconds per kilometre, one way, means ten microseconds per kilometre for a round trip. A request and its response cross the same distance twice.

A 3,000 kilometre separation therefore costs you a minimum of 30 milliseconds round trip before a single packet has been processed, queued, switched, or retransmitted. That is not a provider performance issue. It is the distance, priced in the only currency the distance accepts.

A floor table for one plausible hub

Take Hong Kong as a worked example, because it is one of the few locations that is genuinely central for Asia-Pacific traffic rather than merely marketed that way. The table below computes the great-circle distance from Hong Kong to each destination and converts it at 5 microseconds per kilometre, one way. The round-trip figure doubles it.

Read the last column as a budget. If you serve users in Singapore and Tokyo from Hong Kong, you have already allocated 26 and 29 milliseconds of your round-trip time to geography. Whatever application-level target you have set has to fit inside what remains.

Why this is a lower bound and not the answer

Two corrections push the real floor upward, and honesty about them is what makes the number useful.

The first is that submarine cables do not follow great circles. They are laid along seabed contours, around geological features, and between landing stations that already exist, so the physical path between two cities is typically 1.3 to 1.5 times the straight-line distance. Multiply the table by 1.4 and a Hong Kong to Singapore round trip has a realistic floor closer to 36 milliseconds than 26.

The second is that the packet has to get from the cable landing station to the actual server, and from the user's device to wherever their traffic enters the backbone. That last segment is not a rounding error. It is frequently the largest single term in the sum, and it is the one your provider does not control.

Applying a 1.4 multiplier to the table gives you a practical floor. Anything you measure above that practical floor is routing, peering, congestion, or endpoint overhead. Anything at or near it is the planet.

The signal to measure: your fill ratio

Here is the single measurement worth adding to your runbook. Divide your measured round-trip time by the practical floor for that pair of cities. Call the result the fill ratio.

The measurement is not ping to the server's public address, which tells you about the path between your location and the machine, not the path your users take. Measure from where your users are, or from a probe network with nodes in those markets, and measure to the service, not the host. A synthetic transaction over HTTPS and TLS will include the handshake cost that a raw ICMP echo hides.

Run it over a full day, not for sixty seconds. Take P50, P95, and P99 separately. The reason is that the three percentiles are answering three different questions, and collapsing them into one number is how teams end up arguing about the wrong thing. P50 tells you what the median user experiences. P95 tells you what your tail-latency budget has to absorb. P99 tells you whether something is intermittently broken. A route with a comfortable P50 and a P99 five times higher is not a fast route; it is a route with a problem you have not found yet.

Interpret the fill ratio like this:

• Below about 1.5: you are close to the physics. There is very little left to win by changing routes. If the latency is still unacceptable for your application, the answer is to move the workload closer to the users, not to tune the network.
• Between about 1.5 and 3: normal for well-peered regional traffic. Some of the gap is fibre path length, some is transit economics. Worth investigating if the ratio drifts upward over weeks.
• Above about 3: the path is doing something the map does not explain. This is the band where a change of region, of carrier, or of transit relationship produces a step change rather than a marginal improvement.

The thresholds are deliberately loose. Their purpose is not to grade a provider; it is to tell you whether you are looking at a physics problem or an engineering problem before you spend money on either.

Why real paths sit above the floor

A high fill ratio has three causes, and they call for three different responses. This is the part that a single ping number cannot distinguish.

Asymmetric routing. The outbound path and the return path are chosen independently, by different networks, using different policies. Your packets may leave through one transit provider and come back through another entirely. When the return path is longer than the outbound path, you pay the difference on every round trip. Symmetric-looking latency in both directions from a single vantage point is not evidence of symmetric routing; it is evidence that your one vantage point cannot see the asymmetry.

Peering and transit economics. Traffic between two networks that do not peer directly has to travel through whatever intermediary is willing to carry it, and that intermediary is chosen because it is cheap to reach, not because it is short. Two cities 1,500 kilometres apart can have traffic that goes 6,000 kilometres because the commercial relationship that would produce the short path does not exist. This is the most common reason a fill ratio lands above 3, and it is also the reason the same provider can look excellent from one market and mediocre from another.

Congestion at a specific hour. Capacity is shared, and demand is not flat. A path that is clean at 03:00 can queue badly at 21:00. If your latency curve tracks your users' waking hours, you are looking at contention rather than distance. The diagnostic is the shape of the curve over 24 hours, which is why a one-minute measurement is worthless for this.

The map is not the network

Everything above assumes the cable is working. That assumption is doing more work than most people realise, so it is worth looking at how the physical layer actually behaves.

There are an estimated 1.5 million kilometres of subsea communications cable in service across 607 cable systems, and satellite capacity could not replace them if they failed. Around 200 cable faults are reported worldwide each year, and the International Cable Protection Committee notes that figure has stayed broadly steady even as the total inventory has grown. The cables themselves are the reliable part. It is the maritime traffic above them that causes most of the trouble: 86 percent of cable faults are attributed to fishing activity or anchoring, with fishing roughly twice as prevalent as anchoring incidents. Geological events account for about 7 percent of faults, cable abrasion for 4 percent, and actual component failure for only 4 percent.

The distribution of those faults matters for region selection. Just under half occur inside territorial waters, most of the remainder inside exclusive economic zones, and only 2 percent on the high seas. Cables are most exposed close to shore, in shallow water, where fishing is concentrated and where every cable serving a coastline has to come ashore at a landing station. The deep ocean is the safest place for a cable. That is the opposite of the intuition most people bring to the problem.

Geography concentrates the risk further. The Singapore Strait carries 35 cable systems, the Luzon Strait 18, and the Bab al-Mandab Strait 16. When several cables were severed in the Bab al-Mandab Strait in September 2025, an estimated 25 percent of cable capacity between Asia, Europe, and the Middle East was disrupted. The Luzon Strait was the site of an earthquake and follow-on submarine landslides in December 2006 that severed every cable running through it, and it took 11 repair vessels 49 days to restore all the systems.

Repair timelines are the part that should change how you plan. A single repair typically costs between USD 500,000 and USD 1 million, and repair response times have more than doubled over the past decade. The longest single repair recorded in 2023 took 947 days, much of it spent waiting for permission to work in another country's waters. Only about 60 ships worldwide can repair a submarine cable, and roughly two-thirds of that fleet reaches the end of its service life by 2040 while total cable kilometres are projected to grow by about 48 percent over the same period.

The practical conclusion is not that undersea cables are fragile. It is that the failure mode you are planning against is a capacity reduction of unknown duration, not a clean binary outage. Internet traffic is elastic, so a cable fault usually produces degraded performance rather than a hard stop. If your region choice assumes instant repair, you have assumed something the industry cannot currently deliver. The realistic mitigation is route diversity: two paths that do not share a landing station, a strait, or a single transit provider.

Routing is more stable than you fear

If the physical layer is less reliable than assumed, the routing layer is more reliable than assumed, and that asymmetry is useful when you are deciding where to spend effort.

Border Gateway Protocol is the internet's routing system, and it has no built-in authentication, which is why route hijacks are a persistent concern. The defence that has been deployed against them is RPKI: a cryptographic record, published by the network that legitimately owns a block of addresses, declaring which autonomous systems are authorised to announce it. Routers performing route origin validation consult those records and can reject announcements that contradict them.

The reasonable worry, once RPKI is widely deployed, is that the flood of authorisation changes could itself destabilise routing. A study published in October 2026 analysed more than 11 years of RPKI and BGP data to test exactly that, and the answer is reassuring. Even using a methodology deliberately biased toward overestimating the effect, the share of all BGP updates attributable to RPKI events remains well below 1 percent of total update volume. The trend is upward, because RPKI deployment is growing, but the absolute contribution is very small. The study's conclusion is that operators should not treat routing stability as an obstacle to deploying RPKI.

What this changes for a region decision: routing instability is not a good explanation for a persistently high fill ratio. If your path is consistently three times the floor, the cause is almost always commercial routing rather than a hijack or a policy storm. That narrows the fix to things you can actually act on, which is a change of region, of provider, or of peering relationship.

When the floor is the binding constraint, and when it is not

The floor only matters when your application is sensitive to round-trip time. It is worth being explicit about which applications those are, because plenty of workloads should ignore this article entirely.

• Sensitive to the floor: interactive terminal and remote desktop sessions, database queries issued in a loop, chat and voice, real-time multiplayer state synchronisation, API gateways fronting a request chain, and any trading or auction system where a few milliseconds change who wins.
• Indifferent to the floor: nightly batch jobs, media transcoding, object storage replication, log shipping, backups, and long-running analytics. These are throughput problems. Moving latency by 40 milliseconds changes nothing about how long a two-hour job takes, but doubling port speed halves it.

That distinction is why choosing a region by "closest to our users" is right for some services and actively wrong for others. A batch pipeline should be placed where compute and storage are cheapest and where the data already is. A terminal session should be placed where the physics is least hostile. Those two regions are frequently different regions.

The second thing worth knowing is that bandwidth and latency are not the same axis, and confusing them leads teams to buy the wrong fix. Port speed determines how much you can move per second. Distance and routing determine how long the first byte takes. Adding bandwidth to a distance problem buys you nothing for interactive latency, and upgrading a route for a throughput problem is equally pointless.

Doing it in the right order

A region decision that survives contact with production usually follows this sequence.

1. List the markets that generate your latency-sensitive traffic, weighted by request volume rather than user count.
2. Compute the round-trip floor from each candidate region to each market, using the great-circle distance at 5 microseconds per kilometre one way, then multiply by 1.4.
3. Measure the fill ratio from synthetic probes in those markets, over a full day, and keep P50, P95, and P99 separate.
4. Reject any candidate whose floor, plus your application's own processing budget, exceeds the target you set. No amount of network engineering recovers from this.
5. Among the survivors, choose on fill ratio and its stability, not on peak throughput claims.
6. Re-measure after 30 days and after any carrier change. Fill ratios drift, and a route that was clean at selection time does not stay clean forever.

Step four is the one teams skip, and it is the only irreversible one. Steps five and six are optimisations; step four is a decision about what is possible.

The reason this matters commercially is that the markets which matter most to Asia-Pacific businesses are also the ones where the physical floor is most favourable from a well-connected hub. Serving Southeast Asia, Greater China, and Northeast Asia from a single location is a real option rather than a compromise, provided the location has genuine route diversity and does not funnel everything through one strait.

Where this lands in practice

Once you have the floor and the fill ratio, the question stops being "which region is fastest" and becomes "which region has the shortest path to my markets, enough independent routes that no single cable fault changes the answer, and a price I can hold for the life of the workload".

That last clause is not a throwaway. A region selection made on promotional pricing that resets at renewal is a region decision with an expiry date, and migrating a production service because the discount ended is more expensive than the discount was worth.

For Asia-Pacific workloads where the floor points at a location near the centre of the region, a Hong Kong node is the case worth evaluating, which is what the SurferCloud Hong Kong node cloud server is built for. The service covers 17 or more global availability zones across four continents from Tier 3 data centres, and the Hong Kong tier carries the features a latency-sensitive deployment actually needs: a stated 99.95 percent availability commitment, VPC network segmentation so you can isolate the tiers of the application, and a documented operational model where the platform can be upgraded online without restarting the cloud host. It supports both Linux and Windows images, provisions in minutes, and is positioned against the usual Asia-Pacific gateway workloads: cross-border e-commerce that needs fast domestic and international access, Web3 and blockchain node deployment, AIGC inference endpoints, and software development environments where the round trip between developer and machine is felt directly.

Two commercial details are relevant to the floor discussion specifically. The current offer is up to 25 percent off with no price increase at renewal, which addresses the held-price problem rather than the latency problem, and the lightweight tier starts at $6.75 per month for 1 vCPU, 2 GB memory, 40 GB disk, and 1 TB of outbound traffic on a 30 Mbps port. Payment is accepted by bank card, PayPal, or cryptocurrency, and first-time users can request a test machine through an account manager, which is the cheapest way to obtain the fill-ratio measurement from your own markets before committing.

What the promo page does not publish is per-plan pricing for the enterprise tier, and the page states plainly that full pricing and region availability are visible in the console after signing up. Take that at face value and confirm the specific configuration you need is available in Hong Kong before you build a plan around it.

Frequently asked questions

How much of my latency is the distance, really?

For a well-peered route between two regional markets, the physics is often the smaller half. A Hong Kong to Tokyo round trip has a practical floor near 40 milliseconds once you apply the 1.4 fibre-path multiplier; measured figures for a healthy route commonly land in the 50 to 70 millisecond band. The remaining 10 to 30 milliseconds is routing and endpoint overhead, which is where every realistic improvement lives.

Is ping a good enough measurement?

No, for two reasons. Ping measures a path to a host, which is not the path your users take to your service, and it measures the round trip at the network layer, which excludes the transport and TLS handshakes that often dominate first-request latency. Use ping and traceroute for diagnosis, and a synthetic HTTPS transaction for the number you make decisions with.

Should I add bandwidth to fix latency?

Only if the queue is the problem. Adding port speed reduces the time a packet waits behind other packets. It does nothing about the time the signal spends in glass, which is set by distance. If your fill ratio is above 3 and stable across the day, more bandwidth will not move it.

Why do two providers with nodes in the same city perform differently?

Because the city is not the variable. What differs is the carrier mix, the peering relationships at the local internet exchange, and how many independent cable systems terminate at that site. Two data centres a few kilometres apart in the same city can have materially different fill ratios to the same destination market, and the difference is contractual as much as it is technical.

How often should the measurement be repeated?

At selection time, then monthly, and always after a carrier or transit change. Your routes change without your knowledge, because they are controlled by networks you do not operate. A fill ratio that was 1.8 at launch and is 2.9 six months later is telling you something, and the only way to hear it is to keep measuring.

Does any of this apply if my users are all in one city?

Much less. If every user is in the same metropolitan area as the server, the floor is negligible and the fill ratio is dominated by the last mile, which you do not control and cannot improve by changing region. In that case, spend the effort on the application instead.

Related reading

The measurement methodology in this article is the same one used for low-latency infrastructure for algorithmic trading, where the tolerance for routing detours is smallest and the cost of a high fill ratio is measured in executed orders rather than annoyed users.

For the other axis of the same decision, port speed rather than transfer volume is what actually limits a server, and it explains why adding bandwidth never fixes a distance problem.

If the workload you are placing is an interactive session rather than a service endpoint, the regional trade-offs in a cloud desktop comparison are the same conversation with different constraints.

And for a fully worked example of building a per-endpoint route test matrix before migrating a latency-sensitive service, measuring exchange API round-trip time before moving a trading bot walks through the same steps against a harder target.

The short version

Latency has a floor. It is about 5 microseconds per kilometre one way through fibre, multiplied by however much longer the cable route is than the straight line. Compute it before you choose a region, because that decision is the only one in this process you cannot reverse by configuration.

Then measure the gap between your real latency and that floor. A small gap means you are near the physics and should move the workload nearer the users. A large and stable gap means there is a routing fix available, and it is worth finding. A large and unstable gap means something is broken, and it is worth measuring before it becomes an incident.

What you should stop doing is treating a single ping number as a verdict. It is one observation, from one place, at one moment, with no reference point attached. The floor is the reference point, and it takes about a minute to work out.