What Ping Measures (and What It Does Not)
The ping command sends ICMP echo request packets to a destination and reports how long each round trip takes. It measures:
- Latency (RTT): the round-trip time in milliseconds for each packet
- Jitter: variation between successive RTT values — high jitter causes choppy calls even with low average latency
- Packet loss: percentage of packets that never return — even 1% loss causes noticeable problems in gaming and calls
Ping does not measure download speed, upload speed, or bandwidth capacity. A 500 Mbps connection with 200ms ping and 2% packet loss will feel terrible for gaming and calls despite the fast speed test result.
Reading the Output Line by Line
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=57 time=12.4 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=13.1 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=11.8 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=89.3 ms ← spike
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=12.2 ms
Request timeout for icmp_seq 5 ← loss
64 bytes from 1.1.1.1: icmp_seq=6 ttl=57 time=12.9 ms
--- 1.1.1.1 ping statistics ---
7 packets transmitted, 6 packets received, 14.3% packet loss
round-trip min/avg/max/stddev = 11.8/25.3/89.3/27.1 ms| Field | What It Means | Good Value | Problem Threshold |
|---|---|---|---|
| time= (each line) | Round-trip latency for that packet | <20ms for home internet | >100ms consistently, or large spikes |
| icmp_seq | Packet sequence number — gaps mean lost packets | No gaps | Any missing sequence numbers |
| ttl= | Hops remaining; decreases by 1 per router | 40–128 typical | TTL=1 means destination is one hop away (ping the gateway) |
| min/avg/max/stddev | Summary: minimum, average, maximum RTT, and standard deviation | Low avg, low stddev | High stddev (jitter) even with acceptable avg |
| packet loss % | Fraction of packets that never returned | 0% | >0.5% for calls; >1% for gaming; >5% severe |
Diagnostic Sequence: Start Local, Work Outward
Run these in order — stop and fix when you find the problem, then retest:
- Ping your router gateway (usually 192.168.1.1 or 192.168.0.1):
ping 192.168.1.1
If this is unstable: the problem is on your local network (Wi-Fi, Ethernet cable, router load). Fix locally before testing further. - Ping a public IP without DNS:
ping 1.1.1.1
If gateway is stable but this spikes: problem is between your router and the internet — modem, ISP line, or ISP congestion. - Ping a hostname:
ping google.com
If IP ping is stable but hostname ping spikes: the problem is DNS resolution latency — test your DNS server directly. - Ping the specific destination (game server, office VPN endpoint, video call server)
If only this target has issues: the problem is routing between you and that specific network, not your ISP generally.
Useful Ping Commands by Platform
| Platform | Command | Notes |
|---|---|---|
| macOS / Linux | ping -c 100 1.1.1.1 | Sends 100 packets; shows statistics at end |
| Windows | ping -n 100 1.1.1.1 | -n sets packet count; default is only 4 |
| macOS / Linux (continuous) | ping 1.1.1.1 | Runs until Ctrl+C; Ctrl+C shows summary |
| Windows (continuous) | ping -t 1.1.1.1 | Runs until Ctrl+C |
| macOS (flood ping, root) | sudo ping -f -c 1000 192.168.1.1 | Fast flood ping to stress-test local path |
| Any platform | ping -s 1400 1.1.1.1 (macOS/Linux) | Test with larger packets to catch MTU issues |
Interpreting Specific Patterns
| Pattern | Likely Cause | Next Step |
|---|---|---|
| Gateway ping spikes to 300–500ms intermittently | Wi-Fi interference or congestion; router CPU overload; bufferbloat | Test via Ethernet; check router CPU; enable SQM/QoS |
| Gateway stable (<5ms), internet spikes | ISP modem/line issue; ISP aggregation congestion | Run traceroute to identify which hop spikes; compare morning vs evening |
| All targets show consistent packet loss | Faulty Ethernet cable; bad Wi-Fi signal; modem line error | Check cable; measure Wi-Fi dBm; inspect modem signal levels in admin page |
| Packet loss to internet but not to gateway | ISP line or modem issue | Bypass router and test modem directly; call ISP with evidence |
| Only one destination shows loss or spikes | Route or peering problem between your ISP and that network | Test same destination via VPN; run MTR to identify where loss begins |
| Latency doubles or triples in evenings | ISP network congestion during peak hours | Document with timestamps; contact ISP; consider switching providers |
| Request timeout for all packets | Destination blocks ICMP; or complete connectivity loss | Try pinging your router first; use traceroute instead for connectivity testing |
Latency Benchmarks by Use Case
| Use Case | Target RTT | Acceptable RTT | Problematic RTT |
|---|---|---|---|
| Competitive online gaming (FPS, racing) | <20ms | 20–40ms | >60ms |
| Casual gaming / MMO | <50ms | 50–80ms | >100ms |
| Video calls (Zoom, Teams, Meet) | <50ms | 50–100ms | >150ms |
| Web browsing | <50ms | 50–100ms | >200ms |
| Streaming video | <100ms | 100–200ms | Not sensitive to RTT alone |
| Remote desktop (RDP, VNC) | <30ms | 30–60ms | >80ms |
When High Latency Is Not Your Problem
Some destinations have high latency by design or geography:
- Pinging a server in another country will show 80–150ms — that is physics, not a problem
- Some routers and servers deprioritize ICMP (ping) packets — you may see high ping latency to a hop in traceroute while actual traffic flows fine
- Satellite internet (Starlink: 20–60ms; geostationary: 500–700ms) has latency floors that cannot be reduced regardless of plan tier
- A "Request timeout" during traceroute to a middle hop does not mean the path is broken — many routers silently drop TTL-expired packets
Documenting the Pattern for ISP Complaints
ISPs respond better to evidence than to descriptions. Before calling:
- Run
ping -c 500 1.1.1.1and save the output — 500 packets over ~8 minutes shows a real pattern - Run tests during the problem period and during a good period — the contrast is the evidence
- Record the date, time, and what you were doing (streaming, gaming, working from home) when the issue occurred
- Test from Ethernet, not Wi-Fi, to remove the local network as a variable the ISP can point to
- Include modem signal levels (visible in the modem admin page at 192.168.100.1 for most cable modems) — downstream power should be -7 to +7 dBmV; upstream 38–48 dBmV
Frequently Asked Questions
How many ping tests should I run?
Run at least 100 packets per test (ping -c 100) to get meaningful statistics. Four packets (the Windows default) is not enough to detect intermittent packet loss or jitter patterns. For ISP complaint documentation, 500 packets over ~8 minutes provides strong evidence. Run tests both during the problem period and during a known-good period — the difference between the two is the proof.
Should I test on Wi-Fi or Ethernet?
Test on Ethernet first to establish the baseline — this removes Wi-Fi as a variable and shows the best-case connection quality from your router. Then test on Wi-Fi from the problem location. If Ethernet is clean but Wi-Fi is not, the fix is signal-related (router placement, interference, AP coverage). If Ethernet is also bad, the problem is the router, modem, or ISP line.
Why does my ping look fine but gaming still lags?
Several reasons: you may be pinging a different server than the game uses; the game server may use UDP while ping uses ICMP (different queuing priorities on some routers); bufferbloat may spike latency only under load (not visible in a simple idle ping); or the game server itself may be overloaded rather than your connection being the problem. For gaming diagnosis, run a loaded ping test (ping while a speed test is running) to check for bufferbloat.
When should I call the ISP about ping problems?
Contact your ISP when: Ethernet ping tests (not Wi-Fi) to 1.1.1.1 consistently show over 5% packet loss or latency spikes above 200ms; when the problem is reproducible at the same time each day (suggesting network congestion); or when your modem's signal levels are outside acceptable ranges. Document the problem with saved ping output, timestamps, and Ethernet connection confirmation before calling — this significantly reduces time spent with first-line support.