Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

In the mtr man pages, it reads:

mtr combines the functionality of the traceroute and ping programs in a single network diagnostic tool

I use mtr a lot, and find that it's way much faster than traceroute. Instinctively, mtr gives me the answer emidiately, while traceroute list each ip address every seconds. At my own computer, I used time mtr www.google.com and time traceroute www.google.com, the result is 21.9s VS 6.1s.

The question is why? Since mtr = ping + traceroute, doesn't that mean it's slower or at least the same as traceroute.

Can anyone gives me a reasonable and detailed answer?

share|improve this question

4 Answers 4

up vote 15 down vote accepted

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, were 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 causes 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 is 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 send.

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, 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.

share|improve this answer
    
This is a much better reply. –  NickW Apr 1 at 11:46

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.

share|improve this answer

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.

share|improve this answer

The primary reason is the way traceroute runs. It sends a UDP (or ICMP on windows) packet with a TTL of one to the first host, and when it receives a timeout reply (or it passes an internal timeout), it then generates the next packet for the next host with a TTL of two, and so on (adding one to the TTL for each host). So traceroute's total time includes the sending and receiving of packets for each host, sequentially,.

mtr, after determining the path the packets take, sends all of the ICMP ECHO packets in parallel.

share|improve this answer
    
How does mtr know where to send the packets to ? –  Iain Apr 1 at 10:41
    
Yeah, I should add that in, though how it "actually" finds that out I think would require me to read the source :) –  NickW Apr 1 at 10:46
    
[mtr] investigates the network connection between the host mtr runs on and a user-specified destination host. After it determines the address of each network hop between the machines –  NickW Apr 1 at 10:46
1  
@Iain It sends all of the packets to the one address you specify. The different packets specify a different maximum distance for how far they will travel before getting an error back. The addresses displayed by mtr or traceroute are only known once the reply comes back. –  kasperd Apr 1 at 11:29

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.