Two speed tests on the same connection, twenty minutes apart, returned 2.91 and 41.98 Mbps — a factor of fourteen. Nothing was changed in between. That is not a glitch: a speed test measures something narrower than most people assume when they look at it. Below are our own measurements from a single day — the ones that nearly made us move a server to another provider — and six rules for measuring so the number means something.
Three pairs of numbers from one day
On 28 July 2026 we spent a day measuring throughput on one phone in Moscow: Megafon, 4G+, connected to our VPN server in the Netherlands. We were not writing an article — we were chasing a complaint about a slow connection. The full log of that day is ours; here are three pairs of numbers out of it. All three rows are the same phone and the same tunnel.
| What is compared | First number | Second number |
|---|---|---|
| Two tools, 20 minutes apart | Speedtest — 2.91 Mbps | Yandex Internetometer — 41.98 Mbps (14:46): 14× more |
| Same phone, 20 minutes apart | 2.60 Mbps down, 23.4 up | 96.9 Mbps down, 35.5 up: 37× more |
| Two back-to-back runs | about 20 Mbps | 106 Mbps: 5× more |
In none of the three did we touch anything between the runs: same phone, same room, same server, same settings. It was not the networks that disagreed — it was the measurements. Here is what makes them disagree.
What a speed test actually measures
It does not measure “your internet speed”. It measures how much data moved between your device and one particular server during a few seconds of one particular minute. Everything beyond that is your own generalisation, and that is where the error creeps in.
First consequence: numbers from two different tools are not comparable. Each service runs its own measurement servers in its own locations and measures the road to them. Yandex Internetometer measures to servers inside Russia; Speedtest picks one of its own. These are not two opinions about one quantity — they are two different measurements that happen to share a unit.
How much that matters shows in our control run. On 28 July at 14:47, same tool, same phone, tunnel off: 139.51 Mbps at 20 ms latency. One minute earlier, through the tunnel: 41.98 Mbps at 81 ms. The tempting conclusion — “the VPN costs you two thirds of your speed” — is wrong. Yandex measures to Russian servers, and the traffic was travelling Moscow → Netherlands → Moscow. A longer road gives a smaller number. The instrument did not lie; the question did.
Why back-to-back runs disagree
The second reason is the state of the link in that specific minute — and it has a measurable fingerprint. Next to the big Mbps figure, any decent test shows two small ones: ping and jitter. Ping is how many milliseconds a reply takes. Jitter is how much that wait bounces from packet to packet. A steady link gives single-digit jitter; a nervous one gives hundreds.
Here are the same measurements of 28 July with that second figure alongside.
| Run | Download | Idle jitter |
|---|---|---|
| Far room, weak signal | 5.30 Mbps | 1058 |
| The “slow” run | 2.60 Mbps | 173 |
| Same setup, 20 minutes later | 96.9 Mbps | 29 |
| Cleanest run of the day | 109 Mbps | 6 |
The pattern reads at a glance: where idle jitter is in the hundreds, the Mbps figure is not worth reading. The rule we adopted that day and have kept since: idle jitter above one hundred means the run is void — measure again. Not “slow connection”, but invalid measurement: the tool honestly measured a minute in which the radio link was ragged.
And yes — the 2.91 Mbps run has an idle jitter of 139 recorded next to it.
The tool may have measured a different path
The third reason stings the most: the run was flawless, but it went over a connection other than the one you had in mind.
A modern phone has two address families — the familiar IPv4 and the newer IPv6 — and traffic can take either. In July we walked into this ourselves: our test configuration routed only IPv4 into the tunnel, while the phone had a live global IPv6 address, so everything reachable over IPv6 went around the tunnel. Which means the flattering 117 and 127 Mbps from that same day may have been the carrier's own speed rather than our server's — and we marked them as unverified.
Catching this is easy: a decent tool shows the address you arrived from. Yandex Internetometer shows both families. In our 14:46 run it showed our IPv4 (region “Rotterdam”) and “not detected” for IPv6 — so there was one path, it was the intended one, and the number describes it. Had a carrier address shown up there, the number would have been about a different connection entirely. How to check that in a minute is a separate article.
Megabits are not what you feel
One more disagreement happens not between tools but between the number and your experience: throughput looks great, yet the video call falls apart. The test simply prints the wrong figure in large type.
From one of our runs that day: 117 Mbps down, ping at idle 76 ms, and 650–670 ms under load. While the link is saturated by a download, every small packet queues behind it for the better part of a second. The phenomenon has a name — bufferbloat — and it does not care how many megabits you have.
For calls, games and a browser that simply feels responsive, that second figure is the one that matters. Speed tests print it in small type at the bottom, or not at all.
How to measure honestly: six rules
- One tool. “The other site showed more yesterday” proves nothing: different roads to different servers.
- Three runs in a row, take the middle one. Not the best, not the first. Two of our consecutive runs differed by 5× — a single number on a mobile network means nothing.
- Read ping and jitter before megabits. Jitter in the hundreds: throw the run away and repeat it when the signal settles.
- Check whose address the tool reports. Otherwise you may be measuring a connection you were not thinking about.
- Take a control run right next to it. Same place, same tool, adjacent minutes — once with the VPN on, once off. Only such a pair proves anything.
- Measure more than speed. If calls and games matter, look at latency under load rather than peak throughput.
What believing a single run cost us
In fairness, here is how the story ended on our side. Seeing 2.60 Mbps through our own server, we built a plausible theory: something is wrong with that server's link, we need to move it to another provider. That is days of work and real money.
The measurement that told the theories apart took ten minutes: same phone, same room, repeated once the radio link had settled — 96.9 Mbps. The server was innocent; we had caught a bad minute of a mobile cell and mistaken it for a property of the service. It also turned out that the very same server was pulling 468 Mbps at that moment and was not busy at all.
If your measurements disagree by a factor of several, you have most likely already measured the truth: mobile throughput really does change from minute to minute. One number says nothing about it. Three numbers in a row, with ping and jitter beside them, do.