How to Read an MTR Report: Diagnosing Packet Loss, Latency Spikes, and Network Jitter

When a website or API suffers from intermittent lag, sluggish page loads, or dropped connections, a standard ping command only proves that a problem exists. It cannot show you where along the transit path packets are disappearing. Meanwhile, a traditional traceroute only captures a single snapshot in time, routinely missing intermittent packet bursts, route flaps, and transient congestion.

MTR (My Traceroute) solves this dilemma. By combining the continuous packet sampling of ping with the hop-by-hop discovery of traceroute, MTR provides real-time statistical insights into latency variance, packet loss, and jitter across every router between the client and destination.

This guide explains how MTR operates, how to read every column of an MTR report, how to differentiate between harmless ICMP rate-limiting and catastrophic packet loss, and how to use an online MTR test to diagnose network degradation.

MTR vs. Traceroute vs. Ping: When to use which

Understanding when to employ each tool prevents wasted diagnostic cycles:

Feature	Ping	Traceroute	MTR (My Traceroute)
Visibility	End-to-end only	Every intermediate hop	Every intermediate hop
Sampling Frequency	Continuous	Single pass (usually 3 probes)	Continuous sampling over time
Statistical Analysis	Min / Avg / Max / Mdev	None (single RTT values)	Avg, Best, Worst, and Standard Deviation (StDev)
Packet Loss Detection	Aggregated total only	Coarse (asterisks on timeouts)	Precise percentage per individual router hop
Intermittent Lag Isolation	Poor	Very poor	Excellent

A ping test is ideal for a fast reachability sanity check. A traceroute test maps the geographic and autonomous system (ASN) path. But when diagnosing intermittent spikes, dropped VoIP calls, streaming buffering, or flaky API connections, an MTR test is the definitive diagnostic standard.

Anatomy of an MTR report

When running MTR against a target domain or IP, the output resembles the following diagnostic table:

Host                                  Loss%   Snt   Last    Avg   Best   Wrst  StDev
1. 192.168.1.1 (local-gateway)         0.0%    50    0.8    0.9    0.6    1.4    0.2
2. 100.64.0.1 (carrier-cgnat)          0.0%    50    4.1    4.4    3.8    8.2    0.7
3. 203.0.113.14 (isp-edge-core)        0.0%    50    9.2    9.5    8.9   14.1    0.9
4. 198.51.100.22 (transit-peering)    20.0%    50   12.1   12.4   11.8   16.5    1.1
5. 195.66.225.1 (ixp-london)           0.0%    50   18.4   18.7   17.9   24.2    1.3
6. 104.26.12.31 (destination-server)   0.0%    50   18.2   18.5   17.7   22.1    0.8

Understanding the meaning of each column is critical for accurate analysis:

• Host: The reverse DNS hostname (PTR record) and IP address of the router at that hop. If reverse DNS is unconfigured, only the raw IP appears.
• Loss%: The percentage of probe packets that failed to return an ICMP response for that specific hop during the test run.
• Snt (Sent): The total number of probes transmitted to that hop. For reliable statistical significance, aim for a minimum of 30 to 50 sent packets.
• Last: The round-trip latency (in milliseconds) of the most recently returned probe.
• Avg: The average (arithmetic mean) round-trip time across all completed probes.
• Best: The lowest round-trip latency recorded. This represents the theoretical minimum physical transmission time across the current routing path under zero queue congestion.
• Wrst (Worst): The highest round-trip latency recorded. Extreme worst-case values relative to the average point toward bufferbloat or transient link saturation.
• StDev (Standard Deviation): The mathematical spread of latencies around the average. A low standard deviation (e.g., < 2.0 ms) signifies a remarkably steady, stable link. A high standard deviation (e.g., > 25.0 ms) signals severe network jitter, fluctuating buffer queues, or variable wireless interference.

The #1 trap: ICMP rate limiting vs. true packet loss

The single most common mistake engineers make when analyzing MTR reports is misinterpreting ICMP rate-limiting on intermediate routers as an active network outage.

Look closely at Hop 4 in the sample report above:

4. 198.51.100.22 (transit-peering)    20.0%    50   12.1   12.4   11.8   16.5    1.1
5. 195.66.225.1 (ixp-london)           0.0%    50   18.4   18.7   17.9   24.2    1.3
6. 104.26.12.31 (destination-server)   0.0%    50   18.2   18.5   17.7   22.1    0.8

Hop 4 shows 20.0% packet loss, yet Hop 5 and Hop 6 show 0.0% packet loss.

Is there a network issue at Hop 4? No.

Why this happens

Enterprise core routers are designed to forward commercial customer packets in hardware (via specialized Application-Specific Integrated Circuits, or ASICs) at line rate. Generating an ICMP "Time Exceeded" reply requires sending that packet to the router's slower central CPU (Control Plane Policing, or CoPP).

