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-base	Assignee:	Crutcher Dunnavant <crutcher>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.2	CC:	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 23:06:52 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description jason 2000-05-01 01:58:11 UTC

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 20:04:59 UTC

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 21:24:59 UTC

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 15:43:17 UTC

This is a precision assumption error in the ping app
I thought this one got fixed ?

Comment 4 Chris DeYoung 2000-08-30 15:04:59 UTC

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 23:06:52 UTC

Time skew got fixed by Ingo in later kernels and also ping got fixed for an
accuracy handling bug that could cause this