Calculating packet loss from ping?

Question

I've got an ESXi VM that does command execution on some 700~ devices on our network. It's using Expect, and due to the age of this equipment they have periods of poor performance. These two don't mix well - as the Expect script will have to wait really long to get output before proceeding.

To try to avoid this, our team decided that a ping test should be issued before connecting to the device. If there's packet loss, we'll come back to it later.

The issue we're having is that our ping test looks like this:

loss=`ping -i 0.2 -w 2 $1 | grep "packet loss" | awk '{print $6}'`
loss=${loss%?}

echo "$loss"

10 pings over two seconds - but we get a LOT of 9% Packet Loss responses. For example we usually have 74/700 tests exit preemptively due to packet loss detection. 39/74 of those report 9%, while the rest report in multiples of 10.

Far as we can tell that doesn't really make sense; there are 10 packets being sent...if one is dropped that should be 10% loss. This has been observed infrequently, but it does happen. Is it possible there's something going on in memory that's causing the number 9 to manifest? If these are legitimate instances of packets being lost then it's big news for us.

Answer 1

There are several ping versions. Some have the -w option. Some accept it but is undocumented. In some versions of ping, this happens:

$ ping -i 0.2 -w 2 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.091 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.091 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.089 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.086 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.088 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.097 ms
64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.091 ms
64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.095 ms
64 bytes from 127.0.0.1: icmp_seq=8 ttl=64 time=0.095 ms
64 bytes from 127.0.0.1: icmp_seq=9 ttl=64 time=0.092 ms
--- 127.0.0.1 ping statistics ---
11 packets transmitted, 10 packets received, 9% packet loss
round-trip min/avg/max/stddev = 0.086/0.091/0.097/0.000 ms

That is: one packet is emitted, the time expire and it is never received back.

Thus: 1 packet of 11 got lost, that's 9% loss.

With those ping versions, adding a -c option should solve the issue:

$ ping -i 0.2 -c 10 -w 5 127.0.0.1 
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.127 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.096 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.088 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.084 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.084 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.093 ms
64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.089 ms
64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.089 ms
64 bytes from 127.0.0.1: icmp_seq=8 ttl=64 time=0.087 ms
64 bytes from 127.0.0.1: icmp_seq=9 ttl=64 time=0.094 ms
--- 127.0.0.1 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.084/0.093/0.127/0.000 ms

That means: try packets each 0.2 sec until 10 packets have been received or until a time limit of 5 seconds has elapsed.