Packet loss: how to find it and make your ISP actually fix it

The short version

Packet loss is when some of the little pieces of data your internet sends simply never arrive. Calls drop words, games freeze, and pages stall — even on a fast plan. The fix is to find out where the loss happens: in your own home (which you can fix) or out on your provider's lines (which they must fix, and you can prove it).

What's actually happening

Your internet sends data as thousands of small packages called packets. Normally nearly all of them arrive. Think of mailing 100 letters and having 2 vanish — the other side has to ask you to resend, and that resend takes time and causes stutters.

A little loss (under about 1 percent) is normal and usually invisible. More than that, and you'll feel it: dropouts, lag, and stalls. Loss can come from a bad cable in your house, a failing modem, or a problem on the provider's wires outside.

Why it matters to you

• Video calls freeze and voices cut out.
• Games lag, rubber-band, or disconnect.
• Downloads stall and restart; pages hang halfway.
• Unlike slow speed, packet loss often means something is actually broken — and finding where is how you get it fixed.

How to measure it

On Windows 11

1. Click Start, type cmd, open Command Prompt.
2. Type ping -n 100 1.1.1.1 and press Enter.
3. Wait for it to finish and read the Lost = line. "Lost = 0 (0% loss)" is perfect.

On a Mac

1. Open Terminal (Applications → Utilities, or search with Spotlight).
2. Type ping -c 100 1.1.1.1 and press Enter.
3. Read the packet loss percentage in the summary at the end.

Any steady loss above about 1-2 percent is worth chasing down.

How to fix it

Step 1: Rule out your own home first

Do this before calling your provider — they'll ask, and often it's a cheap fix on your side:

1. Restart the modem and router (unplug 30 seconds; modem first, then router).
2. Test with a cable. Plug a computer straight into the router and re-run the ping test. If Wi-Fi loses packets but the cable doesn't, your problem is Wi-Fi, not the line.
3. Swap the network cable. A bent, pinched, or cheap cable causes loss. Try a known-good Cat6 cable (see gear below).
4. Check the coax (cable internet): make sure the screw-on cable to the modem is finger-tight, and remove any splitters you don't need — each splitter weakens the signal.

Step 2: Check your modem's signal (cable internet)

Your modem has a hidden status page that shows if the signal is healthy:

1. In a browser, go to 192.168.100.1 (works for most cable modems).
2. Find the "status" or "connection" page and look for these:
   • Downstream power: best between about -7 and +7 (the page may show dBmV).
   • Downstream SNR (signal quality): higher is better; above 35 is healthy.
   • Upstream power: best under about 50.
   • Uncorrectable errors: a number that keeps climbing fast is a red flag.
3. Write these down. If they're out of range, that's strong evidence of a line or modem problem.

An old or failing modem is a common cause. A current DOCSIS 3.1 modem on your provider's approved list may fix it outright (see gear).

Step 3: Find where the loss is (both platforms)

• Windows: type pathping 1.1.1.1 and wait a few minutes. It tests each "hop" between you and the internet and shows where packets drop.
• Mac: there's no built-in equivalent, but traceroute 1.1.1.1 shows the hops, and a free tool called mtr gives a loss report.

If loss starts at the very first hop (your own router) it's in your home. If it starts a few hops out, it's your provider's — and now you have proof.

How to make your ISP fix it

1. Collect your evidence: ping loss percentage, modem signal readings, and the pathping/traceroute showing where loss begins.
2. Call and say plainly: "I have measured X percent packet loss. My in-home wiring is ruled out. My modem signal shows [readings]. The loss begins at hop [number], which is on your network."
3. Ask them to check for a line or node fault and to send a technician if needed. Specific numbers are far harder to brush off than "my internet is slow."

How to check it worked

Re-run the 100-packet ping. You want 0 percent (or very close) loss, steady, both on Wi-Fi and wired. Re-check the modem signal readings to confirm they're back in range.

If your result was already good

If your packet loss was zero or near it, nothing is wrong — no changes or purchases needed. Keep your cables in good shape, don't add unnecessary coax splitters, and keep your modem and router firmware updated. Re-test if dropouts ever start, since loss is often the first sign of a developing line fault.

Want to go further?

The Advanced version covers reading mtr/pathping correctly, DOCSIS error counters (correctable vs uncorrectable FEC), distinguishing ICMP-deprioritization from real loss, and building an airtight ISP case.

Is this your problem?

These all come back to packet loss, and this guide shows you how to find it and prove it:

• "How to fix packet loss in Valorant, CS2, Roblox, Apex Legends, Xbox Cloud Gaming or GeForce Now." Disappearing enemies and hit-registration problems are loss, not low bandwidth.
• "Packet loss Spectrum at night," "Xfinity packet loss," "Starlink packet loss." Loss that appears only in the evening usually means an overloaded ISP segment, and a time-stamped log is what gets a technician dispatched.
• "Internet keeps dropping for a few seconds." Brief, repeated dropouts are short bursts of 100% loss; the Watch mode captures when they happen so you can show your ISP.

Summary

Packet loss is the ratio of packets sent to packets that never arrive (or arrive too corrupt to use). The diagnostic goal is localization: in-home LAN/Wi-Fi, the CPE, the access link/L1, or the provider's path. Use sustained ping for a loss rate, mtr/pathping for per-hop localization, and the modem's DOCSIS counters for physical-layer root cause — then escalate with data, not adjectives.

What packet loss actually is

