Red Hat Bugzilla – Bug 11138
Bad time reported from ping on SMP kernel 2.2.14-6.0.1smp
Last modified: 2008-05-01 11:37:55 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
FWIW, this is almost certainly an SMP kernel problem, as ping does little more
than a subtraction of (current - previous) based on gettimeofday(2).
This appears to be a kernel problem, since running a uniprocessor kernel
on the same hardware "solves" the ping time skew problem.
This is a precision assumption error in the ping app
I thought this one got fixed ?
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.
Time skew got fixed by Ingo in later kernels and also ping got fixed for an
accuracy handling bug that could cause this