The minimum values in -Q summaries are always 0

[jafaber]

I use a script to pipe the output of fping (almost) straight into rrdtool. This works great, except that the min value is always 0.

cat hosts | fping -A -u -l -p200 -Q1
[17:26:59]
172.31.128.1  : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.00/9.59/13.7
192.168.101.1 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.00/1.10/1.24
192.168.1.44  : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.00/0.17/0.20
[17:27:00]
172.31.128.1  : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.00/9.62/12.4
192.168.101.1 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.00/1.03/1.11
192.168.1.44  : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.00/0.17/0.19
[17:27:01]
172.31.128.1  : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.00/9.47/11.8
192.168.101.1 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.00/1.05/1.09
192.168.1.44  : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.00/0.20/0.24

The alternative way is to let fping quit every second and use that summary, which does include the correct minimum:

cat ../etc/pinger.hosts | fping -A -u -p200 -c5
172.31.128.1  : xmt/rcv/%loss = 5/5/0%, min/avg/max = 11.6/14.4/17.0
192.168.101.1 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 1.09/1.17/1.40
192.168.1.44  : xmt/rcv/%loss = 5/5/0%, min/avg/max = 0.17/1.19/5.20

The first solution seems much nicer to me: not starting new processes every second and letting fping handle all the timing related issues.

[PawelDefee]

Rather strange - could this be a compiler issue (bug) ? I cannot reproduce this problem. Also, looking at fping.c, all the variables for the minimum value calculation are initialized and set correctly..

[jafaber]

Thank you for looking into this.

I have several older different Linux distributions that run old versions of fping and show this 0 minimum quirk. The latest fping version I could find that doesn't work was 3.0.

However, I just tried again on my fully updated Fedora 21 (fping 3.1) and there it seems to work fine. So whatever it was, it seems to have been fixed.

The way I just tested it again on different systems:

echo -e "8.8.8.8\n8.8.4.4" | fping -A -u -l -p200 -Q1

Thank you!

[PawelDefee]

Right, I was testing the latest (3.10). But indeed it looks like there was a bug in 3.0 that was fixed in some subsequent release:

3.0 version setting of minimum ping:
if( this_reply < h->min_reply_i ) h->min_reply_i = this_reply;

was changed to this in some later revision:
if( !h->min_reply_i || this_reply < h->min_reply_i ) h->min_reply_i = this_reply;

So that fixes it :)

[jafaber]

Cool. Classical bug :)

Thank you for following up on this. Good to know that it's fixed now, this
should make my rrdtool script that much easier and more efficient.

Jannes

On 18 May 2015 at 16:20, Pawel Defée notifications@github.com wrote:

Right, I was testing the latest (3.10). But indeed it looks like there was
a bug in 3.0 that was fixed in some subsequent release:

3.0 version setting of minimum ping:
if( this_reply < h->min_reply_i ) h->min_reply_i = this_reply;

was changed to this in some later revision:
if( !h->min_reply_i || this_reply < h->min_reply_i ) h->min_reply_i =
this_reply;

So that fixes it :)

—
Reply to this email directly or view it on GitHub
#74 (comment).

[schweikert]

Thank you for the analysis. I close the issue then.