Packets are dropped when a buffer overflows (congestion), when a link's bit errors exceed what forward error correction can repair (L1 impairment), or when a device deliberately discards them (policing, rate limits, failing hardware). The user-visible effect depends on transport: TCP retransmits (adding latency and throughput collapse via congestion control), while UDP real-time media simply loses the data — a dropout. Even ~1% loss can halve TCP throughput on a high-latency path because congestion control reacts hard to loss.

Measure a loss rate

• Sustained ping for a rate: ping -n 200 1.1.1.1 (Windows) / ping -c 200 1.1.1.1 (macOS/Linux). Use an IP to exclude DNS. 200+ samples gives a meaningful percentage; a handful of pings does not.
• Test wired and wireless separately. Loss present on Wi-Fi but absent on Ethernet is airtime/RF loss (retransmit exhaustion, weak RSSI, interference), not an access-link fault.
• Pick a stable, nearby anycast target (1.1.1.1, 8.8.8.8). Don't measure loss to a host that rate-limits ICMP — see gotchas.

Localize it per hop

• Windows: pathping -n 1.1.1.1 — sends 100 queries/hop (minutes to run) and reports per-hop loss. Read the This Node/Link loss columns.
• macOS/Linux: install mtr (mtr -rwzbc 200 1.1.1.1). It's the single best tool: continuous per-hop loss and latency. macOS traceroute alone shows the path but not a loss rate.
• Interpretation is the hard part. Loss shown at a single mid-path hop that does not persist to later hops is almost always that router deprioritizing ICMP to its own control plane — not real loss. Real loss appears at a hop and persists through every subsequent hop. Judge by the final-destination column and by continuity, never by one intermediate node.
• First-hop loss (your gateway) = in-home: Wi-Fi, a bad LAN cable/port, or a failing router. Loss that first appears at the ISP's access/aggregation hops and persists = provider-side.

Physical-layer root cause (DOCSIS)

Open the modem status page (commonly 192.168.100.1) and read the RF/signal table. Rules of thumb (your ISP's spec wins):

• Downstream power: roughly -7 to +7 dBmV ideal; beyond ±10 is trouble.
• Downstream SNR/MER: 35 dB+ for 256-QAM; under ~30 dB causes correctable→uncorrectable errors.
• Upstream power: typically under ~50 dBmV; very high upstream power means the modem is shouting over a lossy return path — a classic loss cause.
• FEC counters: watch correctable vs uncorrectable codewords. Uncorrectables are the ones that become packet loss. A rate of uncorrectables rising over minutes, especially across multiple channels, indicates ingress noise/plant fault. Cisco's CMTS guidance treats low upstream SNR as the primary modem-side diagnostic and flags values under ~25 dB as unreliable.
• Confirm expected channel bonding and modulation; dropping to QAM16/32 or losing bonded channels signals a noise fault.

For DSL/VDSL, read SNR margin (want ~6 dB+), attenuation, CRC errors, and errored seconds. For fiber (GPON/XGS-PON), loss is rarely L1 at the ONT; suspect the router, a LAN cable/SFP, or upstream.

Rule out your own L1/L2

• Swap the patch cable and move ports. A marginal cable or dirty jack throws CRC errors and loss; verify with a cable tester (see gear) or by checking interface error counters (netsh interface ipv4 show ipstats, switch port counters, or ifconfig/ethtool -S).
• Remove unnecessary coax splitters — each adds ~3.5 dB loss and a reflection point. Verify F-connectors are torqued and weatherproof.
• Wi-Fi: check retransmit/RSSI; relocate, change channel/width, or wire the endpoint.

Build the ISP case

Package: (1) a 200+ sample loss rate wired at the gateway, (2) a timestamped mtr/pathping showing the hop where loss begins and persists, (3) modem RF readings out of spec with rising uncorrectable FEC, taken at several times including peak evening. State it as: measured X% loss, in-home ruled out (wired, cable swapped, splitters removed), modem signal shows [values], loss originates at [hop/your network]. This converts a vague ticket into a plant/node dispatch. Ask specifically for a line/node check and, if RF is out of spec, a truck roll.

Edge cases & gotchas

• ICMP rate-limiting at a router makes ping/pathping overstate loss to that node; trust end-to-end loss and persistence across hops.
• Loss only under load is congestion/buffer overflow — often your own under-provisioned uplink; SQM plus a slightly lower shaper rate fixes it without an ISP visit.
• Intermittent/weather-correlated loss points to water ingress in outdoor coax or a corroded connector/tap — note the correlation for the technician.
• CGNAT/double NAT doesn't cause loss but can complicate reproducing it for certain apps.
• Wi-Fi "loss" is frequently late-arriving frames the app discards (jitter), not true drops; wired testing disambiguates.

TCP vs UDP symptoms

The same loss rate presents differently by transport, which helps localize it. On TCP (web, file transfer, streaming), loss triggers retransmission and a congestion-window cut; you see throughput that sawtooths or collapses and pages that stall then resume. On UDP real-time (VoIP, most game netcode), lost packets are simply gone — you get dropouts and rubber-banding with no retransmit. If downloads are fine but calls break up, suspect jitter/late-frame discard rather than true loss; if both degrade together, it's more likely genuine drops on the path. Correlating the two narrows the cause before you touch a single setting.

Document over time, not once

Plant faults are frequently intermittent and load- or weather-dependent, so a single clean test does not exonerate the ISP. Run a scheduled capture — a looping ping to a log file, or mtr --report every 15 minutes — across a full day including the evening peak, and timestamp the modem's FEC uncorrectable counters at the start and end of the window so you can show a rate of errors, not a snapshot. A rising uncorrectable rate that tracks your loss, concentrated in peak hours or during rain, is the kind of evidence that moves a ticket from "reboot your modem" to a dispatched line technician.