Don Hatch (hatch++at++hell.asd.sgi.com)
Tue, 9 Jul 1996 01:42:44 -0700
Hi John--
I'm a little suspicious of your calculated number 45000 for the indy
since it came from a measured ticks/second of exactly 22,222,222...
Do you get this number consistently?
Can you send or post a copy of the program you used?
> When writing code to test the actual clock rate, we had a funny experience.
>
> The output at the end of this mail message contains a series of runs of the
> "clocktest" program at different times and at different accuracies (which
> decides how long the program should run). The number after 'clocktest' tells
> the program how accurate the answer needs to be.
>
> We found the actual calculated clock rate to be 40,000 sometimes and 41,600
> at other times. This was on a 250Mhz R4400 Extreme. Our Elan changes between
> 39999 and 39995 for minutes at a time also. Same program, just run at a
> different time. Of course, I am less concerned about a 0.01 percent change
> on the Elan than the huge 4 percent variation on the Extreme.
>
> What could be the problem here?
>
I assume you are measuring the memory-mapped realtime clock
returned by syssgi(SGI_QUERY_CYCLECNTR) (or equivalently pfGetTime())
against the time returned by gettimeofday()
(or time(), or times(), or something).
Keep in mind that the time returned by gettimeofday() and friends
is very unstable.
Certain events such as console messages cause the
clock to stop for typically 10 milliseconds.
If you are running timed or timeslave, every couple of minutes (typically)
it will call adjtime() to sync with the network or master time.
This does not cause an instantaneous time
change; rather, it causes the clock to speed up or slow down for
a period of a few seconds to a few minutes.
The memory-mapped realtime clock is not subject to any such adjustments
(but of course this means it will drift eventually...)
I suspect that these adjustments account for the apparent changes
in measured clock speed that you observed between different runs of the
same program.
See the man pages for timed(1), timeslave(1), adjtime(3) for more
depressing details. You can make timed log its activity to a file so
you can see when it's doing its evil deeds.
Experiment with adjtime() and "date -a".
Let us know if you still think something's awry.
Don
-- Don Hatch hatch++at++sgi.com (415) 933-5150 Silicon Graphics, Inc.======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer++at++sgi.com Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:09 PDT