Test for Packet Loss

What Packet Loss Actually Means

Every piece of data traveling over the internet is divided into packets. Packet loss happens when some of those packets never arrive at their destination. The network sends them, they simply disappear somewhere along the path — into a saturated buffer, a failing cable connection, or an overwhelmed router port. TCP connections notice this and retransmit, which is why packet loss feels like stuttering video, choppy voice calls, or a game that freezes for a fraction of a second before snapping forward.

A speed test can show 300 Mbps while packet loss is destroying your gaming or call experience. Speed and packet loss are separate things. Speed measures how much data arrives per second when everything is working. Packet loss measures how often it fails.

How Much Loss Is Acceptable

Step 1: Test with Ping (Extended Count)

A quick 4-packet ping tells you almost nothing about packet loss. You need at least 100 packets to get a statistically meaningful result — preferably 500 or more run during the time the problem is happening.

# macOS / Linux — 200 packets to Cloudflare DNS
ping -c 200 1.1.1.1

# Windows — 200 packets (default is 32)
ping -n 200 1.1.1.1

# Linux continuous ping (Ctrl+C to stop, shows running stats)
ping -i 0.2 1.1.1.1

The last line of the output reports packet loss as a percentage. Run this against your router gateway first (usually 192.168.1.1 or 192.168.0.1), then against a public IP like 1.1.1.1, then against a hostname. If loss appears at the gateway but not downstream, the problem is in your LAN — Wi-Fi interference, a failing switch port, or a bad cable. If the gateway is clean but 1.1.1.1 shows loss, the problem is on the ISP's side.

Step 2: Use MTR for a Full Path View

MTR (Matt's Traceroute) combines ping and traceroute into one tool that shows packet loss at every hop between you and a destination. It is the fastest way to pinpoint exactly where loss starts on the path.

# macOS (install via Homebrew first: brew install mtr)
mtr --report --report-cycles 100 1.1.1.1

# Linux
mtr -r -c 100 1.1.1.1

# Windows — WinMTR is the GUI equivalent, free download

Read the output from top to bottom. Loss that appears at one hop and continues on every hop after it is usually real network loss. Loss that appears at a single hop but the hops after it are clean almost always means that router deprioritizes ICMP pings under load — it is not actually dropping your traffic. The loss at your ISP's first or second router is the one that matters most.

Step 3: Isolate the Location

Step 4: Browser-Based and Third-Party Tools

Command-line tools give you the most control, but several browser-based tools are useful for checking packet loss without a terminal. Cloudflare's speed test at speed.cloudflare.com reports packet loss directly. PingPlotter is a Windows/macOS app that graphs loss over time and is particularly useful for documenting intermittent problems — run it for a few hours during the time your connection usually misbehaves, then export the graph before calling your ISP.

Online speed test tools that report packet loss (not just bandwidth) include Waveform's broadband test, which shows packet loss and bufferbloat grades alongside speed. If you need to show your ISP evidence, a 4-hour PingPlotter log with timestamps showing recurring loss spikes is far more compelling than a verbal description of the problem.

Timing Matters: When to Run Your Tests

Packet loss that only appears between 7 and 10 pm points to congestion — your ISP's neighborhood node gets saturated during peak hours. Loss that appears at 3 am when nobody else is online points to a hardware or line problem. Running your tests at the same time of day as the problem, then again during a quiet period, gives you the contrast that separates congestion from equipment failure. Screenshot everything with timestamps visible.

Frequently Asked Questions

Is any packet loss normal?

Technically, brief transient loss of less than 0.1% can occur on any connection without any perceptible effect. Loss above 0.5% during normal, non-congested periods is unusual and worth investigating. The baseline you should hold your ISP to is 0% measured on an Ethernet connection from the modem directly to a laptop, pinging a public IP, during off-peak hours. If you are seeing consistent loss under those conditions, the problem is on their infrastructure.

Does packet loss affect downloads?

Less than you might expect for large file downloads, because TCP detects the lost packet and retransmits it automatically. You lose a small amount of throughput efficiency due to the retransmission overhead, but a download will still complete. Where packet loss is most destructive is real-time traffic — voice calls, video conferencing, and online gaming — because those protocols cannot wait for a retransmission. A lost packet in a voice stream means a gap in audio that cannot be reconstructed.

My ping to 1.1.1.1 shows 2% loss but my gateway ping is fine. Is this an ISP problem?

Very likely. If your router gateway (your home network) shows clean results but a public IP shows loss, the problem is between your router and the internet — which means your modem, the coaxial or fiber cable coming into your home, or your ISP's equipment at the street. Check your modem's signal levels and event log, then contact your ISP with the MTR report showing where the loss appears.

How do I document packet loss to show my ISP?

Run MTR with 100 or more cycles and save the output: on macOS/Linux, run mtr --report -c 200 8.8.8.8 > mtr-report.txt to save directly to a file. Take screenshots of PingPlotter graphs showing the loss spikes with timestamps visible. Run a speed test at the same time and note the date, time, and your connection type (Ethernet directly to modem if possible). ISPs take these much more seriously than verbal descriptions because the data tells them exactly which hop is failing.