Time (is fleeting, Maaaadness takes its toll)

[doelz at urz.unibas.ch]

In article <72069 at sgi.sgi.com>, vjs at rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> In article <206355EEFDFF000D92 at NRCNET.NRC.CA>, SERRER at 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 :-)