Something on your network stopped working. Before you open a ticket or call your ISP, you type one command: ping. In two seconds you know if the host is reachable and whether the connection is clean. That's why ping is the first tool every network engineer touches — it's fast, built into every OS, and the output is immediately useful. But there's a lot more in that output than most people read.
TL;DR
- Ping sends ICMP Echo Request packets and measures how long replies take (round-trip time)
- Packet loss percentage = how many requests got no reply
- TTL in ping output = hops remaining when reply arrives (lets you estimate distance)
- mdev / jitter = variation in latency — high jitter hurts video calls and gaming even when average ping is low
- Ping failure doesn't always mean the host is down — many firewalls block ICMP by default
What Is Ping and Why Is It the First Network Tool Everyone Uses?
Ping is a diagnostic tool that sends a small packet to a destination IP address and measures how long it takes to get a response back. That round-trip time — displayed in milliseconds — tells you about network latency. The percentage of packets that don't come back tells you about packet loss. Together, those two numbers describe the health of the path between you and the destination.
It sounds simple, and mostly it is. But there's a lot more going on under the hood, and understanding the details makes you much better at using ping to actually diagnose problems.
What Protocol Does Ping Use?
Ping uses ICMP — the Internet Control Message Protocol. ICMP is a separate protocol from TCP and UDP. While TCP is for reliable data transfer and UDP is for fast, connectionless communication, ICMP is specifically for network diagnostics and error reporting.
When you run ping, your machine sends an ICMP Echo Request message to the target IP. If the target is reachable and not filtering ICMP, it replies with an ICMP Echo Reply. Ping measures the time between sending the request and receiving the reply.
ICMP is also used for other things besides ping. When a router can't forward a packet because the TTL expired, it sends an ICMP Time Exceeded message back. When a port is unreachable, a host sends ICMP Port Unreachable. These ICMP messages are what traceroute uses to map the path between two points.
Reading Ping Output
A basic ping on Linux looks like this:
$ ping google.comPING google.com (142.250.80.46) 56(84) bytes of data.64 bytes from 142.250.80.46: icmp_seq=1 ttl=117 time=12.4 ms64 bytes from 142.250.80.46: icmp_seq=2 ttl=117 time=11.9 ms64 bytes from 142.250.80.46: icmp_seq=3 ttl=117 time=12.1 ms
Here's what each field means:
- 64 bytes — the size of the ICMP reply. The default ping packet is 56 bytes of data plus 8 bytes of ICMP header = 64 bytes total.
- icmp_seq — sequence number. If you see gaps (seq 1, 2, 4 — no 3), that's packet loss.
- ttl — Time to Live. Each router the packet passes through decrements TTL by 1. The value you see in ping is the TTL of the reply when it arrives at your machine. Common starting TTLs are 64 (Linux/Mac), 128 (Windows), 255 (Cisco). If a server starts with TTL 64 and you see TTL 117, it passed through approximately 47 hops on the return path.
- time — the round-trip time in milliseconds. This is the latency.
At the end of a ping session (Ctrl+C to stop), you get a summary:
--- google.com ping statistics ---10 packets transmitted, 10 received, 0% packet loss, time 9011msrtt min/avg/max/mdev = 11.2/12.1/13.8/0.7 ms
The mdev is mean deviation — essentially jitter. A low mdev means consistent latency. A high mdev means the latency is fluctuating, which affects real-time applications like video calls and gaming.
What Do Ping Numbers Actually Mean?
| Latency (ms) | Connection Type | Practical Experience |
|---|---|---|
| Under 5 ms | Local network or nearby data center | Imperceptible lag in all applications |
| 5–20 ms | Good broadband, nearby server | Excellent for gaming, video calls, everything |
| 20–50 ms | Standard broadband, regional server | Good for most things, competitive gaming might notice |
| 50–100 ms | Cross-continent, or congested network | Noticeable in real-time gaming; fine for web browsing |
| 100–200 ms | Intercontinental or satellite | Voice calls OK, gaming becomes frustrating |
| Over 200 ms | Satellite, heavy congestion, routing issues | Video calls degrade, gaming nearly unplayable |
Ping Options You Should Know
Linux / Mac
ping -c 10 host— send exactly 10 packets then stopping -i 0.2 host— send a packet every 0.2 seconds instead of 1 (faster testing)ping -s 1400 host— use a larger packet size (useful for MTU testing)ping -W 2 host— wait only 2 seconds for each reply before counting as lostping -M do -s 1400 host— send with Don't Fragment bit set for MTU path discoveryping6 host— ping over IPv6
Windows
ping -t host— ping continuously until you manually stop it (Ctrl+C)ping -n 20 host— send exactly 20 packetsping -l 1400 host— use a custom packet sizeping -f -l 1472 host— send with Don't Fragment flag for MTU testingping -4 hostorping -6 host— force IPv4 or IPv6
What Ping Doesn't Tell You
Ping measures the round-trip time and packet loss for ICMP packets specifically. This is useful but limited:
- ICMP can be deprioritized or filtered. Many routers handle ICMP at lower priority than regular traffic. A router that's busy might drop ICMP packets while still forwarding TCP/UDP traffic fine. High ping doesn't always mean your web traffic is slow.
- Ping doesn't tell you about the path. You know the destination is reachable and the latency — but you don't know which routers it's passing through. Use traceroute for that.
- Ping doesn't test application connectivity. A server can respond to ICMP perfectly but have a crashed web server or a full database. Ping can't tell you if the application is working.
- Some hosts block ICMP by default. Windows Firewall blocks ICMP Echo Requests from external sources by default. So a ping failure doesn't always mean a host is down.
Using Ping for MTU Testing
One underused application of ping is MTU path discovery. If packets larger than the path MTU get fragmented or dropped (common with VPN tunnels and some cloud connections), you'll see intermittent failures for larger transfers while small packets work fine.
On Linux, use ping -M do -s 1400 host to send a 1400-byte packet with the Don't Fragment bit set. If you get a response, the path supports 1400-byte packets. Increase the size until it fails. The largest size that works + 28 bytes (8-byte ICMP header + 20-byte IP header) is approximately your path MTU.
Ping vs Traceroute: When to Use Each
Ping tells you if a host is reachable and what the latency is. Traceroute tells you the path traffic takes to reach the host and where latency is being added along the way.
Use ping first to confirm reachability. If the latency is higher than expected or there's packet loss, use traceroute to find where the problem starts. High latency at hop 8 but not hop 7 means hop 8 is the bottleneck. Packet loss that starts at a specific hop and continues through the rest of the path points to that hop as the problem.
Common Ping Troubleshooting Scenarios
Scenario 1: Ping fails, but web browsing works
The destination is filtering ICMP. This is normal for many servers and cloud VMs. ICMP blocking is a common firewall configuration, especially on public-facing servers to reduce attack surface and prevent ICMP-based flooding.
Scenario 2: Ping works, but web browsing is slow
Latency and packet loss look fine, but TCP connections are slow. Check for MTU issues — large packets might be getting fragmented. Also check DNS resolution time: ping google.com triggers a DNS lookup, and slow DNS adds latency that shows up before the ICMP measurement but isn't part of it.
Scenario 3: Intermittent packet loss
Run a longer ping (ping -c 200 host) to get a statistically meaningful packet loss percentage. 0.1–1% loss on a consumer connection is normal. Over 1% consistently indicates a real problem — usually a flaky cable, a congested link, or a wireless interference issue.
Scenario 4: High jitter (high mdev)
Consistent latency with high variation (say, 12ms to 85ms on different packets) indicates network instability. Common causes: shared wireless medium, buffer bloat, congested ISP link, or a VPN with inconsistent tunneling overhead.
Ping and Your IP Address
Every ping reveals your IP address to the destination — because the destination has to know where to send the reply. If you ping a server you control, the server logs will show your real IP as the source of the ICMP Echo Requests. This is true even if you're using a VPN — but with a VPN, the logged IP will be the VPN server's IP, not yours.
When troubleshooting connectivity issues, checking your current IP address before and after network changes is a useful step. If your IP changed unexpectedly, that can explain why something that worked before stopped working (IP-based access controls, session cookies tied to IP, etc.). See exactly what IP address the internet currently sees for your connection — and your location, ISP, and ASN.