To protect their control planes against denial-of-service floods, network administrators intentionally rate-limit ICMP responses. When MTR sends rapid probe bursts, the router simply ignores a portion of the ICMP generation requests. However, it forwards all transit traffic onward to Hop 5 and Hop 6 without dropping a single packet.

The Golden Rule of MTR analysis

True packet loss is cascading. If packet loss represents an actual physical transmission failure or saturated link, the loss will persist through that hop and appear on every subsequent hop all the way down to the destination.

If a hop displays 15% loss, but all subsequent hops display 0% loss, the loss at that intermediate hop is harmless ICMP rate-limiting. Dismiss it.

Conversely, consider this pattern:

3. 203.0.113.14 (isp-edge)            0.0%    50    8.5    8.8    8.2   10.1    0.4
4. 198.51.100.22 (congested-link)    18.0%    50   45.2   44.8   12.1  112.5   18.7
5. 195.66.225.1 (ixp-london)         18.0%    50   52.1   51.9   18.2  119.0   18.2
6. 104.26.12.31 (destination)        18.0%    50   51.8   51.5   17.9  117.4   18.5

Here, the 18% packet loss begins abruptly at Hop 4 and remains present through Hops 5 and 6. Furthermore, the average latency quadruples from 8.8 ms to 44.8 ms, and the standard deviation explodes. This is true cascading packet loss caused by an overloaded transit circuit or faulty physical interface at Hop 4.

Identifying common network anomalies

By evaluating the relationship between Hop count, Loss%, Avg, and StDev, you can diagnose specific infrastructure bottlenecks:

1. Last-mile local network saturation

Host                                  Loss%   Snt   Last    Avg   Best   Wrst  StDev
1. 192.168.1.1 (home-router)           6.0%    50    4.2    8.5    1.1   98.2   14.2
2. 100.64.0.1 (isp-gw)                 6.0%    50   12.1   16.4    8.2  104.1   13.9

• Symptom: Packet loss and wild latency fluctuations begin immediately on Hop 1 (the local Wi-Fi router or LAN gateway).
• Cause: Weak Wi-Fi signal, 2.4 GHz radio frequency interference, a failing Ethernet cable, or local network congestion (such as heavy background torrenting or cloud backups saturating upstream bandwidth).

2. Transoceanic fiber cable transitions

Host                                  Loss%   Snt   Last    Avg   Best   Wrst  StDev
4. 140.222.8.1 (new-york-core)         0.0%    50   14.2   14.5   13.8   16.2    0.5
5. 64.230.12.9 (london-landing)        0.0%    50   88.5   88.9   87.8   92.1    0.8

• Symptom: Latency jumps abruptly by 70–80 ms between two consecutive hops, but packet loss remains 0% and StDev stays small.
• Cause: Normal physical propagation delay. Light travelling through undersea fiber-optic glass cables across the Atlantic Ocean takes approximately 70 ms round trip. This is not an outage; it confirms physical geographical distance.

3. ISP peering disputes and transit congestion

Host                                  Loss%   Snt   Last    Avg   Best   Wrst  StDev
5. 203.0.113.80 (isp-egress)           0.0%    50   22.1   22.4   21.8   24.5    0.6
6. 198.51.100.95 (carrier-ingress)    12.0%    50   78.4   76.2   23.1  184.2   34.8
7. 172.67.14.2 (destination)          12.0%    50   77.9   75.8   22.9  181.5   34.2

• Symptom: Latency triples and packet loss cascades immediately at the boundary where your ISP hands traffic off to a Tier-1 transit backbone or internet exchange point.
• Cause: Saturated inter-carrier peering links. Common during peak evening hours when peering capacity is exhausted.

How to use MTR data when contacting support

When submitting a trouble ticket to an ISP, cloud host, or CDN provider, raw screenshots of single ping commands are frequently dismissed. An MTR log provides incontrovertible technical proof.

Follow these best practices when collecting evidence:

1. Run at least 50–100 cycles: Single-digit probe counts do not yield sufficient statistical certainty.
2. Collect bidirectional traces: Internet routing is asymmetric. Packets returning from the server often travel over completely different carriers than outbound packets. Running an MTR from your machine to the server and a reciprocal test from the server back to your public IP gives full visibility.
3. Cross-reference with IP and ASN lookups: Use an IP info tool to check the Autonomous System Number (ASN) and geographic city of the bottleneck router to pinpoint the exact responsible carrier.

Run instant MTR diagnostics with PingXD

You do not need to install CLI utilities or manage complex dependencies on your machine to analyze network paths.

With the PingXD MTR test, you can dispatch multi-cycle MTR diagnostic probes to any hostname or IP from worldwide nodes. Combine it with our traceroute test and website performance test to isolate whether website slowdowns are caused by application code, DNS latency, or transit carrier degradation.