One example of this is when a hop on the route does not reply to ARP requests. 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. In some scenarios there are limits to how many packets you can get replies for. Too much parallelism can cause the output to become inaccurate. 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. 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. Since traceroute cannot go back and update output, it has to wait until it has ultimately decided what it will display.įor 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. 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. Mtr renders output in a different way, where mtr can go back and update output on previous lines. Traceroute produces the output in order top down. The plain traceroute command gets much quicker, if you disable reverse DNS.Īnother important difference, which I did not see mentioned, is how the two tools render the output. If reverse DNS is performed, you have to wait for that as well. Another contributing factor is how long they wait for a reply before the hop is considered to not be responding. Parallelism is a major reason for variation in the speed of these tools.
0 Comments
Leave a Reply. |