karron@MCIRPS2.MED.NYU.EDU (09/08/90)
Which is the better time call to use if you only are interested in measuring clock seconds ? (not system time, cpu time, but real time as measured by a stop watch ). How do you know if the Performance Measurement Utilities are installed ? I don't remember seeing them on my 3.3 inst tape. Where are they ? dan. +-----------------------------------------------------------------------------+ | karron@nyu.edu Dan Karron | | . . . . . . . . . . . . . . New York University Medical Center | | 560 First Avenue \ \ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> <your-number-here> | | (212) 340 5210 \**\__________________________________________ | +-----------------------------------------------------------------------------+
olson@anchor.esd.sgi.com (Dave Olson) (09/08/90)
In <9009080837.AA06570@mcirps2.med.nyu.edu> karron@MCIRPS2.MED.NYU.EDU writes: | Which is the better time call to use if you only are interested | in measuring clock seconds ? (not system time, cpu time, but | real time as measured by a stop watch ). gettimeofday() will get you down to the system clock resolution, which is 10 ms by default, but which can be changed to ~1 ms (exact value depends on the model) by kernel configuration or the ftimer command. time() will only give you 1 second resolution. | How do you know if the Performance Measurement Utilities are installed ? | I don't remember seeing them on my 3.3 inst tape. Where are they ? Install eoe2.sw.perf (the ftimer command mentioned above is in eoe2.sw.usrenv). -- Dave Olson Life would be so much easier if we could just look at the source code.
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (09/09/90)
In article <1990Sep8.085849.5096@odin.corp.sgi.com>, olson@anchor.esd.sgi.com (Dave Olson) writes: > > gettimeofday() will get you down to the system clock resolution, > which is 10 ms by default, but which can be changed to ~1 ms (exact > value depends on the model) by kernel configuration or the ftimer > command. time() will only give you 1 second resolution. The resolution of gettimeofday() is limited to the frequency of clock interrupts, which is either 10 or 1 ms. However, you should not expect the tv_usec field of the structure returned by gettimeofday() to contain a multiple of 10,000 or 1,000. Any fractions of a clock tick from the adjtime() system call are slopped into the current time. In addition, the syssgi() system call can be used to adjust the clock rate, periodically adding or subtracting a number of nanoseconds to the current time, thereby jiggling the least significant bits of the current time. The deamons described in timed(1M) and timeslave(1M) use both mechanisms. A port of ntp or xntp would also use them. Gettimeofday() and time() should be used for time stamps. The timers used by select() and other things are based on "lbolt", the "hz counter" that is returned by times(). Times() should be used if you want a relatively constant tick. vjs
SERRER@nrcm3.nrc.ca (Martin Serrer) (10/10/90)
Just a curiosity question.
Why is it that a $75K workstation (IRIS 4D50/GT) cannot keep time as
accurately as an el-cheepo $5 wrist watch? Mine seems to gain about 3 minutes
per week.
Has anyone built a Timex - Iris interface? :-)
Martin
+-----------------------------------------------------------------------------+
| Martin Serrer Systems Lab., Bldg. M2, Montreal Rd.|
| 613-993-9442 National Research Council of Canada,|
| serrer@syslab.nrc.ca Ottawa, Ontario, Canada K1A-0R6 |
+------------------- Software Rusts, Rust never Sleeps -----------------------+vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (10/13/90)
In article <206355EEFDFF000D92@NRCNET.NRC.CA>, SERRER@nrcm3.nrc.ca (Martin Serrer) writes: > Just a curiosity question. > > Why is it that a $75K workstation (IRIS 4D50/GT) cannot keep time as > accurately as an el-cheepo $5 wrist watch? Mine seems to gain about 3 minutes > per week. At last, a customer saying what I've been saying for years! Oh, well. There is an easy solution, provided you are running 3.3 or better. (3.3.1 is better for other reasons.) You can trim the system's clock by adjusting "timetrim" in /usr/sysgen/master.d/kernel. A good place to start for many 4D70's is -450000. Simply determine how much time your system has gained or lost in the last several days, convert that to a signed number of nanoseconds/seconds, and edit the configuration file. Your value of 3 minutes/7 days or 180*10**9 nsec/ 604800 seconds suggest a value of -300000 would be a good start for your machine. Timed(1M) and timeslave(1M) describe how the system clock can be automatically trimmed. Vernon Schryver vjs@sgi.com
doelz@urz.unibas.ch (10/14/90)
In article <72069@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > In article <206355EEFDFF000D92@NRCNET.NRC.CA>, SERRER@nrcm3.nrc.ca (Martin Serrer) writes: .. >> >> accurately as an el-cheepo $5 wrist watch? Mine seems to gain about 3 minutes >> per week. .. > At last, a customer saying what I've been saying for years! Oh, well. .. > is better for other reasons.) You can trim the system's clock by adjusting > "timetrim" in /usr/sysgen/master.d/kernel. A good place to start for many .. Well, the problem on our box is that the time gained or lost seems to be load- dependent. I described this penomenon on a 4D/70 in 1988 the first time, and, admitting that the 4D/120 we have now got better (only a few minutes per week instead of per day), I decided to adjust the clock manually. It is hopeles to use the timetrim mechanism without spending more time to adjust it than gaining by correct time. After having complained, I gave up on this subject. The only problem I have is if I check file creation dates of NFS'ed lock files and the computers run different times alltogether. SUGGESTION: Because in a multi-vendor network timed and collegues are different, put the source of timed and timeslave in 4Dgifts. - Reinhard DISCLAIMER: Once you do not exactly need to know the time a few minutes plus or minus don't really matter if jobs are runnig for weeks :-)
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (10/15/90)
In article <1990Oct14.083831.1022@urz.unibas.ch>, doelz@urz.unibas.ch writes: > > Well, the problem on our box is that the time gained or lost seems to be >load- dependent. I described this penomenon on a 4D/70 in 1988 the first time, > and, admitting that the 4D/120 we have now got better (only a few minutes > per week instead of per day), I decided to adjust the clock manually. > It is hopeles to use the timetrim mechanism without spending more time > to adjust it than gaining by correct time. After having complained, I > gave up on this subject. The only problem I have is if I check file > creation dates of NFS'ed lock files and the computers run different times > alltogether. Since I started playing with IRIS and time, before the 4D line, I have not heard of verified problems in time that depend on system load. They would involve missed clock interrupts, which would probably have bad effects in many places. The only time problem I know of involves variations among machines of the hardware clock frequency. I have not heard of individual machines whose frequency changed (without having had a new IP4 installed). It seems plausible that if "fast timers" are turned on, the resulting 1KHz clock ticks might sometimes get lost. In other words, individual IRIS 4D70's seem stable when the default 100Hz clock is used. It is just that they are impatient with the official march of time, and gain as much as 450 microseconds each second, or about 38 seconds/day, or <4 minutes/week. I never heard of gains of minutes per day. A group of IRIS's synchronized with timed is stable. A group of 4D70's synchronized to each other and not to anything else should stay within 50 millseconds of each other for weeks at a time, as measured with timedc. I know of an internet of thousands of IRIS's, all synchronized with timed to a 4D20, which is synchronized to another machine with timeslave, which is in turn synchronized to a WWV receiver with timeslave. As long as no one breaks the netgroups and the network does not die, these thousands of IRIS stay somewhat close. Right now, a sample of them are between 1 and 80 msec different. That is close enough for NFS files, which need only to be consistent to the second. Please report any ways to make an IRIS lose time by running a program to the Hotline. If you have a machine that gains minutes per day, get your hardware support to fix it. Vernon Schryver, vjs@sgi.com