Time (is fleeting, Maaaadness takes its toll)

Vernon Schryver vjs at rhyolite.wpd.sgi.com
Mon Oct 15 09:22:16 AEST 1990


In article <1990Oct14.083831.1022 at urz.unibas.ch>, doelz at 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 at sgi.com



More information about the Comp.sys.sgi mailing list