Diagnosing Packet Loss and High Latency

When your server feels sluggish, SSH stutters, or pages load in fits and starts, the culprit is usually packet loss or rising latency. The trick is to measure the problem first, then narrow it down segment by segment: is it your local network, the transit line in between, or the server end?

Step 1: Quantify loss and latency with ping

ping is the fastest health check. Run it from your own machine and send a batch of packets:

# Send 100 packets, then read the summary; -i 0.2 speeds things up
ping -c 100 -i 0.2 YOUR_SERVER_IP

Focus on the last two lines:

• packet loss: 0% is ideal; an occasional 1%–2% usually goes unnoticed; sustained >5% causes visible stutter.
• rtt min/avg/max: latency. avg shows the overall level, and a wide gap between min and max (high jitter) means an unstable line.

One run isn't enough. Test once during the day and once at peak evening hours (roughly 20:00–23:00) and note the loss and average latency for each. Many lines only degrade under evening congestion.

Step 2: Locate the bad segment with mtr

ping tells you whether there's a problem; mtr tells you which hop it's on. It combines traceroute and ping, continuously sampling loss and latency at every hop.

sudo apt update && sudo apt install -y mtr-tiny
# -r for a report, -c 200 for 200 samples, -w for wide output that screenshots cleanly
mtr -rw -c 200 YOUR_SERVER_IP

Read the Loss% column and judge by position:

• Loss on hop 1 or 2: the problem is local (home router, office gateway, weak WiFi). Switch to a wired connection or a different network and retest to confirm.
• Loss on a middle hop that clears up by the final hop: usually "phantom loss." Many routers deprioritize the probe packets passing through them, so if the last hop is clean, the real impact is likely small.
• Loss that starts at some middle hop and continues all the way to the last hop: this is real loss on the line or the remote end — the most worth reporting.
• Loss only on the final hop (your server): the box itself may be overloaded or rate-limiting. Log in and check top and ss -s first.

Step 3: Local vs. line vs. remote

Cross-check the results:

• Switch to another network (e.g. a phone hotspot) and ping again. If it clears up, the problem is local.
• From the server, ping a public address in reverse (e.g. ping -c 50 1.1.1.1). If outbound loss shows there too, it's the remote data center.
• Fine by day, bad at peak, with loss concentrated on middle hops? That's line congestion.

Step 4: Switch lines or contact support?

• Local issue: change networks or reboot the router yourself — no need to involve the provider.
• Evening congestion (real mid-path loss, good by day, bad at night): consider a different line option and send your data to support for review.
• Persistent remote loss or latency (all day, loss at the final hop): clearly on the provider's side — open a ticket.

Handing data to support

"It's laggy" helps no one. Provide:

• Your source network and rough location, plus the time of each test (mark day vs. evening peak).
• The full ping summary (loss % and min/avg/max).
• The complete mtr report or a screenshot (use -w wide format — don't crop half of it).
• Two comparison sets, day and evening, and whether the issue reproduced on a different network.

Summary

Start with ping to confirm loss and latency, then use mtr to find the exact bad hop. Combine a network-swap test with a day-versus-evening comparison to separate local, line, and remote causes. Only real loss (middle hop through the final hop) or an all-day remote problem warrants switching lines or contacting support — and attaching complete ping/mtr data with timestamps makes the whole process far faster.