The Five Numbers on a Speed Test
A complete test reports bandwidth, latency, jitter, packet loss and — for China connectivity — separate figures for each of the three carriers. Most people read only the first, which is often the number least connected to what users experience.
Bandwidth measures how many cars the road can hold. Latency and packet loss measure whether the cars actually move. An eight-lane road that jams constantly can mean a longer commute than a clear four-lane one, and cross-border links are almost always the former.
| Metric | What it measures | When it's a problem |
|---|---|---|
| Bandwidth (down/up) | Theoretical maximum capacity | Rarely the bottleneck cross-border |
| Latency (RTT) | Round-trip time for a packet | Above 150ms, interaction degrades noticeably |
| Jitter | Variation in latency | Above 30ms, real-time apps destabilise |
| Packet loss | Share of packets lost in transit | Above 1%, TCP throughput collapses |
| Per-carrier figures | Path quality via Telecom/Unicom/Mobile | One carrier alone doesn't show the picture |
The table lists all five with reference thresholds. Those in the third column come from established standards for real-time communications and serve as a starting point.
Why Packet Loss Matters Far More Than Bandwidth
This isn't a rule of thumb — it's a mathematical property of TCP. Three reasons:
- Loss triggers congestion control TCP reads a lost packet as "the network is congested" and reduces its sending rate. That's sensible on a local network, but on cross-border links loss often comes from line quality rather than congestion — so TCP misreads it and throttles itself, and the bandwidth you paid for goes unused.
- Throughput is inversely proportional to the square root of loss This is the relationship the Mathis equation describes: throughput is roughly segment size divided by round-trip time, multiplied by one over the square root of the loss rate. In practice, loss worsening from 0.1% to 1% cuts throughput to about a third — entirely independent of your bandwidth.
- Latency amplifies the damage from loss In the same formula, throughput is also inversely proportional to RTT. So on cross-border links high latency and loss compound: 1% loss on a local network may be a mild slowdown, but the same 1% over a 200ms path drives real throughput down to unusable levels.
What This Looks Like in Practice
The classic symptom is "the speed test looks fine but users keep complaining". Most tools display peak bandwidth by default, and a peak is measured in the most favourable instant — it cannot reveal time-of-day packet loss.
Page loading is another common case. A page pulls dozens of resources, each needing connection setup and transfer. With high latency those round trips accumulate, and retransmissions from loss add more, so what users perceive is "the page is stuck" rather than "the download is slow". This is precisely why a bandwidth figure alone misleads.
Worth adding: these thresholds are general starting points, not hard standards. Real-time voice and video are especially sensitive to jitter (noticeable beyond 30ms), while bulk transfer cares more about the combination of loss and latency. Read them against what your service actually does.
Why China Connectivity Needs Three Separate Tests
China Telecom, Unicom and Mobile each run their own backbone and international gateways, and interconnection between them is uneven. The same overseas node might sit 80ms away for a Telecom user and 200ms with packet loss for a Mobile user — **that isn't measurement error, the traffic genuinely takes different paths**.
So one carrier's result can't stand in for the whole. If your users span all three but you test through one, two thirds of your user experience is unmeasured. That's why cross-border testing tools present the carriers separately: not for presentation, but because a single figure is meaningless here.
Three Levels of Interpretation
Given a set of results, work through them in this order:
1. Check packet loss first
This is the priority metric. Below 0.1% is normal; above 1% materially damages TCP throughput; above 3% users are probably already complaining. Loss usually originates along the path rather than at either end, so adding bandwidth or better hardware on your side won't improve it.
2. Then latency and jitter
Latency is set by physical distance and routing, so improvement means taking a different path — serving from a nearby CDN node rather than sending users all the way to origin. Jitter reflects path stability; high jitter usually means congestion or unstable routing in between.
3. Bandwidth last
Only once the first two are within reasonable ranges does bandwidth become the real constraint, and only then is buying more of it worthwhile. Reversed — adding bandwidth while loss is unresolved — the spend never shows up in what users feel.
Three Things to Get Right Before Testing
Results are only interpretable if the test itself is sound:
- Test from where users actually are Testing from your own facility or office measures your line, not theirs. That's doubly true cross-border: the test has to originate in the target market.
- Know which node you're measuring With a CDN in front, you may be measuring the nearest edge node rather than the origin. The two produce very different numbers, so establish which layer you're testing before reading anything into it.
- Don't test only once Cross-border problems are overwhelmingly time-of-day. A single test proves things were fine for one second and says nothing about any other hour. That deserves its own treatment, which we cover separately in a piece on continuous monitoring.
In Summary
The download figure printed largest on a speed test is usually the least informative one cross-border. What users feel is decided by loss and latency, and the two multiply — a mathematical property of TCP, not a tuning problem.
If you need to see outbound quality separately across China's three carriers, our free online speed test shows latency and loss for Telecom, Unicom and Mobile individually.