Ping RTT clock resolution problem on x86_64

[Federico Sacerdoti]

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 at 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 at 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 at 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 at 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

Rocks Cluster Group, San Diego Supercomputer Center, CA