Bug 128428 - Opteron gettimeofday granularity problem
Opteron gettimeofday granularity problem
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Jim Paradis
Depends On:
Blocks: 156320
  Show dependency treegraph
Reported: 2004-07-22 15:51 EDT by Walt Kopy
Modified: 2013-08-05 21:07 EDT (History)
18 users (show)

See Also:
Fixed In Version: RHSA-2005-663
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-28 10:23:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:663 qe-ready SHIPPED_LIVE Important: Updated kernel packages available for Red Hat Enterprise Linux 3 Update 6 2005-09-28 00:00:00 EDT

  None (edit)
Description Walt Kopy 2004-07-22 15:51:24 EDT
Description of problem:
With RedHat AS x86 on opteron using the 2.4.21-9 kernel, the
gettimeofday function demonstrated microsecond resolution. However in
RedHat update 2 the 2.4.21-15 kernel, the gettimeofday function
resolution appears to be less. It is now equal to that of a Linux
clock tick, .01 sec.

This problem causes MPI benchmarks like Pallas and b_eff to produce
innacurate results. Since these benchmarks are important tools used
to evaluate linux cluster performance this problem is considered to
be serious.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Compile and run the following program which can be used to demonstrate
the problem:

#include <sys/time.h>
#include <stdio.h>

main(int argc, char* argv[])
  struct timeval start, prev, recent;
  long diff;
  int underflows = 0, overflows = 0;
#define LIMIT 20000
  int counts[LIMIT];

  bzero(counts, sizeof(counts));

  gettimeofday(&start, NULL);
  prev = start;
  while (1) {
    gettimeofday(&recent, NULL);
    diff = ((recent.tv_sec  - prev.tv_sec)*1000000 +
            (recent.tv_usec - prev.tv_usec));
    if (diff < 0)
      underflows += 1;
    else if (diff > LIMIT)
      overflows += 1;
      counts[diff] += 1;
    diff = ((recent.tv_sec  - start.tv_sec)*1000000 +
            (recent.tv_usec - start.tv_usec));
    if (diff > 5000000)         /* 5 seconds */
    prev = recent;
  if (underflows > 0)
    printf("%9d intervals took less than %6d microseconds\n",
           underflows, 0);
  if (overflows > 0)
    printf("%9d intervals took more than %6d microseconds\n",
           overflows, LIMIT);
  for (diff = 0; diff < LIMIT; diff += 1)
    if (counts[diff] > 0)
      printf("%9d intervals took %9s %6d microseconds\n",
             counts[diff], "", diff);
  return 0;

Actual results:
[root@crs1 root]# uname -a
Linux crs1 2.4.21-15.ELsmp #1 SMP Thu Apr 22 00:09:01 EDT 2004 x86_64
x86_64 x86_64 GNU/Linux

[root@crs1 root]# ./dll
138948453 intervals took                0 microseconds
      318 intervals took            10000 microseconds
      182 intervals took            10001 microseconds

[root@crs1 root]#  ./dll
138909560 intervals took                0 microseconds
      501 intervals took            10000 microseconds

Expected results:
On a system with microsecond resolution, like 2.4.21-9, you see output
like this:

  5283049 intervals took                0 microseconds
  4931788 intervals took                1 microseconds
     3150 intervals took                2 microseconds
      367 intervals took                3 microseconds
      363 intervals took                4 microseconds
      666 intervals took                5 microseconds
     1220 intervals took                6 microseconds
     2507 intervals took                7 microseconds
     1618 intervals took                8 microseconds
      582 intervals took                9 microseconds
      132 intervals took               10 microseconds
      152 intervals took               11 microseconds
      152 intervals took               12 microseconds
       31 intervals took               13 microseconds
       13 intervals took               14 microseconds
        9 intervals took               15 microseconds
       12 intervals took               16 microseconds
        4 intervals took               17 microseconds
        9 intervals took               18 microseconds
        6 intervals took               19 microseconds
       10 intervals took               20 microseconds
        5 intervals took               21 microseconds

Additional info:
This problem causes MPI benchmarks like Pallas and b_eff to produce
innacurate results. Since these benchmarks are important tools used
to evaluate linux cluster performance this problem is considered to
be serious.
Comment 2 Jim Paradis 2004-08-24 14:38:35 EDT
By default, systems without an HPET timer fall back to using the PIT
timer (which has .01 s resolution).  Although the TSC timer is
available for finer resolution, we disabled it by default due to
another problem.  

A workaround for the problem you're seeing right now is to enable the
TSC timer by specifying the "tsc" parameter at boot time.  Meanwhile
I'll revisit the TSC timer issue.
Comment 6 Jim Tong 2004-12-28 03:56:39 EST
Can someone at RedHat elaborate what the TSC timer issue is?
I have an 4 way opteron system, is it safe to use tsc or cyclone as
the kernel parameter at boot time?
Comment 7 Arjan van de Ven 2004-12-30 09:15:26 EST
cyclone is only appropriate for IBM x440 line of machines

TSC will work generally, but there may be unreliabilities in case of clockdrift
(which is more likely the more cpus you have) between the cpus.
(temperature differences alone can cause this over longer time).
HPET is the most reliable method, and in theory all modern systems have one..
Comment 8 Jim Tong 2005-01-03 19:23:01 EST
So Jim Paradis, meant that "we disabled it by default due to another 
problem" was entirely the clock skew problem?  Our system doesn't 
even detect HPET, does it mean it doesn't have it.  Do I have to ask 
someone at AMD that?
Comment 9 Jim Paradis 2005-01-04 12:03:53 EST
It wasn't just clock skew; there was a synchronization problem such
that clock updates (e.g. via ntpdate) would occasionally update the
wrong half of the doubleword and you'd see the year jump to something
like 586562 (See Bug 114869).
Comment 10 Jeff Layton 2005-01-19 14:08:27 EST
So, is this TSC problem an issue on UP AMD64 systems or on the EM64T,
or is it a problem only with NUMA machines? If it's not a problem on
these arches then perhaps we should consider making TSC the default on
Comment 15 Syed Khader Vali 2005-05-11 03:36:07 EDT
So, is there a fix to this problem yet ? This problem has not been fixed as of
RHEL 3 AS Update 4.
Comment 16 Mark Hoover 2005-05-24 10:10:00 EDT
We are encountering a situation where the lack of precision is causing an 
issue with some Oracle timestamps.  The database was exported from Oracle on 
Solaris into Oracle on Linux.

> 5/18/2005 5:28:17.358617 PM
> 5/18/2005 5:28:17.408617 PM

As you can see, the timestamps all end in "8617"
Comment 21 Jim Paradis 2005-06-15 17:38:16 EDT
I am currently investigating the feasibility of backporting the ACPI
power-management timer code from RHEL4 so as to make another free-running timer
available for timekeeping.  I have already backported this to another version of
the 2.4 kernel, so this should not be terribly difficult.
Comment 28 Ernie Petrides 2005-07-20 03:48:48 EDT
A fix for this problem has just been committed to the RHEL3 U6
patch pool this evening (in kernel version 2.4.21-33.EL).
Comment 29 Jim Paradis 2005-07-20 10:29:22 EDT
Note that to take advantage of the fix just committed one has to boot with the
"pmtmr" boot command line option.  This should be noted in the errata documentation.
Comment 30 Jatin Nansi 2005-07-21 06:56:21 EDT
Should this information be noted in the release notes for U6?
Comment 32 Ernie Petrides 2005-07-21 21:42:07 EDT
To kbaxley, not "clock=pmtmr", just "pmtmr".
Comment 46 Ernie Petrides 2005-09-12 14:31:50 EDT
Hi, Bastien.  Please show the output of /proc/cmdline on the boot-up
that shows the failure, and please also indicate whether the reproducer
program in the initial comment of this bug report also fails.  Thanks.
Comment 48 Bastien Nocera 2005-09-26 09:22:48 EDT
Re comment #46, the customer wasn't using the pmtmr option as mentioned in
comment #29.
Comment 49 Red Hat Bugzilla 2005-09-28 10:23:45 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

Comment 53 Peter Martuccelli 2006-10-20 17:06:52 EDT
*** Bug 210889 has been marked as a duplicate of this bug. ***
Comment 54 Ernie Petrides 2006-10-20 19:09:02 EDT
Undoing dup, because this bug was fixed in U6 and bug 210889 was entered on U8.

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