Lag and packet loss: how to read an MTR without being fooled

The game stutters, SSH is sluggish, the website sometimes does not answer. When the problem looks like the network, the right tool is MTR: it combines traceroute and ping and shows, for every hop between you and the server, the latency and the share of lost packets. It is powerful, and very easy to misread.

Run it the right way

From Linux or macOS:

bash

mtr -rwzc 100 <server IP>

-c 100 sends 100 packets: with only a few, the numbers mean nothing;
-w shows full host names, -z the network number (AS) of each hop.

On Windows, use WinMTR, or tracert followed by pathping.

Two rules to read it

1. Only loss that continues to the end counts. Many routers give low priority to packets addressed to themselves and answer reluctantly. That hop shows loss, but if the following hops and the destination are at 0%, your data passes just fine: it is not a problem.

 5. ae1.router-a.example   30%   ← this hop only
 6. core.router-b.example   0%
 7. your-server             0%   ← clean destination: all good

Loss is real when it starts at one hop and continues to the destination.

2. Look at jumps in latency, not absolute values. A clear increase in latency between two hops that stays afterwards shows where the path gets longer or congested. A single hop with a high ping followed by normal hops is, again, a router that answers slowly.

Do it in both directions

The internet is not symmetric: the path from your PC to the server can differ from the way back. For the full picture:

run the MTR from your computer to the server;
run the MTR from the server to your IP;
if you can, repeat it while the problem is happening: a test taken when everything works shows nothing.

The looking glass on our website also lets you run ping, traceroute and MTR from our network to your IP, without logging in to the server.

Before you blame the network

A server at 100% CPU answers slowly even on a perfect network: check top.
Home Wi-Fi and mobile networks drop packets more often than you think: try a cable.
During a DDoS attack, traffic is filtered and latency can rise: the reports in the panel show it.

What to attach to a ticket

If the loss is real, open a ticket and attach text, not screenshots: the MTR in both directions, your public IP, the exact time with the time zone, and how long it has been happening. With this we can tell straight away whether the problem is on our network, on your provider's, or in between.

Tags#network#latency#mtr#traceroute

ShareX LinkedIn