relation between -t and -p options in "none default" mode. -t prossesed not as expected #32

Open
zalexua opened this Issue Nov 11, 2012 · 4 comments

Projects

None yet

2 participants

@zalexua
zalexua commented Nov 11, 2012

If I got it correctly - in "none default" mode ("batch mode" next) fping will receive and will process ECHO replies for previous requests as success till it executes last request disregarding that replies have been received much later that specified in -t option.

For example ping to a site with long distance.

# time ./fping -c1 -t50 zabbix.jp

zabbix.jp : xmt/rcv/%loss = 1/0/100%

real    0m0.078s
user    0m0.000s
sys 0m0.000s

# time ./fping -c2 -t50 zabbix.jp
zabbix.jp : [0], 84 bytes, 175 ms (175 avg, 0% loss)

zabbix.jp : xmt/rcv/%loss = 2/1/50%, min/avg/max = 175/175/175

real    0m1.079s
user    0m0.000s
sys 0m0.000s


# time ./fping -c5 -t50 zabbix.jp
zabbix.jp : [0], 84 bytes, 174 ms (174 avg, 0% loss)
zabbix.jp : [1], 84 bytes, 174 ms (174 avg, 0% loss)
zabbix.jp : [2], 84 bytes, 174 ms (174 avg, 0% loss)
zabbix.jp : [3], 84 bytes, 174 ms (174 avg, 0% loss)

zabbix.jp : xmt/rcv/%loss = 5/4/20%, min/avg/max = 174/174/174

real    0m4.082s
user    0m0.000s
sys 0m0.000s

As we see above one last response always lost because fping finished its work before last response came.

And with none default -p option, so two last responses are lost while first response has been catched:

# time ./fping -c3 -t50 -p50 zabbix.jp
zabbix.jp : [0], 84 bytes, 174 ms (174 avg, 66% loss)

zabbix.jp : xmt/rcv/%loss = 3/1/66%, min/avg/max = 174/174/174

real    0m0.178s
user    0m0.000s
sys 0m0.000s


I'd consider this as a fping's bug because it's nasty inconsistency which depends on number of requests sent and it's absolutely not clear.

I believe that timeouts in none default "batch" mode should work as expected disregarding on number of requests.
So in all my examples I should get 100% lost responses.

@schweikert schweikert closed this Jan 16, 2017
@zalexua
zalexua commented Jan 16, 2017

I've tested the 3.16-rc1
I cannot confirm that it has changed described behavior in any way.

# time ./fping -c3 -t50 -p100 zabbix.jp
zabbix.jp : [0], 84 bytes, 238 ms (238 avg, 66% loss)

zabbix.jp : xmt/rcv/%loss = 3/1/66%, min/avg/max = 238/238/238

real    0m0.659s
user    0m0.000s
sys     0m0.000s

# ./fping -v
./fping: Version 3.16-rc1
./fping: comments to david@schweikert.ch

Don't want to be annoying, but this "issue" in NOT fixed.

@schweikert
Owner

So, you mean that responses received after the timeout specified in -t should be discarded?

@schweikert schweikert reopened this Jan 16, 2017
@schweikert
Owner

I can understand the argument, but I wonder if the current behavior is possibly also preferred by others and possibly relied upon.

@zalexua
zalexua commented Jan 16, 2017 edited

Yes, it's an arguable thing - should be discarded or not.
My own opinion - the responses should be discarded.
I.e. options -t (timeout) and -c (count of packets) should not "depend each other" regarding received result.

I belong to a Zabbix team (NMS application), where fping (with "not default" mode, i.e. with -C option) is used to perform icmp ping checks.
Most of fping's options may be controlled in Zabbix, so for example someone wants to change parameters to use not default number of packets (-c) while leave the same default timeout (-t) - and in such case final result may get different.
https://www.zabbix.com/documentation/3.2/manual/config/items/itemtypes/simple_checks#icmp_pings

As for "backward compatibility" - I'm not sure how to resolve that, but current behavior is illogical for me, so I consider it as a bug, which is "to be fixed" instead of keep things "as is" because someone maybe relies it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment