How to diagnose packet loss and jitter with mtr

What is mtr and why it is essential for networks

When a production application suffers from intermittent slowdowns or API calls that stall without an obvious reason, infrastructure blame usually falls on the network. Discovering exactly where data packets get lost between your server and the destination used to be an arduous task, requiring switching between traditional commands. In practice, this meant you were stuck between traceroute's static path and ping's spot sampling.

This is exactly where mtr (My Traceroute) shines. It combines the best of both worlds by continuously sending packets to every intermediate hop up to the destination, displaying real-time statistics on delays and data loss. To understand the severity of an issue, keep in mind that delivery delay affects synchronous calls, while instability destroys continuous streams. Before blaming your cloud provider, we need to master reading this tool.

How to interpret latency, loss, and jitter in practice

Before launching commands in the terminal, we need to translate the concepts that appear on the mtr screen. Latency is the round-trip time it takes for a packet to travel, measured in milliseconds. Jitter, on the other hand, is the variation in this delay time. If a packet arrives in 20ms and the next in 120ms, the jitter is extremely high, causing severe failures in voice and video streams. Meanwhile, packet loss indicates how many messages vanished along the way.

In everyday engineering, looking solely at average latency hides painful realities. A hop might look stable with a 30ms average, but oscillate wildly between 10ms and 300ms. When you understand this variance, it becomes clear why users complain that the system freezes every now and then. To validate bandwidth and confirm if the channel handles traffic, we often cross-reference these metrics with additional diagnostics, such as measuring bandwidth and jitter in Linux with iperf3, closing in on hidden bottlenecks.

Installation and basic execution of the mtr command

Most Linux distributions have mtr available in their official repositories. Installing it is quick and requires only basic administrative privileges. Let's see how to set it up on Ubuntu, Debian, or derivative servers to prepare our test environment.

To install the tool in your production environment or workbench, run your distribution's standard package manager:

sudo apt update && sudo apt install mtr -y

With the binary installed, the most common usage to check an IP address or domain is running it directly in the terminal. By default, it sends continuous ICMP packets to map the path and update the screen table every second.

mtr 8.8.8.8

How to identify a faulty hop versus a false positive

One of the biggest mistakes when analyzing mtr is panicking upon seeing a 100% loss rate on an intermediate hop. Carrier routers and cloud providers frequently prioritize routing traffic and heavily throttle responses to ICMP diagnostic packets directed at themselves. In practice, this means the router keeps forwarding your packet onward perfectly, but it simply chooses not to reply to mtr's ping.

To confirm whether the issue lies in that specific hop or is just standard router behavior, always check the next hop. If hop 4 shows 100% loss, but hop 5 shows 0% loss and the exact same final latency, hop 4 is a harmless false positive. On the other hand, if the loss recorded at the intermediate hop persists and propagates cumulatively to the final destination, you have found a real network bottleneck that needs to be reported to the provider.

Advanced data collection and reporting in production

When we need to investigate an intermittent issue that only happens during peak hours, interactive terminal visualization is no longer enough. We need to accumulate data over an extended period to generate indisputable technical evidence for infrastructure teams or telecom operators.

To generate a static report after collecting a significant amount of samples, we use specific parameters that bypass the interactive interface and save the consolidated summary. The command below sends one hundred packet cycles and formats the output cleanly:

mtr --report --report-cycles 100 1.1.1.1

This execution ensures that every hop is tested one hundred times, smoothing out isolated spikes and revealing the true packet loss rate and average accumulated jitter along the route. It is the perfect format to attach to technical support tickets without leaving room for ambiguous arguments. To complement this implementation in production environments, see our related technical analyses on How to test optocouplers on board with a multimeter and How to measure idle power consumption using a wattmeter.

Final considerations

Mastering mtr transforms how we investigate network issues, replacing guesswork with concrete data obtained directly at the transport layer. Knowing how to differentiate a router dropping diagnostic packets from a genuinely saturated link saves hours of stressful debugging. Integrating this testing routine into your daily engineering arsenal ensures rapid, assertive diagnostics, keeping distributed systems and production applications running smoothly and with high performance.