Diagnose Latency and Packet Loss: ping, traceroute, mtr

When your application feels slow or connections intermittently fail, the first suspects are latency and packet loss. The classic tools ping, traceroute, and mtr all probe the network, but they answer different questions. Knowing which to run, and how to read the output, is what separates a systematic diagnosis from random poking.

Basic Latency with ping

ping sends ICMP echo requests and measures the round-trip time to a destination. It is the fastest answer to the question: is the host reachable, and is the path slow?

ping -c 10 1.1.1.1
ping -c 10 netbayhosts.in

The output shows each reply with its round-trip time in milliseconds, plus a summary of minimum, average, and maximum RTT and the packet loss percentage. A consistently high average with wide variance (some replies fast, some slow) suggests queuing or congestion. Consistent high values suggest a physically distant path or a saturated link.

Compare ping to a destination several times over. If the first reply is slow and later ones are fast, that is cold cache or a busy initial path. If every reply is slow, it is systematic.

Judging Jitter and Loss

The difference between the fastest and slowest reply is jitter. High jitter is often worse than high average latency because it breaks real-time protocols and makes TCP timeouts unpredictable.

ping -c 30 -i 0.5 1.1.1.1

Running many pings at a short interval with a tight count reveals patterns. Watch for occasional packets that take much longer than the median, or for lost packets that appear sporadically. A single lost packet out of thirty is normal traffic burst noise. Ten lost packets out of thirty indicates real loss on the path.

Tracing the Path with traceroute

traceroute maps the route packets take, showing each hop and its round-trip time. It works by sending packets with increasing TTL values so each router in turn reports that it expired the packet and returns an ICMP time-exceeded message.

traceroute -n 93.184.216.34
traceroute -T -p 443 netbayhosts.in

The -n flag disables reverse DNS, keeping output fast. The -T -p 443 variant sends TCP probes to a specific port, which is more reliable through firewalls that drop ICMP. Each line shows the hop number, the address, and three sample times.

The Critical Rule: Never Trust a Jump Overview

The biggest myth in network diagnosis is that traceroute loss at a specific hop means that hop is the problem. In reality, a router that rate-limits its ICMP responses will show loss for itself and for all subsequent hops, even when it is forwarding packets perfectly.

You also cannot conclude much about intermediate hops by comparing them to the final hop. The final hop measures the true path; middleware hops often show inflated or incomplete times. Only compare hops within the same path. The two numbers that matter most are the first hop on your network and the final hop.

mtr: Continuous Path Probing

mtr combines ping and traceroute into one rolling display. It continuously pings every hop and reports loss and latency per hop, refreshing live. This is the best tool for observing a problem that comes and goes.

mtr -n -c 100 1.1.1.1
mtr --report netbayhosts.in
mtr -i 1 -c 300 8.8.8.8

The -c 100 flag runs 100 packets per hop then stops. The --report mode prints a summary table instead of a live display, ideal for a logged diagnosis. The -i 1 flag sends one packet per second, useful over a longer observation window.

Read the mtr table left to right: the hop number, the address, the loss percentage, and the latency statistics. If loss appears at a middle hop but subsequent hops show zero loss, the middle hop is just not responding to probes. If loss appears at your own first hop, the problem is on your side or at your provider.

Interpreting Loss Patterns

Here is the mental model for mtr output. If the first several hops show near-zero loss and low latency, and only the final segment shows loss, the problem is near the destination, possibly its edge firewall. If loss appears starting at an early hop and stays through the rest of the path, you have genuine loss at that point. If loss appears at one middle hop and then disappears, that hop simply does not answer ICMP.

mtr -z -n -c 50 8.8.8.8

The -z flag appends AS numbers to each hop, revealing when your traffic leaves your provider's network and enters another autonomous system. Interesting shifts at AS boundaries tip you off to peering problems or a slow route handoff.

Pinpointing the Problem

Once you know you have loss, figure out whether it is on your server, at your provider, or upstream. Ping your own gateway, then a destination inside your provider's network, then a public destination.

ping -c 20 <your-gateway-ip>
ping -c 20 <your-provider-nameserver>
ping -c 20 1.1.1.1

If loss appears at your gateway, the problem is on your virtual NIC or your local segment. If it appears at the provider nameserver, the provider network is involved. If only the public destination shows loss, the problem is upstream of your provider, outside your ability to fix from the server.

Documenting a Slow Network

To hand a diagnosis to support or your provider, capture reproducible evidence. Run mtr with a fixed count and save the report, capture ping loss over a minute, and record the exact time the problem occurred.

mtr --report -c 50 8.8.8.8 > mtr-report.txt
mtr -n -c 100 1.1.1.1 | tee mtr-live.txt

A clean report with timestamps and consistent loss figures is far more convincing than "internet is slow." It also tells you exactly what changed if the path shifts between tests.

You can run these diagnostics on any Netbay VPS, where the public IP lets you trace real production paths anytime at netbayhosts.in.