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. Changing component...
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