How To Take An MTR


What Is A MTR?

MTR, also called My Traceroute,  is a piece of software that combines that functions of a ping and traceroute test into a single tool. You are probably wondering, “What is the purpose of this?, Why make a new tool when there is already two that do the same functions?”.

Ping and traceroute are both excellent tools, but they often only tell you half of the story. A ping test will tell you if the server or IP you are testing against is up or down. A traceroute test will tell you the path that your request to that remote location takes over the internet. When debugging what is causing a problem with your service it is important to know both pieces of information. So lets say that we ping our service and it is either down or experiencing heavy packet loss. The ping tell us that there is a problem, but where is the problem happening? Is it on the server itself, is the problem with some congestion on an ISP in between us and the server we are trying to connect to? With just a ping test you cannot tell. An MTR will tell you exactly where issues are happening by tracerouting the path your connection takes to the remote server and then pinging each hop along the way. With this you can easily see if the packetloss starts building up before it gets to where your server is. If it is, the issue is not likely with who is hosting your server, but instead with some ISP that is a middleman between you and them.

How To Perform A MTR


Windows does not include the MTR program by default, so you will need to install a version of it. A popular version is called winmtr. it can be downloaded from HERE. Sometimes the website is a bit slow so you might need to reload it.  Once you download the software and open it up, it should look like the image below.


The host textbox is where you put the IP or domain of the service that you want to test. When you click the start button the test will begin to run. Always run the test until the “Sent” column is at least 20, so that enough data can be gathered to be useful. When you are done collecting data just hit the “Stop” button and test will stop. You can click on the “Copy Text to clipboard” button if you need to share the results with someone else.

Mac OS X

Mac OS X also does not include the software by default, but can be installed quickly through a simple package installer. It can be downloaded HERE. Once downloaded run through the package installer quickly and then open up terminal. Terminal can be opened by going to your “Applications” folder and then found under the “Utilities” folder.



The syntax for running the command is:

sudo /usr/local/sbin/mtr <testing ip or domain>

Sudo is required because the program requires root permissions to run (hit enter to run). Because of this the system will prompt you for your admin password when you run the command.


Once you hit enter (after entering your admin password) the test will begin running. Run the command until the “Snt” or Sent column reaches at least 20. The more data the better. When you are done running the test hit the p key to pause the test. This will allow you to copy and paste the output out of the command to share with others. If you want to resume, simply hit any other key.


When you are completely done using the program hit the q key to quit the program.


Linux is probably the easiest of all the operating systems to install the MTR software on. It is possible the program might already be installed on your system. To check, run the command:

mtr --help

If you get output showing the usage of the command similar to:


Then the program is already installed. If not simply install it via the package installer on your OS

For redhat based yum systems:

yum install mtr -y

For debian based apt systems:

apt-get install mtr -y

Once the system has finished the install you can use the software. The syntax of the command is:

mtr <ip or domain you want to test>

As soon as you type the command the test will start executing. Let the command run until the “Snt” or Sent column is at least 20. The more data the better.


When you have gathered as much data as you want, hit the p button. This will pause the execution of the test and allow you to copy and paste the text to share to someone else if you wish. If you choose that you want to resume your test, simply hit any other key. When you are all done with your test, hit the q key to quit the network test.

Analyzing The Results

Once you have collected the data it is important to know what everything stands for.

   HOST: example                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. inner-cake                    0.0%    10    2.8   2.1   1.9   2.8   0.3
  2. outer-cake                    0.0%    10    3.2   2.6   2.4   3.2   0.3
  3.                  0.0%    10    9.8  12.2   8.7  18.2   3.0
  4. po-20-ar01.absecon.nj.panjde  0.0%    10   10.2  10.4   8.9  14.2   1.6
  5. be-30-crs01.audubon.nj.panjd  0.0%    10   10.8  12.2  10.1  16.6   1.7
  6. pos-0-12-0-0-ar01.plainfield  0.0%    10   13.4  14.6  12.6  21.6   2.6
  7. pos-0-6-0-0-cr01.newyork.ny.  0.0%    10   15.2  15.3  13.9  18.2   1.3
  8. pos-0-4-0-0-pe01.111eighthav  0.0%    10   16.5  16.2  14.5  19.3   1.3
  9. as15169-3.111eighthave.ny.ib  0.0%    10   16.0  17.1  14.2  27.7   3.9
 10.                 0.0%    10   19.1  22.0  13.9  43.3  11.1
 11.                0.0%    10   15.1  16.2  14.8  20.2   1.6
 12.    0.0%    10   15.6  16.9  15.2  20.6   1.7


  • Everything in this column shows the name or the IP of each step or hop in the path it takes to reach the destination you are testing

Loss %

  • This section shows the percentage of packets lost in transit. This value is supposed to be 0% at all times or at least not very high.


  • This is the number of packets sent in the test. Tests should at minimum send 20.


  • This is the latency result of the last test packet sent.


  • This is the results of averaging the latency of all packets sent so far.


  • This is the result of the best test latency of all the packets sent.


  • This is the result of the worst test latency of all the packets sent.


  • This is just the standard deviation of the results.

The main issues you will be looking for is a spike in packetloss and a large spike in latency at certain places through the test. This is typically where you will find the cause of the problem. If these show up before it hits the data center where your server is then the issue is typically not on your data center’s end. However if you do contact your data center they will very likely want the result of such a test from your end so that they can get the most information.



CC BY 4.0 This work is licensed under a Creative Commons Attribution 4.0 International License.

Alex Wacker has written 16 articles

I am the founder and owner of Subnet Labs LLC. Impact VPS is one of our VPS brands. Linux, virtualizaton and the internet amaze me and I enjoy learning new things every day about them.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>