Why Packet Loss, Not Just Latency, Is the Metric That Actually Predicts a Bad China Route

Latency dominates every conversation about China routing, largely because it’s the number that’s easy to quote. It’s also the number least likely to explain why a route is actually performing badly.

Packet loss is the better predictor, and it’s frequently the metric that’s missing when someone says a route “tested fine” and then disappointed in production. The reason is mechanical rather than a matter of opinion: loss and latency interact on long paths in a way that makes a small loss percentage far more expensive than it looks.

This piece covers what loss actually does to throughput, why China routes generate it in specific places, what thresholds are worth acting on, and how to measure it in a way that catches intermittent patterns.

What packet loss actually is

Packet loss is the proportion of packets that never arrive, or that arrive so late they’re treated as lost. It’s a different measurement from latency, which is how long successful packets take, and from jitter, which is how much that duration varies.

The three metrics can move independently, and a route can look healthy on one while failing on another. That independence is exactly why checking only the most quotable one produces surprises.

Loss also has a dominant cause worth keeping in mind: routers under load drop packets when their queues fill. That makes most loss a capacity signal rather than random degradation, which is part of why it predicts trouble better than latency creeping upward does.

Why latency alone doesn’t tell the full story

The first reason is selection. Latency figures from ping and traceroute describe the packets that completed a round trip. Packets that vanished contribute nothing to the average, so a route dropping eight percent of traffic can report a very similar average latency to one dropping none, because you’re measuring the survivors either way.

The second reason is the one that actually matters for throughput. TCP recovers from loss by retransmitting, and a retransmission costs a full additional round trip. On a domestic path with 15 milliseconds of latency, recovering a lost packet is nearly free. On a path to China at 150 milliseconds, every recovery costs 150 milliseconds or more, so the same loss percentage produces roughly ten times the practical penalty.

TCP’s congestion control compounds it further. Loss is interpreted as a congestion signal, so the sending rate backs off and then rebuilds gradually. A route with steady low-level loss keeps triggering that backoff, which means throughput settles well below what the available bandwidth would suggest. This is why a 1 Gbps port can deliver disappointing transfer speeds to China on a lossy path: the bottleneck is the loss, not the port.

Why China routes are specifically prone to this

The most common source is congestion at domestic peering and handoff points. These are shared, heavily used links, and during peak hours their queues fill, which produces exactly the kind of loss that’s worst for long-haul TCP.

The last-mile segment inside China contributes as well, particularly on mobile networks where conditions vary by cell load and signal quality. This portion sits outside the reach of any foreign host, which is why a genuinely excellent international leg can still terminate in a lossy final hop.

The border inspection layer adds a third possibility. Traffic crossing into China passes through filtering infrastructure, and under load that processing can drop rather than merely delay, especially for traffic patterns that draw extra scrutiny.

Worth noting: loss on a China route is often intermittent rather than constant, appearing in bursts aligned with congestion peaks. That burstiness is precisely what a short test misses.

How to actually check for packet loss

MTR is the right tool, because it runs continuously and reports loss per hop rather than only end to end. That per-hop view is what localizes the problem: if loss appears at hop twelve and persists through the remaining hops, something at hop twelve is dropping packets, and you now know whether it’s on your side of the border or theirs.

One caveat that trips people up constantly: isolated loss at a single intermediate hop, with zero loss at hops after it, is usually not real. Many routers deprioritize responding to the probe packets MTR uses while forwarding actual traffic normally, so they report loss that traffic never experiences. Loss that matters shows up at a hop and continues through every hop after it.

Run for several minutes rather than a few seconds, and repeat at different times of day. Given how bursty loss is on these paths, a thirty-second sample can easily land between bursts and report a clean result you can’t reproduce. V.PS publishes a looking glass at every location for ping and traceroute from the server side, which is a good starting point as long as you treat one reading as a single sample rather than a characterization.

What counts as bad packet loss

