Ping Result Analyzer
Parse pasted ping output for packet loss and min/avg/max latency, with interpretation.
Paste the raw output of a ping run and this tool extracts the packets sent/received, packet loss percentage, and the min/avg/max round-trip time (RTT), then grades it ok / warning / danger at a glance. It recognizes both the Windows form (Packets: Sent = 4, Received = 4) and the Linux/macOS form (4 packets transmitted, 4 received).
You no longer have to read the numbers by hand to tell whether there is loss or high latency, which makes it handy for first-pass network triage. To turn repeated latency samples into statistics, use the latency percentile calculator; to grade a server's speed, see the response time tiers.
Formats you can paste
You only need the summary lines of a ping run. Either of these two formats is recognized.
- Linux / macOS:
4 packets transmitted, 4 received, 0% packet lossandrtt min/avg/max/mdev = 1.2/3.4/5.6/0.7 ms(orround-trip min/avg/max = ...) - Windows:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)andMinimum = 1ms, Maximum = 3ms, Average = 2ms
How it grades
The status uses the rules below, taking whichever of average latency or loss is worse.
- OK: 0% loss and average RTT below 100ms
- Warning: loss up to 10%, or average RTT 100–250ms
- Danger: loss above 10%, or average RTT above 250ms
High latency points to path congestion or physical distance; packet loss points to a wireless hop, overload, or an MTU problem.
RTT reference by distance and link type
To judge whether an average RTT is good, compare it against the “physically possible minimum” rather than an absolute number. Light travels through fiber at roughly 2/3 of its vacuum speed (~200km/ms), and the signal makes a round trip, so a 1,000km path costs about 10ms at best. The ranges below are typical when measuring from East Asia.
| Path / link | Typical avg RTT | Note |
|---|---|---|
Same LAN / 127.0.0.1 | < 1ms | Loopback is effectively 0ms, often shown as 0ms |
| Home router → wired PC | 1–3ms | Over Wi-Fi this jumps to 5–30ms and fluctuates |
| Same country (e.g. coast to coast in a small region) | 5–20ms | Domestic CDN / game servers |
| Nearby region (e.g. Japan, Hong Kong) | 30–60ms | Close overseas region |
| US West Coast | 120–160ms | Trans-Pacific cable; over 100ms is normal here |
| Europe / LTE·5G mobile | 200–300ms / 30–80ms | Mobile adds latency and jitter at the wireless first hop |
So if you ping a US server and see an average of 150ms, that is perfectly normal for the distance even though this tool flags it as “warning”. The grade is a generic baseline—always weigh it against how far away the target actually is.
Reading a real example
Suppose you paste this Linux output.
10 packets transmitted, 9 received, 10% packet loss, time 9012msrtt min/avg/max/mdev = 28.4/41.7/210.3/52.1 ms
The tool reads 10% loss and an average of 41.7ms. The average alone looks fine, but 10% loss trips the threshold, so the overall verdict is “warning”. The bigger clue is hidden: withmin 28.4 the max 210.3 is more than 7× higher and mdev 52.1is very large. A healthy-looking average is masking individual packets that spike badly—a classic fingerprint of bufferbloat (congestion) or a flaky wireless hop. Never trust the average in isolation; always read max and mdev alongside it.
Common pitfall
- Calling loss after only 4 pings: Windows
pingdefaults to just 4 probes, so a single drop shows as25% loss. Loss percentage is meaningless on tiny samples—paste a run with plenty of probes, e.g.ping -n 50(Windows) orping -c 50(Linux/macOS). - Relaxing because the average is low: even with a low average RTT, a large max/mdev (jitter) makes video calls and games stutter. Perceived quality is often driven by the variation, not the mean.