Your connection is slow and you need to know where it is broken, not just that it is broken. Traceroute shows you the path. MTR shows you the path and tells you how healthy each hop is over time. This article walks you through both, how to read them, and how IPIPAI's trace_route tool brings the same insight to your browser without a terminal.
What Traceroute Actually Does
Traceroute (or tracert on Windows) works by sending packets with increasing TTL (Time To Live) values. The first packet dies at the first router, the second dies at the second, and so on. Each router that kills a packet sends back an "ICMP Time Exceeded" message, and traceroute records which router that came from. After enough rounds you have a numbered list of hops from you to the destination.
That is useful, but it is a one-shot snapshot. You see the path, you do not see whether hop 7 is dropping 40 percent of packets this week or whether hop 3 is adding 80 ms of latency on a bad cable.
What MTR Adds
MTR (My Traceroute) is a Linux tool that runs traceroute continuously and reports a rolling table for each hop. Instead of one line per router you get a small column of stats: sent packets, received, loss percentage, and four latency percentiles (SNT, LAST, BEST, AVG, WORST, plus STDDEV). It keeps running so a flaky link that only fails every few packets shows up clearly instead of hiding in a single pass.
Reading an MTR output is a discipline. Three columns matter most:
- Loss % — if a hop shows 30–100 percent loss but the next hop is healthy, that hop is likely just rate-limiting ICMP (common on public ISP routers), not actually broken. The real problem is where loss stops improving toward the destination.
- AVG — the average latency at that hop. A jump from 2 ms to 120 ms between two adjacent hops tells you which link is the slow one.
- WORST — the tail latency. Sporadic 900 ms spikes on an otherwise green link mean packet reordering or a congested peering point.
MTR vs Traceroute — When to Use Which
| Traceroute | MTR | |
|---|---|---|
| Goal | Find the path | Find the broken link and how bad |
| Runs | One pass | Continuous, rolling window |
| Latency data | Single value per hop | Min / avg / max / stddev |
| Packet loss | Not measured | Per-hop loss % |
| Best for | "Which route does this go?" | "Where is it actually hurting?" |
In practice I reach for traceroute first to see the geography of the route, then MTR to pressure-test the suspicious hops.
Running It Without a Terminal
If you are not on a Linux box, IPIPAI's Traceroute tool gives you the same hop-by-hop view in the browser. Type a destination and it walks the route, resolving each hop to a name and country when it can. You get the "which router is this" answer instantly, no SSH required.
For latency pressure testing at each hop, IPIPAI's Ping tool and the ping_host API let you fire packets at a specific IP and read back RTT, jitter, and loss. Combine the two: use traceroute to find the hop, then ping that hop to quantify it.
Common Patterns and What They Mean
Question marks in the middle of the route
A hop that shows ??? or * * * is a router that does not answer ICMP. That is not a failure — many transit providers deliberately silence ICMP to save CPU. The route is fine if the hops after it still respond.
A single hop with huge loss but the next is clean
Almost always ICMP rate limiting, not a real break. The network is probably fine; just the diagnostics are being throttled. Watch the destination's stats instead.
Loss that stays elevated toward the destination
This is the one that actually hurts. Sustained loss near the last hop means the path or the destination itself is dropping packets. That is where your user-perceived lag lives.
Wrapping Up
Traceroute answers "which way?" MTR answers "which link is bad and how bad?" Use them together and you will stop guessing. The IPIPAI Traceroute tool gets you the path in the browser, the Ping tool gets you the numbers, and the DNS lookup article is the natural next stop when the destination itself is a domain name. The rest of the toolkit lives on the IPIPAI articles page.