What is MTR (My Traceroute)?

What MTR is.

MTR combines the functions of two classic network utilities — ping and traceroute — into a single tool. Rather than testing just the endpoint (ping) or listing the route once (traceroute), MTR continuously measures the path to a host, showing every hop between your machine and the destination together with live, per-hop packet loss and latency. Because it keeps sampling, the numbers settle into a statistically meaningful picture instead of a single snapshot that might have caught a fluke. It's a staple of network troubleshooting and is available as open-source command-line tools (the original mtr, plus WinMTR on Windows).

How it works.

Like traceroute, MTR discovers the path by sending probe packets with an increasing Time To Live (TTL). The first probe is sent with a TTL of 1, so the first router on the path decrements it to zero and returns an ICMP "time exceeded" message — revealing hop 1. The next probe uses TTL 2 to reveal hop 2, and so on, until the packets reach the destination. Where MTR differs is what happens next: instead of stopping after one pass, it repeatedly re-probes every hop and aggregates the results over time. Each round adds to running per-hop statistics — how many probes replied, how long they took, how much they varied — which is why an MTR display updates continuously and grows more trustworthy the longer you let it run.

How to read MTR output.

A typical MTR run looks like the sample below. Each row is one hop along the route, in order from your machine (top) to the destination (bottom):

                                        Packets              Pings
 Host                              Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                        0.0%    50    0.4   0.6   0.3   1.9   0.2
 2. 100.64.0.1                      0.0%    50    8.9   9.3   8.1  14.0   1.0
 3. core1.isp.example.net          40.0%   50   11.2  11.9  10.9  22.1   2.3
 4. ae-2.transit.example.net        0.0%    50   24.1  24.8  23.7  30.2   1.1
 5. edge.dest.example.net           0.0%    50   31.0  31.5  30.8  35.1   0.8

The most important thing to understand — and the mistake most people make — is how to read loss. In the sample above, hop 3 shows 40% loss, yet hops 4 and 5 show 0%. That is almost always not a real problem. Packet loss that appears at a single middle hop but does not persist to later hops usually means that router is de-prioritizing or rate-limiting the ICMP/UDP probes MTR uses to measure it — it forwards your actual traffic just fine while quietly ignoring the diagnostic packets aimed at it. Real trouble looks different: it shows loss that begins at a hop and continues all the way through to the destination. So judge a route by the loss on the final hop, not by a lone red spike in the middle.

Why it matters.

A speed test or a ping tells you that a connection is bad; MTR tells you where it's going wrong. By walking the path hop by hop, it lets you localize a problem to a specific segment: your local network (the first hop or two), your ISP's access and core network, a mid-path transit provider you don't control, or the destination itself. That distinction changes what you do next — reboot the router, open a ticket with your ISP, or accept that the far-end server is the bottleneck. It turns "the internet is slow" into an evidence-backed, actionable diagnosis.

MTR in NetGlobe.

NetGlobe includes a live MTR tool called MTR Live. When you click any connection on NetGlobe's live map, its Endpoint Focus panel opens with everything known about that endpoint — and from there you can launch MTR Live with one click and watch per-hop loss and latency update in real time against that exact host. It sits alongside the rest of NetGlobe's diagnostics — traceroute, path MTU discovery, iperf3 and a speed test — so you can go from noticing a suspicious or slow connection to pinpointing the hop responsible without ever leaving the app. NetGlobe is a visibility and diagnostics tool: it shows and measures, it doesn't block.