Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Bad time reported from ping on SMP kernel 2.2.14-6.0.1smp|
|Product:||[Retired] Red Hat Linux||Reporter:||jason|
|Component:||netkit-base||Assignee:||Crutcher Dunnavant <crutcher>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2002-12-14 18:06:52 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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