Bug 11138 - Bad time reported from ping on SMP kernel 2.2.14-6.0.1smp
Bad time reported from ping on SMP kernel 2.2.14-6.0.1smp
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: netkit-base (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Crutcher Dunnavant
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-04-30 21:58 EDT by jason
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
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: ---


Attachments (Terms of Use)

  None (edit)
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

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