You can make mtr start in this view with --displaymode=2 (direct command line arguments, `mtr --displaymode=2 …`; or shell alias, `alias mtr="mtr --displaymode=2"`; or set environment variable MTR_OPTIONS=--displaymode=2).
Screenshot of this mode: https://temp.chrismorgan.info/2025-02-06-hn-42924182-mtr-dis...
—⁂—
¹ 1.1 = 1.0.0.1 = Cloudflare public DNS, a convenient nearby public internet endpoint.
I like the work https://fasterdata.es.net/ does. They provide clear guides and set expectations if you want to get more bandwidth out of a connection.
sudo apt install mtr-tiny
One thing I've not understood is why will some hops have consistently lower ping times than hops farther down the chain in the same trace?
Is it indicating that the router is faster at forwarding packets than responding to ping requests?
https://archive.nanog.org/sites/default/files/traceroute-201...
Exactly this. In most “real” routers, forwarding (usually) happens in the “data plane”. It’s handled by an ASIC that has a routing table accessible to it in RAM. A packet comes in on an interface, a routing decision is made, and it goes out another interface - all of this happens with dedicated hardware. Pings (ICMP Echo requests), however, get forwarded by this ASIC to a local CPU, where they are handled by software (in the “control plane”).
You’re really seeing different response times from the two control planes - one may be more loaded or less powerful than another, regardless of the capacity of their data planes.
Maybe the only thing I've explained more in my career than this is why it's ok that your Linux box has no "free" memory.
Beyond that technicality, your guess is often right... Routers will frequently prioritize forwarding packets over sending the TTL exceeded packets tools like MTR use to measure response times.
Obviously you know, but for anyone else reading, a modern traceroute tool (like mtr) can send icmp, udp or tcp, on generic or specific ports. Indeed the default for mtr on my laptop is to use icmp.
However, it could also be the case that the routing back to you is significantly different, so you can have a much longer path to you from router N than router N+1.
This is more likely to happen on routes that cross oceans. Say you're tracing from the US to Brazil. If router N and N+1 are both in Brazil, but N sends return packets through Europe and N+1 sends through Florida, N+1 returns will arrive significantly sooner.
I believe most of the time this is the reason indeed. Answering an ICMP error to a TTL expiration or to an echo request is very low priority.
This latency in error message generation may even be a better signal of the router load than the latency of the actualy trip through it.
Incidentally, if you suspect you yourself are this, I can't recommend any book more highly than Michael W. Lucas's Networking for Systems Administrators. Don't be fooled by the title - the whole idea is to get you to the level where you can talk to a network engineer without looking totally clueless, and no farther - an excellent stopping point.
I would recommend it handily over, say, my own Intro to Networking class in college. And yes, `mtr` is mentioned by name in it!
I'm 100% sure the only reason so many programmers know how NAT works is because NAT breaks video games.
https://movingpackets.net/2017/10/06/misinterpreting-tracero... (discussion at https://news.ycombinator.com/item?id=15474043 )
The other issue with packet loss is the tool doesn’t handle ICMP properly in the first place. A ping flood to an end to end host like 1.1.1.1 shows 0% loss, but when I use mtr to do flood like pinging it shows my wifi router with 100% loss. If I ping flood my router I get 0%.
It’s genuinely a bad tool and you should really just be keeping ping and traceroute separate as they do completely different things.