why mtr is much faster than traceroute?

Solution 1:

Parallelism is a major reason for variation in the speed of these tools. Another contributing factor is how long they wait for a reply before the hop is considered to not be responding. If reverse DNS is performed, you have to wait for that as well. The plain traceroute command gets much quicker, if you disable reverse DNS.

Another important difference, which I did not see mentioned, is how the two tools render the output. Traceroute produces the output in order top down. Mtr renders output in a different way, where mtr can go back and update output on previous lines.

This means mtr can display output as soon as it is available, because if later replies cause that output to not be accurate, mtr can go back and update it. Since traceroute cannot go back and update output, it has to wait until it has ultimately decided what it will display.

For example if hop number 2 is not responding (which is a symptom I have seen on multiple ISPs), traceroute will display hop number 1 and then wait for a while before it displays hop number 2 and 3. Even though the reply from hop number 3 has arrived it is not being displayed because traceroute is still waiting for the reply from hop number 2. Mtr does not have that restriction and can display the reply from hop number 3 and still go back to display the reply from hop number 2, if it arrives later.

Too much parallelism can cause the output to become inaccurate. In some scenarios there are limits to how many packets you can get replies for. Sending more packets in those cases will not speed up the process, it will however cause more lost packets, as you get the same number of replies with more packets being sent.

One example of this is when a hop on the route does not reply to ARP requests. Usually the first packet will trigger an ARP request, and if more packets arrive before the ARP request times out, only the last of those packets will be buffered and get a reply.

Another difference is in how many hops with no responses will be displayed before the tool stops displaying more hops. I have seen the traceroute command continue for as many hops as requested (30 by default), while the mtr command would stop as soon as it had passed five hops with no responses.

Solution 2:

The traceroute command is sending 3 probes per hop if you limit it to 1 probe -q 1 then the results become comparable

time mtr -r -c 1 google.com
.
.
.
real    0m2.640s
user    0m0.003s
sys     0m0.018s


time traceroute6 -q 1 google.com
.
.
.
real    0m0.445s
user    0m0.006s
sys     0m0.007s

I would expect the main differences between comparable tests to be related to DNS query time and path differences. You'll note that my traceroute is faster then the mtr but this isn't always the case.

---

Solution 3:

I suppose this come from the way the route tracing is implemented. traceroute sent at least 3 packets for each hop in the route to the destination, sequentially.

mtr discover the hops in the route first, and then send packet to each node in parallel.

It seems also to me that there is a difference in the way mtr handles hop not responding to ping / probes; it ignores then quickier than traceroute which seems to send its 3 packets all the time, even if the first attempts failed to get response.