How Ping Works: A Complete Guide to Network Latency Testing

If you have ever troubleshot a slow internet connection or a website that will not load, chances are someone told you to "just ping it." The ping command is one of the oldest and most fundamental network diagnostic tools, yet many people use it without truly understanding what happens under the hood.

In this guide, we will break down exactly how ping works at the packet level, explain what the results mean, and show you how to use ping effectively to diagnose real-world network problems.

What Is Ping?

Ping is a network utility that tests whether a specific host is reachable across an IP network. It measures the round-trip time (RTT) for packets sent from your computer to a destination and back. The name "ping" was inspired by sonar technology, where a pulse is sent out and the echo is measured.

The tool was written by Mike Muuss in December 1983 and has been a staple of network diagnostics ever since. Every major operating system ships with a built-in ping command, and you can also use our Ping Tool for browser-based testing without needing a terminal.

How Ping Works at the Packet Level

ICMP: The Protocol Behind Ping

Ping uses the Internet Control Message Protocol (ICMP), which operates at the network layer (Layer 3) of the OSI model. ICMP is not a transport protocol like TCP or UDP. It is a supporting protocol used by network devices to send error messages and operational information.

When you run a ping command, here is exactly what happens:

1. Your computer creates an ICMP Echo Request packet. This packet contains a type field (8 for echo request), a code field (0), a checksum, an identifier, a sequence number, and optional payload data.

1. The packet is wrapped in an IP header with your source IP address and the destination IP address. The IP header's protocol field is set to 1, indicating ICMP.

1. The packet traverses the network. It passes through your local network, your ISP's routers, and potentially dozens of intermediate routers before reaching the destination.

1. The destination host receives the ICMP Echo Request. If the host is up and configured to respond to pings, its network stack processes the request.

1. The destination sends back an ICMP Echo Reply. This reply packet (type 0, code 0) contains the same identifier, sequence number, and payload data from the original request.

1. Your computer receives the reply and calculates the time elapsed between sending the request and receiving the reply. This is the round-trip time (RTT).

Anatomy of a Ping Packet

A typical ICMP Echo Request/Reply packet looks like this:

• IP Header (20 bytes): Version, header length, total length, TTL, protocol (1 = ICMP), source IP, destination IP
• ICMP Header (8 bytes): Type, code, checksum, identifier, sequence number
• Payload (variable): Optional data, often 32 or 56 bytes of padding. The payload is echoed back in the reply, allowing the sender to verify data integrity.

The total default packet size varies by operating system. Windows sends 32 bytes of payload data (60 bytes total with headers), while Linux and macOS send 56 bytes of payload (84 bytes total).

Reading Ping Output

When you run a ping command or use our Ping Tool, you will see output like this:

PING google.com (142.250.80.46): 56 data bytes
64 bytes from 142.250.80.46: icmp_seq=0 ttl=118 time=11.4 ms
64 bytes from 142.250.80.46: icmp_seq=1 ttl=118 time=12.1 ms
64 bytes from 142.250.80.46: icmp_seq=2 ttl=118 time=11.8 ms
64 bytes from 142.250.80.46: icmp_seq=3 ttl=118 time=13.2 ms

--- google.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.4/12.125/13.2/0.660 ms

Let us break down each field:

icmp_seq (Sequence Number)

This is the sequential packet counter starting from 0 or 1. If you see gaps in the sequence numbers, it means packets were lost in transit. Consecutive numbering with no gaps means all packets arrived successfully.

ttl (Time to Live)

TTL is a counter that decrements by 1 at each router hop. It prevents packets from circulating infinitely in case of a routing loop. The initial TTL value depends on the destination operating system:

• Linux: Starts at 64
• Windows: Starts at 128
• Network equipment (Cisco, etc.): Starts at 255

If you receive a reply with TTL=118 and the destination is a Linux server (starting TTL=64), that does not add up. But if it is a server behind a cloud load balancer running on Linux with an initial TTL of 128, then 128 - 118 = 10 hops, which is reasonable. You can verify the hop count using Traceroute.

time (Round-Trip Time)

This is the most important metric. It tells you how long the packet took to travel to the destination and back, measured in milliseconds. Here is a general guide for interpreting RTT:

