1)

2)
MTR (my traceroute) is a dynamic network performance diagnostic tool
combining the functionality of ping and traceroute. It investigates the connection
between destination host and source server (eg. your DataPacket server).
Precisely described, it analyses the response time and packet loss of routers
(hops) passed on the way to destination and back through TTL (time to live)
using ICMP. MTR sends a stream of packets while successively increasing TTLs
where each packet is discarded by the successive hop (first hop has TTL one,
second hop has TTL two, etc.), so we can see the trace to a given host.
mtr [YOUR HOST IP] -r
For MTR report generation, use -r option flag. If you’d like the results to be more
reliable, increase the cycle counts -c (10 cycles by default) and decrease the interval -
i (1 second by default).
Use parameter report wide -w flag that doesn’t truncate long DNS.
Force the -n flag which displays IP addresses as a numeric record instead of reverse
DNS lookups.
Loss% – what percentage of packets will not return
Snt – count of sent packets
 Last – latency of the last sent packet
Avg, Best, Wrst – average, best and worst latencies of all packets
StDev – the standard deviation of latencies to each hop. A high StDev means there
are network inconsistencies

 Ping - Pay attention to the average RTT except in cases where the
standard deviation (stddev) is really high.
 Ping to troubleshoot DNS connectivity. If you ping a hostname, ping
will first try to resolve that hostname to an IP address.
Note:- When an IP packet is sent, its TTL is usually 255 and is then decremented by 1 at each
hop.

 Round-Trip Time: If it’s taking too long for packets to go from source to
destination, there may be something wrong with the quality of your link. It
could also be that the distance between source and destination is quite
large. For example, between device 6 (41.221.166.25) and 7
(197.149.150.169), there is a big jump in the RTT. Upon research, I see
that those IP addresses are in two different countries (Nigeria and
Angola), which is why the RTT is that large, as packets are
travelling far.

Use ip location geo finder

By default, when you run MTR, it will try to use reverse DNS to resolve IP
addresses to hostnames. This can slow down your troubleshooting process
especially if you are not interested in DNS or using DNS on your network. We
can disable the DNS resolution process using the -n or –no-dns option.
Also, MTR sends successive packets every 1 second. This may be fine when a
network is operating normally. However, during network congestion, packets usually
arrive at a faster rate. We can use the -i option (or –interval) to specify how often
we want MTR to send packets, thus simulating a congested network:
Notice that with a shorter interval between packets and sending 50 packets,
I now see some packet loss between the source and some devices in the
path.

s an example, I tried using MTR on google.com and I noticed that the

destination device was filtering my ICMP packets:

Since I know google.com will respond to TCP port 80 (HTTP), I can change my
MTR options to use that instead. The option for UDP is -u (or –udp), TCP is -T
(or –tcp), while SCTP is -S (or –sctp) and you can specify the port using -P (or
–port).
As you can see, I can now get all the way to my destination (google.com).

Packet loss
Packet loss tracks the percentage of packets that failed to reach their destination. In
general, a single network hop with packet loss on a traceroute is not a cause for
concern. Figure 1 shows such a traceroute, with hop 9 showing packet loss.

Figure 1. Single occurrence of packet loss.

A single hop showing packet loss is rarely an indication of a malfunctioning

device along the route. Other more likely causes include ISP rate limits, and, on
occasion, a busy router CPU.
Furthermore, small occurrences of packet loss throughout a route are usually benign.
Figure 2 shows an example of ISP rate-limiting resulting in minimal packet loss (Figure
2).
Figure 2. Minimal packet loss from ISP rate-limiting.
Figure 3 shows significant packet loss from hops 8 - 13, indicating a serious
problem. Identifying the cause of this problem requires additional investigation and
considerable knowledge. If this problem does not resolve itself within 30
minutes, contact our Support Team and attach the MTR report.

Figure 3. Significant and pervasive packet loss.

Network latency
Even under ideal conditions, latency increases with every hop. As long as these
increases remain within expectations, there is no cause for concern. The potential
causes of high latency are extensive, but include mis-configured routers, congestion,
and service types, among many others. In general terms, anything under 100
milliseconds (ms) is ideal, but transcontinental hops will tend to exceed this time.
However, as shown in Figure 4, one outlying latency spike does not indicate a problem.
In Figure 4, the latency spikes at hop 6, but drops significantly afterward. In this
case, the results suggest no effect to the overall service. Always examine the
latency to the final hop along the route when analyzing MTR results.
Figure 4. Latency spike.
Figure 5 shows a potentially more significant problem, with high latency starting at
hop 8 and persisting through subsequent hops. This suggests some kind of issue
with the router at that hop.

Figure 5. Persistent high latency.

https://www.linode.com/docs/networking/diagnostics/diagnosing-network-issues-with-mtr/