How to show failed ping?

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.

Going partially off the answer by EvgEnZh, but with my own version:

ping -O -q 8.8.8.8

That makes it print a message when a reply takes too long or never comes back (-O) and suppresses messages for when they do come back (-q). The result is that you only get output when packets go missing. This can make finding intermittent problems much easier by making it so you don't have to sift through a pile of "it worked" messages for the few places it broke.

Maybe ping -f is suitable for you. From ping manual:

-f

Flood ping. For every ECHO_REQUEST sent a period ''.'' is printed, while for ever ECHO_REPLY received a backspace is printed. This provides a rapid display of how many packets are being dropped. If interval is not given, it sets interval to zero and outputs packets as fast as they come back or one hundred times per second, whichever is more. Only the super-user may use this option with zero interval.

For 1 echo_request every second it would look like ping -i 1 -f 8.8.8.8