Bug 128428

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):
kernel-2.4.21-15.EL


How reproducible:
Everytime


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

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

int
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;
    else
      counts[diff] += 1;
    diff = ((recent.tv_sec  - start.tv_sec)*1000000 +
            (recent.tv_usec - start.tv_usec));
    if (diff > 5000000)         /* 5 seconds */
      break;
    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.