Bug 11138

Summary: Bad time reported from ping on SMP kernel 2.2.14-6.0.1smp
Product: [Retired] Red Hat Linux Reporter: jason
Component: netkit-baseAssignee: Crutcher Dunnavant <crutcher>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2CC: cdeyoung
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-12-14 18:06:52 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description jason 2000-04-30 21:58:11 EDT
On Dell Poweredge XE-5100-2 servers with dual-Pentium 100Mhz processors we
noticed that ping occasionally responds back with bad times.  We have
tried this with a 3COM PCI 905B ethernet card and a Digital DS21140
ethernet card to see if it was a hardware problem.  Also, the problem
corrected itself in uni-processor mode. Here is a sample:

PING 192.168.0.10 (192.168.0.10) from 192.168.0.20 : 56(84) bytes of data.
64 bytes from 192.168.0.10: icmp_seq=0 ttl=32 time=11.1 ms
64 bytes from 192.168.0.10: icmp_seq=1 ttl=32 time=4388.4 ms
64 bytes from 192.168.0.10: icmp_seq=2 ttl=32 time=9032.1 ms
64 bytes from 192.168.0.10: icmp_seq=3 ttl=32 time=-26216.-5 ms
64 bytes from 192.168.0.10: icmp_seq=4 ttl=32 time=18334.8 ms
64 bytes from 192.168.0.10: icmp_seq=5 ttl=32 time=-17922.-6 ms
64 bytes from 192.168.0.10: icmp_seq=6 ttl=32 time=-10357.0 ms
64 bytes from 192.168.0.10: icmp_seq=7 ttl=32 time=-5714.-8 ms

This problem also occured with 2.2.14-5.0smp kernel on Redhat 6.2.

We also notice that as it was ping-ing, it would pause for
Comment 1 Jeff Johnson 2000-05-08 16:04:59 EDT
FWIW, this is almost certainly an SMP kernel problem, as ping does little more
than a subtraction of (current - previous) based on gettimeofday(2).
Comment 2 Jeff Johnson 2000-05-08 17:24:59 EDT
This appears to be a kernel problem, since running a uniprocessor kernel
on the same hardware "solves" the ping time skew problem.

Changing component...
Comment 3 Alan Cox 2000-08-22 11:43:17 EDT
This is a precision assumption error in the ping app
I thought this one got fixed ? 
Comment 4 Chris DeYoung 2000-08-30 11:04:59 EDT
I been experiencing this same problem on 2.2.14-5smp. I was able to work around
this by removing everything in /etc/resolv.conf. I'm not sure if ping is not
resolving things properly or the kernel is not handling it correctly. 
If left for a long time the pings will eventually return acceptable times
although after some time (maybe arp or routing cache flushes) the pings go back
to thousands of ms.
Comment 5 Alan Cox 2002-12-14 18:06:52 EST
Time skew got fixed by Ingo in later kernels and also ping got fixed for an
accuracy handling bug that could cause this