kmail.at
contact
kmail.at
contact

elsewhere

EnglishEN
← learning

networking · difficulty ◆

ping — test network reachability and latency

Round-trip time, packet loss and an exit code — three numbers that separate a dead host from a dead service, and from a script that cannot even reach it.

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.

AI-generated draft · reviewed and editedThis text was generated with AI as a first draft, then reviewed and edited by the author, who holds editorial responsibility for it.

2026-09-09 · 5 min read

$ ping

What it does

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.

Why it matters

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.

What the summary line and the exit code tell you

The last two lines are the ones to read. 'N packets transmitted, N received, 0% packet loss' answers the reachability question; 'rtt min/avg/max/mdev' answers the latency one, and mdev — mean deviation — is the number people skip. mdev is jitter: on a quiet link it sits in the decimals, and when a single probe stalls well behind the others it jumps into the tens while the average still looks respectable. That is the shape of a link that is not healthy, and it is invisible in the average alone. `-q` prints only this summary, which is what belongs in a log. `-w deadline` caps the whole run — give up after ten seconds, whatever is still outstanding — while `-W timeout` is the per-reply wait that only applies when nothing has answered at all. Then there is the exit code: 0 when at least one reply arrived, 1 when none did, 2 for any other error such as a name that will not resolve, and also 1 when you pass `-c` together with `-w` and the deadline arrives with fewer replies than the count you asked for. That makes `ping -c1 -W1 -q "$host" >/dev/null || echo "$host is not answering"` a complete health check — and it is why the exit code is worth reading instead of the text.

Example

$ 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.

$ ping -c 1 -W 1 1.1.1.1 > /dev/null; echo "reachable=$?"
ping -c 1 -W 1 192.0.2.1 > /dev/null; echo "silent=$?"
ping -c 1 -W 1 nosuchhost.invalid > /dev/null; echo "bogus=$?"
reachable=0
silent=1
ping: nosuchhost.invalid: Name or service not known
bogus=2

Three exit codes, all three measured here. 192.0.2.1 is TEST-NET-1, a documentation range nothing routes, so the probe goes out and no reply ever comes back: exit 1. A name that will not resolve is a usage error rather than a network result: exit 2. The manual also gives 1 when -c and -w are both set and the deadline arrives before the count is reached. So 'nothing answered in time' and 'ping could not even start' stay distinguishable, which is what makes $? worth checking in a monitoring script.

$ ping -c 1 -M do -s 1472 -W 2 1.1.1.1
ping -c 1 -M do -s 1473 -W 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
1480 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=12.7 ms

--- 1.1.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 12.706/12.706/12.706/0.000 ms

PING 1.1.1.1 (1.1.1.1) 1473(1501) bytes of data.
ping: local error: message too long, mtu=1500

--- 1.1.1.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

The other job ping does that people forget: it measures the path MTU. `-s 1472` asks for a 1472-byte payload, which with the 8-byte ICMP header and the 20-byte IP header is exactly 1500 bytes on the wire — and it answers. One byte more and the kernel itself refuses, printing the MTU it knows about: 'message too long, mtu=1500'. `-M do` is the flag that stops the kernel fragmenting the probe for you, which is what turns this into a real test rather than a packet that quietly gets split. Nothing in that output needed root, and nothing in it is specific to 1.1.1.1 — run it against your own gateway to find the smallest MTU a tunnel or a VPN has left you with.

$ ping -A -c 4 -w 3 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=10.7 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=8.84 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=8.80 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=8.78 ms

--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 31ms
rtt min/avg/max/mdev = 8.776/9.264/10.652/0.801 ms, ipg/ewma 10.337/10.040 ms

`-A` is adaptive mode: the interval between probes shrinks to match the round-trip time, so at most one probe is in flight instead of one per second by the clock. Four packets took 31 ms of wall clock rather than three seconds, and the summary gains a column (`ipg/ewma`) that reports the measured inter-packet gap and an exponentially weighted average. On a fast link this is nearly flood mode — the manual warns it is 'essentially equivalent to flood mode' when RTTs are low — which makes it the quickest way to get a usable latency sample without sending a burst big enough to upset anything.

Common flags

-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)
-A
adaptive ping — the interval shrinks to the round-trip time so at most one probe is in flight; the default interval is 2 ms. Adds ipg/ewma (measured gap, weighted average) to the summary.
-w DEADLINE
stop after DEADLINE seconds however many packets are still outstanding — the flag to use in scripts, where -W alone can leave ping waiting on a lost reply.

History

Origin

ping was written by Mike Muuss in December 1983 at the US Army Ballistic Research Laboratory. He had hit odd behaviour on the lab's IP network, and the result, in his own words, was 'a little thousand-line hack that I wrote in an evening'. The first build did not work: the kernel had no raw ICMP socket support, so he added that as well and had things running before sunrise. He named it after the sound a sonar makes, which is where the echo reply's nickname comes from. Berkeley took the kernel patch and the source back, and it has shipped with every Unix-like system since.

The TTL trick

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.

Fun facts

Pros & cons

pros

  • + Instant, universal, and present on every Unix-like system — no install needed
  • + Gives you a raw latency number in milliseconds, the single most useful network health metric
  • + Packet loss percentage in the summary is a fast, reliable signal for a flaky link

cons

  • − Many hosts and firewalls block ICMP, so no reply does not always mean down
  • − Only tests ICMP reachability — it cannot tell you if a web server or database is actually working
  • − Default behavior runs forever, which trips up people who forget -c

Takeaways

  1. 1Always add -c N so ping stops on its own — `ping -c 4 host`
  2. 2Read the summary line: 0% packet loss and a low average rtt means the link is healthy
  3. 3Compare ttl values to estimate how many router hops a packet crossed
  4. 4Use -i 0.5 for a faster latency sample when you need more data points quickly
  5. 5If ping fails, still try curl or a TCP connection — ICMP is often blocked by design

Related commands

← all learning