When Windows' ping says "Request timed out.", it is not an error per se. Microsoft arbitrarily chose a timeout of 4 seconds, after which they assume "failure" and report it. If you were to ping anything from Mars, that's a guaranteed false alarm, but even on Earth RTT (round-trip time) over 4s is perfectly possible. The timeout is configurable with a
/w <millisec> switch.
On Linux, ping utility does not assume that timeout is a failure and doesn't wait for reply. Normally, it prints all received replies immediately and as-is, including "late" ones, out-of-order ones, duplicates and and conflicting responses (e.g. a valid reply after "Destination unreachable").
Having said that, there usually are options to see when a reply isn't received for too long. Even on my Android phone, stock ping utility supports these 2 options:
-D prints a timestamp before every message, makes gaps easier to spot.
-O prints a message when reply is not received before sending next ping, and this is more or less what was asked. The "timeout" is fixed to ping interval (
However, these options do not seem to be supported everywhere (e.g. Debian Wheezy lacks them as far as I know, while Jessie has them.
busybox ping does not support them yet).
Here is an example output I managed to get (unimportant ping replies skipped):
u0_a93@NX505J:/ $ ping -D -O 184.108.40.206
PING 220.127.116.11 (18.104.22.168) 56(84) bytes of data.
[1440545014.805478] 64 bytes from 22.214.171.124: icmp_seq=1 ttl=244 time=116 ms
[1440545142.995443] 64 bytes from 126.96.36.199: icmp_seq=129 ttl=244 time=110 ms
[1440545144.885601] no answer yet for icmp_seq=130
[1440545145.455485] 64 bytes from 188.8.131.52: icmp_seq=131 ttl=244 time=568 ms
[1440545145.455780] 64 bytes from 184.108.40.206: icmp_seq=130 ttl=244 time=1569 ms
[1440545146.005850] 64 bytes from 220.127.116.11: icmp_seq=132 ttl=244 time=119 ms
[1440545254.055962] 64 bytes from 18.104.22.168: icmp_seq=240 ttl=244 time=115 ms
--- 22.214.171.124 ping statistics ---
240 packets transmitted, 240 received, 0% packet loss, time 239250ms
rtt min/avg/max/mdev = 109.062/138.757/1569.620/101.608 ms, pipe 2
Note how #130 is first reported "missing", then received after #131, and finally packet loss is reported to be zero. Windows' ping would never give such a result: it waits until a reply or a timeout and only then sends next ping, ignoring any late or non-first replies.