What is MTR? The diagnostic tool that outperforms both ping and traceroute

MTR is a tool that provides a live, continuously updating view of the route between your device and a remote server, revealing not only where your packets travel, but how the performance of each hop changes over time.

Understanding how data travels across the Internet is essential for diagnosing performance issues, especially when problems seem intermittent, inconsistent or impossible to trace. While most people are familiar with tools such as ping and traceroute, there's another tool that combines the strengths of both and offers a far clearer picture of what is happening along a network path: MTR.

MTR ("My TraceRoute" but originally "Matt’s TraceRoute") provides a live, continuously updating view of the route between your device and a remote server. It reveals not only where your packets travel, but how the performance of each hop changes over time. For businesses that rely on stable connectivity, MTR is one of the most useful diagnostic utilities available.

Why MTR matters

Imagine driving the M25, one of the UK’s busiest motorways. If you only travelled it once on a quiet evening, you might conclude it is smooth and free of delays. But anyone who commutes regularly knows it is prone to congestion, bottlenecks and diversions.

Computer networks behave in much the same way. A single test might make everything appear normal, yet the real picture becomes clear only when you examine conditions over time. This is where MTR excels.

Ping and Traceroute: useful but limited

Before understanding MTR, it helps to revisit the limitations of the traditional tools:

Ping

Ping measures the round-trip time between you and a destination. It’s useful for spotting high latency or packet loss, but it doesn’t tell you where along the route the problem occurs.

Traceroute

Traceroute shows the path packets take from one point to another, hop by hop. However, it provides only a single snapshot. If the network behaves differently a few seconds later, which is common, the snapshot may not reflect the real issue.

MTR combines both functions, giving you the full route and updating it continuously so you can watch patterns evolve.

What MTR does differently

MTR sends a steady stream of test packets through each hop of a route and updates the results in real time. This gives you a moving picture of:

  • Latency at every hop
  • Packet loss over time
  • Route stability
  • Points where performance consistently degrades

With these insights, it becomes much easier to determine whether a problem lies on your local connection, within your provider’s network, or somewhere else entirely.

How to run MTR

MTR is available on most platforms, although the method varies slightly:

  • Linux: Open a terminal and type: mtr <hostname>
  • macOS: macOS includes MTR, but it must be run with elevated privileges: sudo mtr <hostname> Enter your password when prompted.
  • Windows: Windows does not include MTR by default. Instead, download WinMTR from winmtr.net and run it as a standalone application.

For best results, allow MTR to run long enough to build a stable picture. Resetting it periodically can help prevent early spikes from skewing the averages.

Understanding MTR results

An MTR report contains several columns, but the key ones are:

  • Hops: The routers your traffic passes through
  • Loss %: Packet loss at each hop
  • Sent/Received: The number of test packets used
  • Avg (Mean Latency): Average response time
  • Best (Lowest Latency): Fastest recorded response

Normal router behaviour that can look like a problem

Some routers, especially those belonging to large carriers, intentionally deprioritise or ignore ICMP requests (the type of packets MTR uses). This can produce:

  • "Waiting for reply"
  • Apparent packet loss at one hop
  • Higher latency on a particular hop

This behaviour is normal as long as later hops are unaffected. If the route continues normally after the unusual hop, the router is simply refusing to answer every request while still forwarding traffic correctly.

When packet loss indicates a real issue

If packet loss appears at a particular hop and continues for every hop that follows, the problem is likely real. This may point to:

  • A faulty or congested link
  • A router experiencing hardware or software issues
  • A path that is overloaded or unstable

Diagnosing latency spikes

Latency spikes work the same way:

  • Spike at a single hop only, and normal afterwards: The router is deprioritising ICMP; not a fault.
  • Spike that carries through the trace: There may be congestion or a fault at that specific hop.

Why the return path also matters

Just as road journeys do not always use the same route in both directions, Internet traffic frequently takes a different path on its way back. If you have access to the destination server, running a return-path MTR provides a fuller and more accurate diagnosis. This is known as a bidirectional test, and it often reveals issues that a single test would miss.

A clearer window into network health

MTR is an indispensable tool for diagnosing connectivity problems because it provides a continuous, detailed, and realistic view of how traffic behaves across a network. For businesses that rely on reliable Internet performance, MTR offers the clarity needed to distinguish between temporary fluctuations and underlying faults.

For more information, visit our home page or contact us with your questions.