check_ping oddities

[Dale Blount]

> >Hi,
> >
> >My check_ping is defined like this:
> >
> >define command{
> >        command_name                    check_ping
> >        command_line                    $USER1$/check_ping -H
> >$HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 6 -t 20
> >}
> >
> >Yet I get output at times like:
> >
> >PING WARNING - Packet loss = 71%, RTA = 89.44 ms
> >(warn is 60%, crit is 80%, so WARNING is correct).
> >
> >and
> >
> >PING WARNING - Packet loss = 25%, RTA = 17.44 ms
> >(warn is 20% and crit is 40%, so WARNING is correct).
> >
> >
> >And now to the question.  How can 71% or 25% be a result when 6 packets
> >are sent?
> >
> >Thanks,
> >
> >Dale
> 
> I've seen this happen on some of our WAN hosts. Near as I can tell,
> check_ping (we use check_icmp, but I saw it happen in the check_ping
> days as well) bases its success rate on the number of replies -- if you
> use 5 packets as your standard, then it waits to hear the response from
> packet #4 before reporting its result. And it sends out packets until it
> gets that specified reply. (I know, I could read the source to get a
> definitive answer...just feeling too lazy at the moment.)
> 
> In my situation, over an 800 ms WAN link, there was usually time to send
> 6 packets while waiting for the result on the 5th, so I'd get packet
> losses of 16% when things were otherwise okay. What's puzzling me in
> your situation is your latency -- what happened to me shouldn't be
> happening to you with those kind of ping times.
> Both of those links are small capacity and latency jumps with usage.

Sometimes they loose 100% if they're full enough.  I'm not concerned
with that now - I'm just curious why the math seems odd.  check_ping
--help says:

-p, --packets=INTEGER
   number of ICMP ECHO packets to send (Default: 5)

so it seems to me that if I change -p to 6, a 25% or 71% would never be
possible unless it sends enough packets to get 6 back, then divides 6 by
that to get a percentage.  In that case, the usage text is wrong.

Dale




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null