What mtr Does That traceroute Cannot
traceroute sends three probes per hop and exits. If packet loss is intermittent — occurring only 1–2% of the time — three probes will almost certainly miss it. mtr keeps running, sending continuous probes to every hop on the path simultaneously, accumulating hundreds of samples. It displays live statistics for each hop: loss percentage, average latency, best and worst RTT seen, and standard deviation. This statistical picture reveals instability and loss patterns that a single traceroute snapshot would never capture.
When users report a connection that "drops out occasionally" or "feels slow sometimes," mtr run for several minutes during the problem period will almost always show the responsible hop with elevated loss or sharply increasing worst-case RTT.
Installation
On Debian and Ubuntu Linux:
sudo apt install mtrOn Red Hat, Fedora, and CentOS:
sudo dnf install mtrOn macOS via Homebrew:
brew install mtrNote that on macOS, Homebrew installs mtr as a binary that requires root to send raw packets. You may need to run it with sudo mtr google.com or adjust permissions. On Windows, the closest equivalent is WinMTR, a graphical tool available from the WinMTR project. mtr also runs inside WSL on Windows.
Basic Usage
Launch the interactive full-screen display:
mtr google.comRun for a fixed number of cycles and print a report (non-interactive, suitable for pasting into a support ticket):
mtr --report --report-cycles 100 google.comRun 200 cycles for a longer, more statistically robust sample:
mtr --report --report-cycles 200 google.comPress q to quit the interactive display, or d to cycle through display modes.
Understanding the Output Columns
| Column | Meaning | What to watch for |
|---|---|---|
| Loss% | Percentage of probes with no reply | Any loss at final destination is significant; mid-path loss may be ICMP rate limiting |
| Snt | Total probes sent to this hop | Higher = more statistically reliable loss % |
| Last | RTT of the most recent probe (ms) | Useful for watching real-time spikes |
| Avg | Average RTT across all probes (ms) | The primary latency indicator per hop |
| Best | Lowest RTT seen (ms) | Represents best-case propagation delay for this hop |
| Wrst | Highest RTT seen (ms) | Large gap between Best and Wrst indicates jitter or congestion events |
| StDev | Standard deviation of RTT (ms) | High StDev = inconsistent latency, often a sign of buffer bloat or intermittent congestion |
Interpreting Per-Hop Packet Loss
The most common misreading of mtr output is treating mid-path packet loss as a problem when it is not. Many routers intentionally rate-limit ICMP replies to protect their CPU — they forward traffic normally but only send one ICMP Time Exceeded reply per second or less. This appears as 30–70% loss at a single hop while all subsequent hops show 0% loss.
The rule: if loss appears at hop N but the final destination shows 0% loss, the loss at hop N is almost certainly ICMP rate limiting, not a real problem for your traffic. If loss appears at hop N and persists at the same level or higher through all remaining hops including the destination, that points to genuine packet loss on the link at or after hop N.
mtr vs traceroute vs ping
Each tool serves a different diagnostic need. ping gives you aggregate RTT and loss to a single target. traceroute gives a one-shot hop-by-hop snapshot. mtr gives you continuous, statistically robust per-hop measurements. Use ping to confirm reachability, traceroute to locate a problem, and mtr to characterise an intermittent or persistent issue.
Using TCP and UDP Modes
Like traceroute, mtr supports TCP and UDP probe modes to bypass firewalls that block ICMP:
mtr --tcp --port 443 google.com
mtr --udp --port 53 8.8.8.8TCP mode is especially useful when probing web servers and other TCP services behind firewalls that pass port 80 or 443 traffic but block ICMP entirely. These flags require root on most systems.
Saving Reports
To capture a report and save it to a file for sharing with an ISP or network team:
mtr --report --report-cycles 100 google.com > mtr-report.txtFor JSON output (useful for automated processing):
mtr --report --json --report-cycles 100 google.com > mtr-report.jsonFrequently Asked Questions
What does mtr stand for?
mtr originally stood for Matt's Traceroute, named after its original author Matt Kimball. The project is now maintained by the open-source community. Some documentation refers to it as My Traceroute, but Matt's Traceroute is the original meaning.
How is mtr different from traceroute?
traceroute sends a fixed number of probes and exits, giving you a one-time snapshot of the path. mtr runs continuously, sending probe after probe and updating statistics in real time. This means mtr can detect intermittent packet loss that a single traceroute would miss entirely — if loss occurs only 2% of the time, a 3-probe-per-hop traceroute might never see it, whereas mtr accumulates hundreds of samples and displays an accurate loss percentage.
What does packet loss at an intermediate hop mean in mtr?
Packet loss shown at an intermediate hop but not at subsequent hops almost always means that router is rate-limiting or deprioritising ICMP replies — not that it is actually dropping traffic. This is a normal router behaviour to protect CPU. Only treat packet loss as a genuine problem when it appears at a hop and persists through all subsequent hops, especially the final destination. That pattern indicates real loss on the link leading to or at that hop.
How do I install mtr on Windows?
mtr is not available natively on Windows. The most commonly used Windows alternative is WinMTR, a graphical application that provides the same continuous path diagnostics. Download it from the WinMTR project page, enter the target hostname, and click Start. For command-line use, you can also run mtr inside WSL (Windows Subsystem for Linux) by installing it with apt: sudo apt install mtr.
What do the columns in mtr output mean?
The key columns are: Loss% — percentage of probes that received no reply; Snt — total probes sent to this hop; Last — RTT of the most recent probe in milliseconds; Avg — average RTT across all probes; Best — lowest RTT seen; Wrst — highest RTT seen; StDev — standard deviation of RTT, indicating how consistent the latency is. High StDev at a hop suggests unstable or variable latency rather than simple congestion.
How long should I run mtr to get a reliable result?
For a reliable result, run mtr for at least 100 cycles, which takes about 100 seconds at the default one-probe-per-second rate. For intermittent problems that appear under load or at specific times of day, running mtr for 5–10 minutes gives a more representative sample. Use mtr --report --report-cycles 200 google.com to run exactly 200 cycles non-interactively and print a summary.