Below about half a percent, loss is largely unremarkable and most applications won’t show it. Between one and two percent, real-time traffic starts degrading noticeably and bulk transfer throughput drops more than the number intuitively suggests, for the retransmission reasons above.

Above roughly three percent on a sustained basis, you’re looking at a route with a genuine problem rather than normal internet behavior, and it’s worth investigating or changing rather than accepting. Real-time media is the least tolerant, since UDP-based voice and video don’t retransmit at all and a lost packet becomes an audible gap.

Pattern matters as much as magnitude. Brief loss spikes during known peak hours are normal for China routes and mostly a capacity-planning matter. Steady loss present even during quiet overnight windows suggests something structural in the path, and that’s the case where changing carrier route or location is likely to actually help.

What actually reduces packet loss on a China route

The main lever is reducing exposure to congested shared links. A named, carrier-optimized route keeps traffic on a premium backbone for more of the path, which means fewer of the oversubscribed handoff points where queue-drop loss occurs. Matching that route to the carrier your users are actually on, China Telecom, China Unicom, or China Mobile, matters for the same reason, since a premium path on the wrong carrier leaves those users on a generic one.

Testing before committing is the other half, and it’s the part that’s easy to skip. Run a real sustained MTR against a provider’s looking glass rather than relying on a one-line ping figure from a sales page, and do it at the hours your users will actually be online.

On the application side, a few things reduce how much loss hurts even when you can’t remove it. Enabling modern TCP congestion control designed for lossy long-haul paths helps throughput hold up better under intermittent loss, connection reuse avoids repeatedly paying handshake costs on a path where a lost handshake packet is expensive, and reducing the total number of round trips a page or API interaction requires shrinks the number of opportunities for loss to bite.

Wrapping up

Latency tells you how fast a route feels when it’s working. Packet loss tells you how often it isn’t working, and on a long path that distinction drives far more of the real experience than the average latency does.

If a China route feels unreliable despite acceptable-looking latency, run a sustained MTR, read the per-hop loss column, and check whether the loss persists through subsequent hops. That single measurement usually explains what the latency average was hiding.

Thanks for reading! Whether you’re testing a new location or re-checking one you’ve run for years, sustained loss tells you more about a route than a single latency figure ever will. If you’re looking for fast, no-nonsense infrastructure, V.PS runs KVM VPS on its own networks in 11 cities across 4 continents, with a public looking glass so you can test before you buy. For China-facing workloads specifically, the Performance KVM VPS in Singapore and Tokyo Gen 2 carries CTGNet, CUP, and CMIN2 routing to all three major mainland carriers.

Ready to get started? Deploy a server or contact our team if you need help choosing a plan.

Frequently asked questions about packet loss on China routes

What’s a normal amount of packet loss on any internet route?

Under about half a percent is common and rarely noticeable. Between one and two percent starts affecting real-time traffic and bulk throughput, and sustained loss above roughly three percent indicates a route problem rather than ordinary internet behavior.

Can packet loss happen even with good average latency?

Yes, and it’s the case that catches people out. Latency statistics only describe packets that completed the trip, so lost packets are invisible in the average, and a lossy route can report the same latency as a clean one.

Why does packet loss hurt more on a high-latency route?

Because every retransmission costs a full round trip. Recovering a lost packet on a 15 millisecond domestic path is negligible; on a 150 millisecond path to China it costs ten times as much, and TCP’s congestion backoff reduces throughput on top of that.

How do I check for packet loss on my own route to China?

Run a sustained MTR for several minutes and read the per-hop loss figures, repeating at different times of day. Ignore loss that appears at one hop and disappears at later hops, since that usually reflects a router deprioritizing probe replies rather than actually dropping traffic.

Does a China-optimized route eliminate packet loss entirely?

No, but it reduces the number of congested shared handoff points traffic has to cross, which is where most avoidable loss occurs. The final domestic hops inside China remain outside any foreign provider’s control.

Is packet loss more important to check than latency?

They answer different questions, so neither replaces the other. Loss is usually the better early warning for a route that will disappoint in production, while latency is the better predictor of how responsive a working route will feel.