Is the host there, and how fast does it answer?
ping is the only command named after a sound a submarine makes — and it has been diagnosing dead networks since 1983, long before most of the internet existed.
ping sends ICMP echo request packets to a host and waits for echo replies, printing the round-trip time of each. It answers two questions at once: is the host reachable, and how fast does it respond? The name comes from sonar — a submarine sends out a 'ping' and listens for the echo to locate something. Your computer does the same thing over the network.
When a website won't load, a server is unreachable, or a service is flaky, ping is the first diagnostic. It tells you whether the problem is the network (no replies, packet loss) or something higher up (replies fine, but the app is down). It also gives you a raw latency number in milliseconds — the single most useful figure for judging whether a connection is healthy or crawling.
ping -c 4 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=9.40 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=10.1 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=12.4 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=9.13 ms --- 1.1.1.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 9.125/10.255/12.367/1.272 ms
-c 4 stops after four packets. The summary line is the real payoff: 0% packet loss and an average round-trip of ~10 ms means this link is healthy. (Verified live on this box.)
ping -c 3 kmail.at
PING kmail.at (80.108.50.214) 56(84) bytes of data. 64 bytes from 80-108-50-214.cable.dynamic.surfer.at (80.108.50.214): icmp_seq=1 ttl=64 time=2.40 ms 64 bytes from 80-108-50-214.cable.dynamic.surfer.at (80.108.50.214): icmp_seq=2 ttl=64 time=3.71 ms 64 bytes from 80-108-50-214.cable.dynamic.surfer.at (80.108.50.214): icmp_seq=3 ttl=64 time=1.86 ms --- kmail.at ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1003ms rtt min/avg/max/mdev = 1.860/2.656/3.711/0.777 ms
Pinging a hostname resolves it to an IP first. Note the ttl=64 here vs ttl=57 for 1.1.1.1 — the TTL tells you roughly how many router hops the packet survived. (Verified live.)
ping -c 5 -i 0.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=11.2 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=10.8 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=11.5 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=10.9 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=118 time=11.1 ms --- 8.8.8.8 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 10.8/11.1/11.5/0.2 ms
-i 0.5 sends a packet every half second instead of the default one second, so you get a faster latency sample. The tiny mdev (0.2 ms) means the connection is very stable — no jitter.
| Flag | Meaning |
|---|---|
-c N | send exactly N packets, then stop (essential for scripts and one-off checks) |
-i SEC | wait SEC seconds between packets (default 1; use 0.2-0.5 for a faster sample) |
-t TTL | set the IP time-to-live — the value that decrements at each router hop |
-s SIZE | set the packet payload size in bytes (default 56; useful for MTU testing) |
-W SEC | timeout in seconds to wait for a reply before giving up |
-q | quiet — print only the summary, not every reply line |
-4 / -6 | force IPv4 or IPv6 (handy when a hostname resolves to the wrong family) |
ping was written by Mike Muuss in December 1983 at the US Army Ballistic Research Laboratory. He knocked it out in about an hour to debug a network problem, and named it after the sonar sound a submarine emits to locate objects — the echo reply is the 'return ping'. It spread through the Unix world almost immediately and has shipped with every Unix-like system since.
Every IP packet carries a time-to-live field that decrements by one at each router hop, and drops the packet when it hits zero. ping exposes that value in its output, which is why the ttl=57 for 1.1.1.1 vs ttl=64 for a local host tells you the packet crossed more routers. The same mechanism is what traceroute exploits: it sends packets with TTL 1, then 2, then 3, and reads the 'time exceeded' errors to map the whole path.