Bug 137114 - Ping RTT clock resolution problem on x86_64
Ping RTT clock resolution problem on x86_64
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-25 16:35 EDT by Federico Sacerdoti
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:15:26 EDT
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 Federico Sacerdoti 2004-10-25 16:35:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.5 (KHTML, like Gecko) Safari/125.9

Description of problem:
Hello,

I am a developer from the Rocks project in San Diego. We are noticing a problem with the clock resolution for TCP round trip times that only emerges on AMD Opteron systems. The bug is characterized as follows:

The issue is that the clock resolution is only 10ms: ie any rtt value between 0-10ms is reported as 0.00ms.

--On Opteron (bug)--
root@www root]# ping google.com
PING google.com (216.239.37.99) 56(84) bytes of data.
64 bytes from 216.239.37.99: icmp_seq=0 ttl=238 time=89.9 ms
64 bytes from 216.239.37.99: icmp_seq=1 ttl=238 time=79.9 ms
64 bytes from 216.239.37.99: icmp_seq=2 ttl=236 time=79.9 ms

[root@www root]# ping nbc.com
PING nbc.com (63.241.60.70) 56(84) bytes of data.
64 bytes from nbc.com (63.241.60.70): icmp_seq=0 ttl=53 time=0.000 ms
64 bytes from nbc.com (63.241.60.70): icmp_seq=1 ttl=53 time=0.000 ms


--On Other systems (normal)--
[root@rocks-43 root]# ping google.com
PING google.com (216.239.57.99) 56(84) bytes of data.
64 bytes from 216.239.57.99: icmp_seq=0 ttl=244 time=11.5 ms
64 bytes from 216.239.57.99: icmp_seq=1 ttl=244 time=11.8 ms
64 bytes from 216.239.57.99: icmp_seq=2 ttl=244 time=11.5 ms
64 bytes from 216.239.57.99: icmp_seq=3 ttl=244 time=11.7 ms

[root@rocks-43 root]# ping nbc.com
PING nbc.com (63.241.60.70) 56(84) bytes of data.
64 bytes from nbc.com (63.241.60.70): icmp_seq=0 ttl=53 time=7.41 ms
64 bytes from nbc.com (63.241.60.70): icmp_seq=1 ttl=53 time=7.32 ms
64 bytes from nbc.com (63.241.60.70): icmp_seq=2 ttl=53 time=7.39 ms
64 bytes from nbc.com (63.241.60.70): icmp_seq=3 ttl=53 time=7.33 ms


This behavior happens for several different types of ethernet cards on opterons, and is not observed on either Pentium or Nocona systems.

Has anyone noticed this before? Our kernel version is:

(Nocona)
Linux rocks-43.sdsc.edu 2.4.21-20.EL #1 SMP Fri Oct 1 09:12:23 PDT 2004 x86_64 x86_64 x86_64 GNU/Linux

(Opteron)
Linux www.rocksclusters.org 2.4.21-20.ELsmp #1 SMP Sat Sep 18 18:28:16 PDT 2004 x86_64 x86_64 x86_64 GNU/Linux

Thank you,
Federico

P.S. There is some indication that the "tsc" kernel option fixes this partially, although while clock resolution is better, it is still not normal.

Version-Release number of selected component (if applicable):
kernel-2.4.21-20.EL

How reproducible:
Always

Steps to Reproduce:
See Description.

Actual Results:  See Description

Expected Results:  See Description

Additional info:
Comment 1 Olle Liljenzin 2004-11-25 05:34:06 EST
I also see this behaviour on all our Opteron machines.

Our EM64T and IA64 machines running 64 bit kernels report ping times
with normal resolution, so this looks very specific for the AMD-64 kernel.
Comment 2 Simon Garner 2005-01-31 16:22:55 EST
I am also seeing the same problem. Dual Opterons, kernel 2.4.21-
27.0.2.ELsmp, showing pings in units of 10ms. Also affects mtr and 
traceroute times.
Comment 4 Wilmer Jaramillo M. 2006-10-17 16:29:58 EDT
I am also seeing the same problem. With HP xw9300 Workstation with RHEL3 update
5,7 and 8 in Dual Opterons, affecting to ip-util package and NIC nVidia CK804
using driver nvnet.o and forcedeth.o.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210889


Comment 5 RHEL Product and Program Management 2007-10-19 15:15:26 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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