The practical answer

Ping measures round-trip time for ICMP probes. It is useful for comparing paths and spotting instability, but an unanswered ping does not prove a host is down. Judge repeated destination results alongside the application you are trying to fix.

Understand the four useful signals

  • Latency: time for a probe to travel to the target and a reply to return.
  • Loss: proportion of probes that receive no reply before the timeout.
  • Variation: changing round-trip times, often called jitter informally in troubleshooting.
  • Loaded delay: how those times change during uploads or downloads.

The round-trip value is not a direct one-way measurement. ICMP handling also differs from an application's TCP or UDP traffic. A single fastest result says little about whether a video call is stable.

Run a small, repeatable comparison

# Windows; replace the gateway with your actual router address
ping -n 30 192.168.1.1
ping -n 30 example.com

# macOS / Linux
ping -c 30 example.com

Run one set while the connection is quiet and another while a normal upload or download is active. Repeat on Ethernet if you started on Wi-Fi. Keep the destination, time, packet count, and connection type in your notes. Avoid an endless flood of probes; a modest sample is enough for an initial comparison.

Work through the pattern

Suppose gateway replies vary from 2 to 180 ms on Wi-Fi, but become consistently low over Ethernet. That points toward the wireless segment or its load. If the gateway remains stable while an Internet target's replies rise during an upload, investigate the WAN queue, provider path, or target handling.

If a router ignores every ping but browsing and calls work, its ICMP policy may simply block replies. If 3 of 30 probes fail, the observed sample loss is 10%; repeat before treating that as a stable connection-wide rate. Short tests are noisy, and packets missing from the sample do not reveal exactly where the loss occurred.

Connect the result to the symptom

For calls and games, look for sustained spikes or gaps that line up with the disruption. For slow downloads, also check throughput, server limits, CPU, storage, and competing traffic. Better idle ping does not guarantee higher download speed.

A useful escalation report includes a wired baseline, local gateway results, at least one affected destination, timestamps, and whether the fault appears under load. Intermediate traceroute loss alone is weaker evidence than repeated loss that continues to the destination and coincides with real application failures.

Put it into practice

References & further reading

Protocol standards and official documentation supporting this guide. Device menus and provider policies vary; use the documentation for your equipment when applying a change.