MTR stands for My Traceroute. It started life as Matt’s traceroute, after its original author, Matt Kimball. It’s a command-line tool that combines ping and traceroute: it finds every router between you and a destination, then keeps probing each one, so you get packet loss and latency per hop over dozens or hundreds of samples instead of a single snapshot.
That’s why support teams ask for it. A one-off traceroute tells you the path. An MTR tells you where the path is hurting, and whether that hurt is real.
(If you searched “MTR meaning” hoping for Hong Kong’s rail system or a mill test report, wrong MTR. This one’s for people with a slow server.)
What MTR does under the hood
MTR sends probes with increasing TTL (time to live) values. Each router where a probe expires sends back an ICMP “time exceeded” message, which reveals that hop. The mtr project README describes it as combining “the functionality of the ‘traceroute’ and ‘ping’ programs in a single network diagnostic tool.”
Plain traceroute does this once, three probes per hop. MTR does it over and over. After 100 cycles you have real statistics, which is the whole point.
An example MTR report
Here’s an illustrative report. It isn’t a real measurement: the addresses are from the documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) reserved for exactly this kind of example.
$ mtr -rwc 100 192.0.2.130
Start: 2026-09-29T14:02:11-0500
HOST: laptop.example.net Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 100 0.6 0.7 0.4 2.1 0.2
2.|-- 203.0.113.1 0.0% 100 8.9 9.4 7.8 21.3 1.9
3.|-- 203.0.113.45 0.0% 100 9.8 10.2 8.9 18.6 1.4
4.|-- 198.51.100.17 38.0% 100 11.2 12.0 10.7 44.9 4.6
5.|-- 198.51.100.82 0.0% 100 68.4 24.1 20.8 71.2 11.3
6.|-- 192.0.2.9 0.0% 100 21.5 21.9 20.9 26.4 0.9
7.|-- 192.0.2.130 0.0% 100 22.3 22.6 21.8 25.0 0.6
A nervous reader sees 38% loss at hop 4 and opens a ticket. This path is fine. Here’s why.
What each column means
| Column | What it shows | What to look for |
|---|---|---|
| Loss% | Share of probes to this hop that got no reply | Only matters if it continues to the final hop |
| Snt | Probes sent to this hop | Use 100 or more; 10 is noise |
| Last | Round-trip time of the most recent probe, in ms | Ignore on its own; it’s one sample |
| Avg | Mean round-trip time across all probes | The number to compare hop to hop |
| Best | Fastest reply seen | Roughly the path’s floor latency |
| Wrst | Slowest reply seen | Spikes here are common and often harmless |
| StDev | Standard deviation of the replies | High values mean jitter at that hop |
If StDev and jitter are the part you care about (voice, games, trading), our jitter vs latency guide goes deeper on why a steady 40 ms often beats a jumpy 20 ms.
How to read an MTR report correctly
This is where most people go wrong. Routers are built to forward packets, not answer them. Replying to your probe is a low-priority control-plane job, and many networks rate-limit those ICMP replies on purpose.
Loss that doesn’t carry through is usually not loss
Look at hop 4 again. It drops 38% of probes, but hops 5, 6 and 7 show 0%. If hop 4 were really discarding traffic, everything behind it would lose packets too. It isn’t. The router is just declining to answer some of your probes while forwarding your actual traffic at full speed.
Rule of thumb: only the loss at the final hop is loss your application feels. Intermediate loss that vanishes by the next hop is ICMP rate limiting.
Loss that starts and continues is real
Compare it with this one:
4.|-- 198.51.100.17 0.0% 100 11.2 12.0 10.7 14.9 0.6
5.|-- 198.51.100.82 12.0% 100 22.4 23.1 20.8 31.2 1.8
6.|-- 192.0.2.9 11.0% 100 21.5 22.9 20.9 33.4 2.0
7.|-- 192.0.2.130 12.0% 100 22.3 23.6 21.8 34.0 2.1
Loss appears at hop 5 and holds at roughly the same level all the way to the destination. That’s a real problem, and it starts at or just before hop 5 (the link between 4 and 5 is as likely a suspect as the router itself).
Latency spikes: persistent or not?
The same logic applies to latency. Hop 5 in the first example shows a 24.1 ms average and a 71.2 ms worst case, yet hop 6 averages 21.9 ms. Traffic can’t arrive at hop 6 faster than it passed through hop 5, so that bump is the router being slow to reply, not slow to forward.
A jump that holds through to the end is different. If hop 5 goes from 12 ms to 60 ms and every later hop stays near 60 ms, that’s where the delay enters. Sometimes it’s congestion. Often it’s distance: a big step where traffic crosses the country or an ocean is physics, not a fault.
Asymmetric paths will fool you
The path from you to the server and the path from the server back to you are frequently different. MTR only shows the forward path, but every latency number includes the return trip, which may run over routers you never see. So a problem on the return path can show up as loss or delay at a hop that’s innocent.
That’s why a good host asks for MTR in both directions: one from your machine to the server, and one from the server back to your IP. Run each with at least 100 probes while the problem is happening, and paste both into the ticket as text. With both directions, an engineer can usually tell quickly whether the problem sits with your ISP, a transit provider or the host.
MTR commands you’ll actually use
On Linux or macOS (via Homebrew), install mtr and run a report:
mtr -rwzc 100 example.com # report, wide, AS numbers, 100 probes
mtr -rwc 100 -T -P 443 example.com # TCP probes to port 443
mtr -rwc 100 -u example.com # UDP probes
mtr -4 -rwc 100 example.com # force IPv4
mtr -6 -rwc 100 example.com # force IPv6
-r prints a report and exits, -w stops hostnames being truncated, -z adds each hop’s AS number, and -c sets the probe count. -T switches to TCP, handy when a firewall treats ICMP differently from your real traffic; aim it at your service’s port with -P. The full option list is in mtr --help and the project page at BitWizard, which also notes that Roger Wolff took over maintenance in 1998.
On Windows, use WinMTR. Enter the host, let it run for a few minutes, then use Export TEXT so you can paste the result.
If all you have is plain traceroute:
traceroute 8.8.8.8 # Linux / macOS
tracert 8.8.8.8 # Windows
traceroute 8.8.8.8 is a fine sanity check of your outbound path. For anything you’ll send to a support team, use MTR.
What a looking glass is
A looking glass is a web page a network runs so outsiders can run diagnostics from that network’s routers or servers. You type in your IP, pick a location, and it runs ping, traceroute or MTR back toward you. That gives you the reverse-direction test without needing an account on anyone’s server.
Many carrier looking glasses also offer BGP lookups. “Looking glass BGP” means asking a router which route it would use for a prefix: the AS path (the chain of networks the traffic would cross), the next hop, and sometimes BGP communities. It answers questions like “does this provider reach my ISP directly, or through two other carriers first?” Public tools such as the RIPEstat looking glass show BGP routes for a prefix as seen from RIPE’s route collectors.
GigeNET’s looking glass
GigeNET runs one at lg.gigenet.com. It offers four tools: Ping, Traceroute, MTR and IPERF (for IPERF, you run iperf -s on your own machine first). You can run them from three locations, labeled Chicago, IL; Los Angeles, CA; and Washington, D.C. It doesn’t do BGP route lookups, so pair it with a public BGP tool if you want the AS path.
The same page lists a 1 GB test file per location for download speed checks:
- Chicago:
http://speedtest.chi.gigenet.com/1gb.img - Los Angeles:
http://speedtest.lax.gigenet.com/1gb.img - Washington, D.C.:
http://speedtest.iad.gigenet.com/1gb.img
Test a host before you buy
This is the part I’d do before signing any hosting contract, ours included. It takes ten minutes.
- From the host’s looking glass, run MTR from each candidate location to your office IP and to a couple of IPs where your users are. Check final-hop loss and Avg.
- Run MTR from your side back toward each location, so you have both directions.
- Pull the 1 GB test file with
curl -o /dev/nulla few times at your busy hour, not at 3 a.m. - Pick the location closest to your users on the network, not on the map.
If a host publishes no looking glass or test files, ask why. GigeNET’s facilities are listed on the datacenter locations page, so you can match your results to a site before choosing a dedicated server.
FAQ
MTR stands for My Traceroute. It was originally called Matt’s traceroute, after Matt Kimball, who wrote it. The tool is still maintained as open source and ships in most Linux distributions.
Traceroute maps the path once, with three probes per hop. MTR maps the same path but keeps probing every hop, so you get loss percentage, average latency and jitter over many samples. For troubleshooting an intermittent problem, MTR is the better tool.
Usually not, if the loss disappears at the next hop and the final hop shows 0%. That pattern is a router rate-limiting its ICMP replies. Loss that starts at a hop and carries through to the destination is the kind to report.
Use at least 100 (-c 100). Ten probes can make a single dropped reply look like 10% loss. For intermittent problems, run it while the problem is happening, or run several reports across the day.
If your MTR results point to a GigeNET location that fits your users, tell us what you need and we’ll put a quote together.
