How Ping Works: ICMP Echo Request and Reply
Ping operates using ICMP (Internet Control Message Protocol), specifically ICMP Echo Request (type 8) and ICMP Echo Reply (type 0) messages. The mechanism is straightforward:
- Your machine sends an ICMP Echo Request packet to the target host, with a sequence number and a timestamp embedded in the payload.
- If the target host is reachable and not filtering ICMP, it responds with an ICMP Echo Reply containing the same sequence number.
- Your machine records the round-trip time — the time between sending the request and receiving the reply.
- This is repeated for each ping probe (typically 4 probes on Windows, continuous until interrupted on Linux/macOS by default).
YOUR MACHINE TARGET HOST
───────────── ───────────
ICMP Echo Request ──────────► receives request
(seq=1, timestamp)
◄────────── ICMP Echo Reply
(seq=1, same timestamp)
Time elapsed = RTT (round-trip time)
What ping does NOT do:
- It does not test TCP or UDP connectivity — ICMP is a separate protocol layer
- It does not test whether a service (web server, database, API) is responding — only whether the host responds to ICMP
- It does not show the path packets take — that's traceroute's job
- It does not measure one-way latency — the RTT includes both outbound and return path latency combined
A host that doesn't respond to ping is not necessarily down. Many firewalls, servers, and cloud instances block ICMP entirely for security or policy reasons. A non-response to ping is an indication, not a conclusion.
Reading Ping Output: Every Field Explained
Linux / macOS output
$ ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=12.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=11.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=12.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=23.8 ms ← spike
64 bytes from 8.8.8.8: icmp_seq=5 ttl=118 time=12.2 ms
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 11.9/14.5/23.8/4.6 ms
Field by field:
-
64 bytes— the size of the ICMP reply packet received. Standard ping sends 56 bytes of data; with the 8-byte ICMP header the reply is 64 bytes. Unusual sizes may indicate the remote host is returning truncated responses. -
icmp_seq=N— the sequence number of this probe. Gaps in sequence numbers (e.g., seq=1, seq=2, seq=4 — seq=3 missing) indicate lost packets. Out-of-order sequence numbers indicate reordering on the network path. -
ttl=118— the TTL (Time To Live) value in the reply packet. This is one of the most informative fields — explained in detail in the next section. -
time=12.4 ms— the round-trip time for this specific probe in milliseconds. This is the core measurement.
Summary statistics:
0% packet loss— fraction of probes that received no replyrtt min/avg/max/mdev— minimum, average, maximum, and mean deviation (a measure of jitter) across all probes. Themdevvalue is particularly useful: low mdev indicates stable latency; high mdev indicates inconsistent latency (jitter).
Windows output
C:\> ping 8.8.8.8
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=13ms TTL=118
Reply from 8.8.8.8: bytes=32 time=12ms TTL=118
Reply from 8.8.8.8: bytes=32 time=13ms TTL=118
Reply from 8.8.8.8: bytes=32 time=12ms TTL=118
Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 13ms, Average = 12ms
Windows uses 32 bytes of data by default (versus 56 on Linux/macOS) and reports TTL in capitals. Windows ping doesn't report mdev/jitter — use -t flag for continuous pinging and observe the time values manually.
What Latency Numbers Actually Mean
Round-trip time (RTT) is primarily determined by physical distance and the speed of light through the transmission medium. Electrical signals travel at roughly 200,000 km/s through fiber optic cable — meaning a transatlantic round trip (London to New York and back, ~11,000 km) has a theoretical minimum of ~55ms. Real-world latency is higher due to routing overhead, queuing at intermediate nodes, and processing time at the destination.
Latency benchmarks:
| RTT Range | Typical Cause | User Experience |
|---|---|---|
| < 1 ms | Same LAN, loopback | Effectively instantaneous |
| 1–10 ms | Same city / regional data centre | Imperceptible for most applications |
| 10–30 ms | Same country / continental | Excellent for all applications including gaming |
| 30–80 ms | Intercontinental (e.g., US to Europe) | Good; slight delay perceptible in real-time voice |
| 80–150 ms | Intercontinental with suboptimal routing | Acceptable; noticeable in VoIP and gaming |
| 150–300 ms | Very long distance or congested path | Noticeable delays; problematic for gaming/VoIP |
| > 300 ms | Satellite, severe congestion, or routing anomaly | Significant impact on interactive applications |
High absolute latency is not always a problem — a 120ms RTT to a server on another continent is expected and normal. The question is whether the latency is appropriate for the geographic distance and routing path. A 120ms ping to a server in the same city, or one that should be <30ms, is a problem.
ℹ️ Tip: Check the RTT against the expected geographic distance. Use our Traceroute tool alongside ping to see the routing path and identify where latency is being added.
What the TTL Value Tells You
The TTL (Time To Live) field in the IP header is a hop counter initialised by the sending host, decremented by 1 at every router, and used to prevent packets from circulating indefinitely. When TTL reaches 0, the router discards the packet and sends an ICMP Time Exceeded message back to the sender. Traceroute exploits this mechanism — ping simply reports the TTL of the reply.
The TTL in ping output is the TTL of the REPLY packet — set by the remote host when it sends the Echo Reply, and decremented by each router on the return path to you. It is not the TTL of your outbound packet.
Inferring hop count from TTL
Most operating systems initialise TTL at one of three values: 64 (Linux, macOS), 128 (Windows), or 255 (Cisco routers, some BSD systems). The TTL you receive minus the starting TTL gives the number of hops consumed.
Received TTL = 118
Likely starting TTL = 128 (Windows host)
Hops consumed = 128 - 118 = 10 hops
Received TTL = 54
Likely starting TTL = 64 (Linux host)
Hops consumed = 64 - 54 = 10 hops
Received TTL = 245
Likely starting TTL = 255 (network device)
Hops consumed = 255 - 245 = 10 hops
A TTL that is exactly 64, 128, or 255 suggests the host is on the same network segment — zero hops consumed. A very low TTL (e.g., TTL=1 or TTL=2) suggests the path is very long or the starting TTL was already low.
TTL changes between probes: If the TTL value changes between ping probes to the same host, the network is performing per-packet load balancing — different probes are taking different paths with different hop counts. This is normal in large networks with ECMP (Equal-Cost Multi-Path) routing but can complicate traceroute interpretation.
Packet Loss: What It Means and What Causes It
Packet loss occurs when an ICMP Echo Request or its corresponding Reply is dropped somewhere in the network path, resulting in a ping probe with no response. It appears in output as a missing icmp_seq line and contributes to the loss percentage in the summary.
Not all "packet loss" is true packet loss
The most important caveat in interpreting ping loss: ICMP is low-priority traffic on most networks. Many routers and firewalls are configured to rate-limit, deprioritise, or silently drop ICMP packets when under load, as a traffic management policy — not because the network path is broken.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=12.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=11.9 ms
← seq=3 missing (dropped)
64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=12.2 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=118 time=12.1 ms
If you see intermittent single packet loss (1 in 20, 1 in 50) with otherwise stable latency, the most likely cause is ICMP rate limiting at an intermediate router or firewall — not actual packet loss on the data path. TCP traffic to the same destination may be completely unaffected.
True packet loss is characterised by:
- Consistent loss (not random single packets)
- Loss that correlates with high latency on surrounding probes
- Loss that persists when tested from multiple sources
- Application-level symptoms: TCP retransmissions, connection drops, slow downloads
Causes of genuine packet loss
- Link congestion: A network link operating at or near capacity drops packets when buffers overflow. Congestion-related loss usually correlates with high latency on the same probes.
- Physical layer issues: Faulty cable, degraded fiber, bad transceiver, or radio interference (for wireless links) cause bit errors that result in packet drops at the receiving end.
- Router buffer overflows: Heavy traffic bursts can momentarily overflow router queues, causing burst loss — several consecutive probe drops followed by recovery.
- Firewall rules: A firewall blocking ICMP entirely produces 100% loss on ping while TCP/UDP traffic flows normally.
Distinguishing ICMP filtering from real packet loss
Run both a ping and a TCP connectivity test to the same host:
# Ping (ICMP)
ping -c 20 target.example.com
# TCP connectivity check (doesn't use ICMP)
curl -o /dev/null -s -w "%{time_total}\n" https://target.example.com/
# Or for a non-HTTP service:
nc -zv target.example.com 443
If ping shows loss but TCP connections succeed reliably, ICMP filtering is the explanation. If both show problems, the packet loss is real.
Jitter: Why Consistency Matters as Much as Latency
Jitter is the variation in round-trip time between consecutive ping probes — captured in the mdev (mean deviation) field in Linux/macOS output. A path with 20ms average RTT and 1ms mdev is far more stable than a path with 20ms average RTT and 15ms mdev.
; Stable, low-jitter path (good for VoIP, gaming, video conferencing)
rtt min/avg/max/mdev = 11.9/12.1/12.4/0.2 ms
; ^^^
; 0.2ms jitter — very stable
; High-jitter path (problematic for real-time applications)
rtt min/avg/max/mdev = 11.9/18.3/67.2/18.1 ms
; ^^^^
; 18.1ms jitter — very unstable
Why jitter matters: Real-time applications (VoIP, video conferencing, online gaming) are sensitive to latency variation, not just absolute latency. A VoIP codec that expects packets every 20ms cannot easily compensate for packets arriving at 12ms, then 67ms, then 14ms intervals. Jitter buffers absorb some variation, but high jitter degrades audio quality, causes video stuttering, and increases gaming input lag.
Causes of jitter:
- Queue depth variation: Routers that are occasionally (but not constantly) congested add variable queuing delay
- Path switching: ECMP routing that switches between paths of different latency
- Wireless interference: Wi-Fi packet retransmissions add variable delay
- CPU scheduling on virtual machines: Hypervisor scheduling can cause VM-level jitter independent of network conditions
Common Ping Patterns and Their Diagnosis
| Pattern | Likely Cause | Next Step |
|---|---|---|
| All probes timeout (100% loss) | Host down, ICMP fully blocked, or routing failure | Try TCP test; run traceroute to find where path fails |
| Low loss (1–5%), stable latency | ICMP rate limiting at intermediate router | Run TCP test to confirm application traffic is unaffected |
| Consistent loss (>5%), high latency | Congested link or physical layer issue | Run traceroute to identify the problem hop |
| Stable low latency, zero loss | Healthy path | No action needed |
| Stable latency, high mdev | Jitter from congestion or ECMP path variation | Check for congested intermediate hops with traceroute |
| Sudden latency spike (one probe) | Transient queue burst | Usually ignorable if isolated; watch for recurrence |
| Gradually increasing latency | Progressive congestion | Investigate at the network or ISP level |
| TTL varies between probes | Per-packet ECMP load balancing | Expected on large networks; may complicate traceroute |
| Very low TTL received (< 10) | Long path, or low starting TTL | Run traceroute to count actual hops |
| RTT much higher than geographic distance suggests | Suboptimal routing, routing anomaly | Run traceroute and check AS path |
Ping Across Operating Systems
Linux / macOS
# Ping with 10 probes
ping -c 10 example.com
# Ping with custom interval (0.2 seconds between probes)
ping -i 0.2 -c 20 example.com
# Ping with larger packet size (useful for MTU testing)
ping -s 1472 example.com
# Flood ping (requires root — 1000 probes as fast as possible)
sudo ping -f -c 1000 example.com
Windows
# Standard 4-probe ping
ping example.com
# Continuous ping (Ctrl+C to stop)
ping -t example.com
# Specific number of probes
ping -n 20 example.com
# Larger packet size
ping -l 1400 example.com
Key differences
- Default probe count: Linux/macOS ping continuously until interrupted (
-c Nto limit); Windows sends 4 probes by default (-tfor continuous) - Default packet size: Linux uses 56 bytes data (64 bytes total); Windows uses 32 bytes
- Output format: Windows rounds RTT to whole milliseconds; Linux/macOS shows decimal precision
- Statistics: Linux/macOS shows
mdev(jitter); Windows only shows min/avg/max
For running a ping test from an external network vantage point — useful for determining whether a connectivity issue is local to your network or visible from outside — use our Ping Test tool.
Ping vs. Traceroute: When to Use Each
| Question | Use Ping | Use Traceroute |
|---|---|---|
| Is the host reachable at all? | ✓ | |
| What is the round-trip latency? | ✓ | |
| Is there packet loss on the path? | ✓ | |
| Is the latency stable (jitter)? | ✓ | |
| Where on the path is the problem? | ✓ | |
| Which networks does traffic traverse? | ✓ | |
| Is an intermediate hop adding latency? | ✓ | |
| Is there asymmetric routing? | ✓ |
The practical workflow:
Start with ping. If the host is reachable and latency is within expected range with low packet loss, the network path is healthy — no further investigation needed. If ping shows high latency, significant packet loss, or high jitter, run traceroute to identify which hop in the path is responsible.
# Step 1: Quick reachability and latency check
ping -c 10 target.example.com
# Step 2: If problems found, identify which hop
traceroute target.example.com # Linux/macOS
tracert target.example.com # Windows
# Step 3: Identify the network operator at the problem hop
# Look up the hop's IP in ASN lookup to identify whose network it's in
For the full guide on reading traceroute output — including what asterisks mean, how to identify the problem hop, and how to interpret latency jumps between hops — see our How to Read a Traceroute guide. For understanding the AS-level network path that traceroute reveals — which autonomous systems your traffic traverses and why — see our ASN and BGP Routing guide.
Frequently Asked Questions
Q: If ping shows 0% packet loss, does that mean my network is healthy?
It means ICMP packets are getting through without loss, which is a good sign — but it doesn't guarantee that other protocols are working correctly. A misconfigured firewall could allow ICMP while blocking TCP port 443, for instance. Ping is a useful first check, not a comprehensive network health assessment. If you're troubleshooting a specific application issue, test connectivity using the same protocol the application uses (TCP to the specific port).
Q: Why does my ping to a nearby server show higher latency than to a farther server?
Latency isn't purely determined by physical distance — it depends on the routing path. A "nearby" server may be routed through distant transit networks due to BGP routing decisions or peering relationships. A more distant server may have a more direct route. This is also why ping from one location shows very different results than ping from another location to the same target. Use our Traceroute tool to see the actual routing path.
Q: What does "Request timeout for icmp_seq" mean?
The probe was sent but no reply was received within the timeout period (typically 2 seconds on Linux/macOS, 4 seconds on Windows). This could mean the host is unreachable, ICMP is blocked at the destination or an intermediate firewall, the return path is broken, or the probe was simply dropped due to congestion or ICMP rate limiting.
Q: Can I ping a hostname instead of an IP address?
Yes — ping hostname.example.com will first resolve the hostname to an IP via DNS, then send ICMP probes to that IP. If the ping fails, it's worth running the DNS lookup separately (dig hostname.example.com) to confirm whether DNS resolution succeeded — a DNS failure and a network failure look the same in ping output.
Q: What is a good ping for gaming?
For competitive online gaming, RTT below 30ms to the game server is ideal. Up to 60ms is acceptable for most games. Above 100ms introduces noticeable input lag. Above 150ms makes fast-paced games significantly less responsive. Jitter matters as much as absolute latency — stable 50ms RTT with <2ms mdev is preferable to 30ms average RTT with 20ms mdev, because the variance in the latter creates unpredictable lag spikes.
Q: Why does my ping get worse at certain times of day?
Time-of-day latency variation typically indicates congestion on a shared network link — your ISP's backbone, a peering point, or a transit provider link operating near capacity during peak usage hours (typically evenings in residential networks). This is a network capacity issue, not something configurable at the host level. Document the timing and run traceroutes during high-latency periods to identify which hop adds latency during peak hours — this is useful evidence for ISP escalation.
Next Steps
Run a ping test from an external vantage point using our Ping Test tool — it shows how your host responds to ICMP from outside your local network, which is useful for confirming that connectivity issues are visible externally and not local to your machine or network.
When ping reveals a problem — high latency, packet loss, or jitter — follow up with our Traceroute tool to identify which specific hop in the path is responsible. The combination of ping (to characterise the problem) and traceroute (to locate it) covers the core of most network path diagnostics.
For understanding the network operator context of each hop in a traceroute — identifying which ASN and company is responsible for each segment of the path — see our ASN and BGP Routing guide.
Browse all network guides on DNSnexus for related topics.