Bug 43801 - ping summary computed wrongly
ping summary computed wrongly
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: iputils (Show other bugs)
7.0
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Phil Knirsch
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-07 03:10 EDT by Duncan
Modified: 2015-03-04 20:09 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-06-26 09:44:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Duncan 2001-06-07 03:10:18 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

Description of problem:
The routine taking the responses received and giving the minimum, average, 
maximum time and (poorly documented) deviation appears to 
mishandle "unusual" data.

It may have trouble when its reported units change from usec to msec or 
msec to sec.  Last week I observed a ping session whose average time 
reported was lower than its minimum:
64 bytes from piglet.tbo.net (65.194.59.170): icmp_seq=403 ttl=127 
time=41.348 msec
--- piglet.tbo.net ping statistics ---
459156 packets transmitted, 439547 packets received, 4% packet loss
round-trip min/avg/max/mdev = 7.987/3.602/1406225.176/2123.138 ms

Note the very large (23 minute) maximum response time, that icmp_seq has 
wrapped, and that average is lower than minimum.

Today I observed a badly delayed packet reported as having been received 
34 minutes before it was sent.

--- 65.194.59.162 ping statistics ---
27660 packets transmitted, 1097 packets received, 96% packet loss
round-trip min/avg/max/mdev = -2070687.-17/3184.346/1110765.804/70882.629 
ms

Note the large negative value for minimum seconds, and that the number is 
presented with TWO negative signs -- one for each side of the decimal 
point.

How reproducible:
Sometimes

Steps to Reproduce:
1.ping across a very flakey but mostly idle link with plenty of internal 
buffering.  piglet.tbo.net, home.tbo.net, jwdci.com, emphyrio.in-con.com, 
wl-cmike.in-con.com.
2.break the link in some way.  restart an intermediate router, move one of 
the radios out of range, spin an antenna, flood the system with RF noise, 
or wait for any of the above to happen.  this takes about a day.
3.press INTR to terminate your ping session and run the stats routine.
	

Additional info:
Comment 1 Phil Knirsch 2001-06-26 09:44:11 EDT
Tricky... The problem is really how to handle these cases.
I don't necessarily want to change the internal measurement of time differences
to use 64bit instead of 32bit, so the only two sane things to do would be

a) Ignore overflows
b) Use some kind of MAXTIME for overflows and report all packages taking longer
as taking MAXTIME time.

Both approches won't reflect reality though anymore and will certainly lead to
wrong statistics.

If i have time i might really take a long look and see if i can switch internaly
to 64bit. No promises though ;)...

Read ya, Phil
Comment 2 Phil Knirsch 2001-06-28 09:01:25 EDT
OK, was actually easier than i thought it would be. Fixed it in rawhide, should
appear real soon now(tm).

Read ya, Phil

PS: You might still be able to trigger an overflow of mdev, but this is not
fixable at all. And after all, the most important things are min, max and avg,
right? ;-)

Note You need to log in before you can comment on or make changes to this bug.