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 (-i
), though.
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 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
[1440545014.805478] 64 bytes from 8.8.8.8: icmp_seq=1 ttl=244 time=116 ms
~~~~~~~~~~
[1440545142.995443] 64 bytes from 8.8.8.8: icmp_seq=129 ttl=244 time=110 ms
[1440545144.885601] no answer yet for icmp_seq=130
[1440545145.455485] 64 bytes from 8.8.8.8: icmp_seq=131 ttl=244 time=568 ms
[1440545145.455780] 64 bytes from 8.8.8.8: icmp_seq=130 ttl=244 time=1569 ms
[1440545146.005850] 64 bytes from 8.8.8.8: icmp_seq=132 ttl=244 time=119 ms
~~~~~~~~~~
[1440545254.055962] 64 bytes from 8.8.8.8: icmp_seq=240 ttl=244 time=115 ms
^C
--- 8.8.8.8 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.
5 packets transmitted, 0 received, 100% packet loss, time 4032ms
(information like that is printed when ping terminates, whether by itself or by Ctrl+C)? Are you looking for separate data about each individual ping?