High latency and packet loss: reading MTR
Use MTR output to find where a path gets slow or breaks.

What are latency and packet loss?
Round-trip time (RTT) is how long a small packet takes to reach the target and for the answer to come back. Ping measures it several times and gives the minimum, average and maximum. The minimum is closest to the real network distance; a big gap between it and the average or maximum means queues and congestion on the way. Packet loss is the share of packets that got no answer at all.
High latency makes games, video calls and pages opening feel slow, and even a few percent of loss cuts download speed and makes voices break up in calls.
Reading MTR output
MTR shows the path hop by hop like traceroute, but it probes each hop many times and gives each one its own loss and latency. Three rules explain most results:
- Loss at a middle hop that does not continue to later hops is usually not real. Routers forward passing traffic quickly but limit or deprioritise answering probes aimed at themselves, so that hop stays quiet while packets go through it fine.
- A real problem starts at one hop and continues to the end of the path, all the way to the target. The last hop is the number that counts.
- A latency jump at a hop that stays to the end means the path got longer or busier from there. A jump at one hop that drops again at the next is, again, usually just that router being slow to answer.
A big jump when the path crosses an ocean or continent is normal: light in optical fibre travels at about 200,000 km per second, so every 1,000 km of cable adds roughly 10 ms to the round trip. High latency to a target on another continent is not necessarily a fault.
Find the problem step by step
- On CheckNet’s “Ping and route” page, first ping the target from several countries. If it is slow everywhere, the problem is near the target; if only from one region, it is on the path from there.
- Then run MTR mode from the places where the result was bad.
- Start at the last hop. If the target shows no loss and a sensible latency, ignore loss at middle hops.
- If the target shows loss, walk backwards and find the first hop from which loss appears at every later hop. That hop’s name or address usually tells you which network it is.
- Repeat the test at different times of day. A problem that only shows in the evening is usually congestion, not a fault.
- Remember that some servers do not answer ping, so a failure does not always mean the target is down. Check with the “Does it open everywhere?” page too.
What to send your provider or host
- The full MTR output as text, not just a screenshot, from where the problem shows.
- The target’s IP or name, and the country and network of the probe that ran the test.
- The exact date and time, with the time zone, and whether the problem is constant or only at certain hours.
- A test from another place that works fine, for comparison. This helps more than any description.

