How to run an MTR

MTR runs a traceroute and a ping at the same time, continuously, and keeps a running loss and latency figure for every hop on the path. That makes it the right tool for a problem that comes and goes, which a single traceroute is almost designed to miss.

Why MTR beats a single traceroute

A traceroute sends three packets per hop and then stops. If your problem affects two packets in a hundred, or shows up for thirty seconds every ten minutes, three packets will usually miss it entirely, and you will send support a clean traceroute for a connection that is genuinely broken.

MTR keeps sending, so every hop gets a denominator. Instead of "hop 7 timed out" you get "hop 7 lost 4 of 300", which is a measurement you can act on.

Linux

sudo apt install mtr

sudo dnf install mtr

Debian and Ubuntu first, Alma, Rocky, and RHEL second. On Debian, mtr-tiny is the same tool without the graphical interface and is fine for a server.

Run a fixed-length report:

sudo mtr -rwzbc 300 203.0.113.10

Without -r you get the live view, which updates in place and quits with q. That is good for watching, and the report is what you paste into a ticket.

To probe the port your service actually uses rather than ICMP:

sudo mtr -T -P 25565 -rwzbc 300 203.0.113.10

-T is TCP mode and -P names the port. -u sends UDP instead. Start with the default ICMP run, since it is the one that reaches every hop, and use TCP mode when you need to confirm the service port is treated the same way.

Some builds carry the capability to run unprivileged. If yours does, drop the sudo.

macOS

MTR is not included. Install it with Homebrew:

brew install mtr

Homebrew installs it into sbin, which is not on the PATH that sudo uses, and MTR needs root on macOS. Give the full path:

sudo /opt/homebrew/sbin/mtr -rwzbc 300 203.0.113.10

On an Intel Mac the path is /usr/local/sbin/mtr. Every flag above works the same way from there.

Windows

There is no official MTR build for Windows. Two practical options:

WinMTR is the port everyone uses. It is a small portable program with no installer: put the address in the host box, press Start, leave it running for several minutes, then stop it and copy the result as text using the buttons on the window. It probes with ICMP only, so it has no TCP or UDP mode and no AS lookup.

pathping is built into Windows and needs no download:

pathping 203.0.113.10

It runs a traceroute first, then pings each hop in turn and prints a per-hop loss table. Because it works through the hops one at a time it takes minutes on a long path, and it can be shortened:

pathping -q 50 -p 250 203.0.113.10

-q is queries per hop and -p is the wait between them in milliseconds. Read its loss column with exactly the caution described below, and more of it: pathping depends entirely on routers replying to it, so intermediate hops showing 100% loss in a pathping are extremely common and almost never real.

If you have WSL installed, sudo apt install mtr inside it gives you the real tool, including TCP mode. Expect the first hop to be the WSL virtual gateway rather than your router.

How long to run it

Long enough for the sample to contain the problem.

• 300 cycles, about five minutes at the default one second interval, is the shortest run worth sending to anybody.
• Under 100 cycles the loss column cannot mean anything. On 10 packets one drop reads as 10%. On 300 it reads as 0.3%. The number changes, the network does not.
• Run it while the problem is happening. An MTR taken after the fact describes a working connection.
• Take a second one when everything is fine, on the same route, and keep it. A baseline turns "29 ms" into "29 ms, up from 12 ms", which is the difference between a report and a guess.
• For something that appears every few minutes, 600 to 1,000 cycles.

Reading the report

                                   Packets               Pings
 Host                            Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.1.1                   0.0%   300    0.4   0.5   0.3   2.1   0.1
 2. 192.0.2.1                     0.0%   300    9.1   9.3   8.8  14.2   0.4
 3. 192.0.2.34                   18.7%   300   11.0  11.2  10.6  19.8   0.6
 4. 198.51.100.7                  0.0%   300   27.9  28.1  27.4  33.0   0.5
 5. 198.51.100.62                 0.0%   300   28.4  28.6  27.9  35.7   0.6
 6. 203.0.113.10                  0.0%   300   29.0  29.2  28.6  40.1   0.8

That report shows a healthy connection with one distraction in it.

Loss at a middle hop that does not reach the last line is not your problem

Hop 3 lost 18.7% of its probes. Every hop after it, including the destination, lost nothing. Those are the same packets: to reach hop 4 they had to pass through hop 3. Packets cannot be lost at hop 3 and simultaneously arrive at hops 4, 5, and 6.

What that router is dropping is the ICMP replies it owes MTR, because generating them is a low-priority job it is configured to ration. It is a setting on somebody else's router and it costs you nothing.

This is the single most misread result in hosting support. It produces a steady stream of tickets reporting 19% packet loss on a path that is losing none, and the time spent disproving them is time not spent on the real fault. Before you quote a loss figure, look at the bottom line.

Real loss propagates

If hop 3 showed 18.7% and hops 4, 5, and 6 also showed roughly 18%, that is real loss, and the trace is telling you where it begins: everything behind hop 3 inherits it. The pattern to look for is loss that starts at one hop and persists to the destination.

The number that decides whether you have a problem is always the last line. The hops above it only tell you where the problem starts, and only once the last line has confirmed there is one.

Latency reads exactly the same way

A middle hop with a high Avg that the hops below do not carry forward is control-plane delay on that router, not delay on your path. A rise that every subsequent hop carries is real, and it started there.

Wrst and StDev are the jitter columns

A hop with Avg 29 and Wrst 400 is stalling periodically. Players feel that far more than they feel a high but steady figure, because prediction in a game client copes with consistent delay and cannot cope with a sudden one. A path with a high Avg and a low StDev is a long path, not a broken one.

The report covers one direction

MTR measures the path from where you run it. Routing is not symmetric, so congestion on the way back appears in your report only as a slightly worse final number, with no hop to blame.

Take two reports for every investigation:

1. From the player's machine to the server's IP address.
2. From the server back to the player's public IP address, in the same window.

Install MTR on the server the same way as any other Linux box. Without the second report, half of the path has never been measured.

When the MTR is clean and players still complain

If the bottom line shows no loss and a flat, low Avg while people are lagging, the path between those two machines is fine and the fault is at one end of it:

• The server itself. Check the load before anything else, starting with the live gauges on Server overview and the method in Diagnosing high latency.
• The player's own network, which an MTR from their machine does cover but a Wi-Fi problem hides well. See Diagnosing packet loss.
• Filtering in front of the service. Protection sits ahead of the server, so measure against the game port with -T -P as well as with ICMP, and use Address lookup on the Attacks tab to check whether a specific player's address was filtered. That is covered in When players cannot connect.

Related