• < 20 ms: Excellent. Typical for servers on the same continent or nearby regions.
• 20-50 ms: Good. Normal for cross-country connections.
• 50-100 ms: Acceptable. Common for intercontinental connections.
• 100-200 ms: Noticeable lag. May affect real-time applications like video calls and gaming.
• > 200 ms: Poor. Will cause significant delays in interactive applications.

Packet Loss

The summary at the end shows how many packets were sent versus received. Any packet loss above 0% indicates a problem. Here is what different levels of packet loss mean:

• 0%: Network is healthy
• 1-2%: Minor issue, possibly congestion. VoIP calls may have occasional glitches.
• 3-5%: Moderate issue. Video calls will stutter, gaming will lag.
• > 5%: Serious problem. Web pages will load slowly, downloads will fail.
• 100%: Host is unreachable, down, or blocking ICMP

Advanced Ping Techniques

Adjusting Packet Size

You can change the payload size to test how the network handles larger packets. This is useful for finding MTU (Maximum Transmission Unit) issues:

# Linux/macOS - send 1472-byte payload (1500 bytes total = standard MTU)
ping -s 1472 -M do google.com

# Windows
ping -l 1472 -f google.com

If you get "packet too big" or "fragmentation needed" errors, there is an MTU mismatch somewhere along the path. This commonly causes issues with VPN connections and can explain why some websites load partially.

Flood Ping (Linux)

For stress testing a local network (never use this on networks you do not own):

sudo ping -f -c 1000 192.168.1.1

This sends packets as fast as possible and reports statistics at the end. It is useful for identifying intermittent packet loss under load.

Setting TTL

You can limit how far your ping packets travel:

ping -t 5 google.com   # macOS/Linux
ping -i 5 google.com   # Some Linux variants

With a TTL of 5, the packet will be discarded after 5 router hops. This is useful for identifying which segment of the network path has problems, and it is essentially a rudimentary form of what Traceroute does automatically.

Continuous Monitoring

For ongoing monitoring, combine ping with timestamps:

ping -D google.com | tee ping_log.txt

This logs each ping response with a UNIX timestamp, which is invaluable for correlating network issues with other events.

Common Ping Problems and Solutions

"Request Timed Out"

This means no reply was received within the timeout period (usually 1-4 seconds). Possible causes:

• The destination host is down or unreachable
• A firewall is blocking ICMP traffic (very common with cloud servers)
• There is severe packet loss on the network path
• Routing is broken somewhere between you and the destination

Important note: Many servers intentionally block ICMP traffic for security reasons. A failed ping does not necessarily mean the server is down. The website may load fine in a browser even if ping fails. Use our Ping Tool to test from multiple locations and confirm whether the issue is on your end or the server's end.

High Jitter

Jitter is the variation in ping times between packets. If your ping times look like 12ms, 45ms, 11ms, 89ms, 14ms, you have high jitter. This is often caused by:

• Network congestion at peak hours
• WiFi interference
• An overloaded router or switch
• ISP throttling

Jitter is particularly damaging for real-time applications. A consistent 80ms ping is better for gaming and VoIP than a ping that bounces between 10ms and 150ms.

Gradually Increasing Latency

If your ping times start low and steadily climb (11ms, 15ms, 22ms, 38ms, 55ms...), this often indicates a buffer bloat problem on your network or a memory leak in your router's firmware. Try rebooting your router and running the test again.

Ping vs. Other Network Tools

Ping is just one tool in your diagnostic toolkit. Here is when to use alternatives:

• Use Traceroute when you know there is latency but need to find where on the path the delay occurs.
• Use our Speed Test when you need to measure actual throughput (bandwidth), not just latency.
• Use the Port Scanner when ping fails but you suspect the host is actually up (it may just be blocking ICMP while still accepting TCP connections).

Key Takeaways

• Ping uses ICMP Echo Request/Reply packets to measure network round-trip time
• RTT under 50ms is generally good for most applications
• Any packet loss above 0% warrants investigation
• Failed pings do not always mean the host is down, as ICMP may be blocked
• Combine ping with traceroute and speed tests for a complete network picture
• Use our Ping Tool for quick, browser-based testing from multiple locations

Related Articles:

• Traceroute Explained: How to Trace Network Paths Like a Pro
• Internet Speed Optimization: 15 Proven Ways to Get Faster Speeds
• Port Scanning Basics: Finding Open Ports and What They Mean