What Is Packet Loss? Measure It Without Misreading Ping

Packet loss means some transmitted packets do not reach their destination. A choppy call can be a symptom, but it is not a diagnosis: high latency, changing delay and application overload can produce similar interruptions. A useful investigation states what traffic was measured, when it was measured and which path was involved.

Why a fast connection can still feel unreliable

Throughput, latency and packet loss describe different things. A connection can transfer a large file quickly yet struggle with an interactive session. Congested queues can discard packets; wireless interference and physical interface errors are other possibilities. Jitter is variation in delay, not another name for loss.

TCP can retransmit missing data, so loss does not automatically leave a downloaded file corrupted. Retransmission instead costs time and can reduce throughput. A voice application has different deadlines: audio arriving too late may be useless even if the network eventually delivers it.

Build a local baseline, then test beyond it

Find the default gateway for your active connection. On Windows, ipconfig displays it. The address below is an example; replace it with your actual gateway before running a bounded test:

ping -n 20 192.168.1.1

On Linux or macOS, use the count option instead:

ping -c 20 192.168.1.1

Repeat against a remote destination you are allowed to test and know normally answers ping. Keep the sample size comparable. Record whether the connection was busy, whether a VPN was involved, and whether you used Wi-Fi or Ethernet. Twenty probes are a starting sample, not proof that an intermittent fault is absent. The Windows ping reference documents its options.

A missing reply is evidence with limits

Imagine a test with 20 requests and 19 replies. The observed unanswered fraction is 5%. That does not identify whether an outbound request, a returning reply or the destination's ICMP handling caused the gap. It also does not establish 5% loss for every application. A gateway may restrict its own replies while continuing to forward traffic.

Compare Ethernet and Wi-Fi under similar conditions. A repeatable wireless-only problem makes the local radio path worth investigating. A clean local test and an affected remote test widen the investigation beyond the LAN, but do not by themselves prove that the Internet provider is at fault. The remote host and return path still matter.

Do not blame the first red MTR row

An intermediate router can rate-limit diagnostic responses without dropping the traffic it forwards. Large loss on that row, followed by clean responses from the destination, is not evidence of equivalent end-to-end loss. Loss that persists downstream deserves investigation, but asymmetric return paths prevent a single report from identifying an exact faulty link. See Cloudflare's explanation of MTR and router response limits.

Before escalating, collect the time window, destination, sent/received counts and the application's symptoms during that window. Inspect relevant firewall logs instead of disabling security software wholesale. After a targeted change, repeat the same comparison under similar load; one successful reply is not a reliable acceptance test.