> Bruce Guenter wrote:
> >
> > Greetings.
> >
> > As I was trying to track down a problem with the clock on a router
> > behaving erratically, I ran a simple loop benchmark repeatedly and
> > observed that the time taken to run the loop varied by a factor of four.
> > I've attached a copy of the trivial code I've been using as a test. The
> > output that I'm seeing is similar to the following:
[SNIPPED first inquiry]
>
> I have a production machine which also is an AMD K6-233, running
> 2.0.37-pre4.
> This machine has a light load but also managed to have a clock skew of
> over 20 minutes each day (okay, light, I got an totally niced rc5 client
> running too). I solved it by running '/sbin/clock -r' to read the time
> from the CMOS which does keep a correct time. Maybe it has something to
> do with the fact that it's and AMD-K6 233Mhz or the rc5 client with MMX
> extensions might do something weird, I dunno.
>
> -Yaron Bandell.
[SNIPPED Machine info]
The current time-keeping in the kernel isn't too good. Here is
a log of the daily resetting of time to NIST
Reference time = Fri Feb 12 16:54:16 1999
My time = Fri Feb 12 16:54:17 1999
Difference = 1 seconds
Time set by 132.163.135.130 (132.163.135.130)
Setting hardware clock to Fri Feb 12 16:54:16 EST 1999
Reference time = Sat Feb 13 00:00:05 1999
My time = Sat Feb 13 00:00:00 1999
Difference = -5 seconds
Time set by time-A.timefreq.bldrdoc.gov (132.163.135.130)
Reference time = Sun Feb 14 00:00:14 1999
My time = Sun Feb 14 00:00:00 1999
Difference = -14 seconds
Time set by time-A.timefreq.bldrdoc.gov (132.163.135.130)
Reference time = Tue Feb 16 00:00:29 1999
My time = Tue Feb 16 00:00:01 1999
Difference = -28 seconds
Time set by time-A.timefreq.bldrdoc.gov (132.163.135.130)
Reference time = Wed Feb 17 00:00:22 1999
My time = Wed Feb 17 00:00:08 1999
Difference = -14 seconds
Time set by time-A.timefreq.bldrdoc.gov (132.163.135.130)
Reference time = Thu Feb 18 00:00:14 1999
My time = Thu Feb 18 00:00:00 1999
Difference = -14 seconds
Time set by time-A.timefreq.bldrdoc.gov (132.163.135.130)
Reference time = Fri Feb 19 00:00:17 1999
My time = Fri Feb 19 00:00:03 1999
Difference = -14 seconds
Time set by time-A.timefreq.bldrdoc.gov (132.163.135.130)
Reference time = Fri Feb 19 19:29:01 1999
My time = Fri Feb 19 19:29:01 1999
Difference = 0 seconds
Time set by 132.163.135.130 (132.163.135.130)
Setting hardware clock to Fri Feb 19 19:29:01 EST 1999
Reference time = Sat Feb 20 00:00:03 1999
My time = Sat Feb 20 00:00:00 1999
Difference = -3 seconds
Time set by time-A.timefreq.bldrdoc.gov (132.163.135.130)
Reference time = Sun Feb 21 00:00:14 1999
My time = Sun Feb 21 00:00:01 1999
Difference = -13 seconds
Time set by time-A.timefreq.bldrdoc.gov (132.163.135.130)
Reference time = Mon Feb 22 00:00:15 1999
My time = Mon Feb 22 00:00:00 1999
Difference = -15 seconds
Time set by time-A.timefreq.bldrdoc.gov (132.163.135.130)
The times where there was little skew were times in which the machine
was recently rebooted. In this case, the time is always set to NIST
as soon as the network is up.
So it's typically off by -14 seconds in a 24 hour period. This is
a dual pentium 400 MHz machine with an Intel chip-set.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.1 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Wisdom : It's not a Y2K problem. It's a Y2Day problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/