home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!spool.mu.edu!olivea!sgigate!sgi!rhyolite!vjs
- From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
- Newsgroups: comp.sys.sgi
- Subject: Re: clock speed
- Message-ID: <uoft000@rhyolite.wpd.sgi.com>
- Date: 11 Jan 93 18:13:20 GMT
- References: <1is8dhINNhme@usenet.INS.CWRU.Edu>
- Organization: Silicon Graphics, Inc. Mountain View, CA
- Lines: 32
-
- In article <1is8dhINNhme@usenet.INS.CWRU.Edu>, ce095@cleveland.Freenet.Edu (Jeffrey Scott Traigle) writes:
- >
- > Something that I have noticed since beginning administrating SGIs
- > several months ago is that the clock on them run fast. Within three
- > to four days of setting the time on them, they are around 20 minutes
- > fast. Is this something inherent in SGIs or is it just something with
- > our setup?
-
-
-
- Without more information about which models of IRIS and which
- versions of IRIX they are running, it's hard to say much.
-
- Still, 5 minutes/day is not an expected error.
-
- I bet that timed is running the contents of their /usr/tmp/.timetrim
- files are crazy (a large positive number of nanoseconds/second),
- perhaps because some of the machines were sending a lot of messages to
- the console, making their clocks appear to be very, very slow.
-
- It should be effective to:
- (1) delete /usr/tmp/.timetrim on all of the machines
- (2) restart timed (the easiest way is to reboot)
- (3) every day or two for a week or two use the data command
- to set the time. Try to set the time right to within
- a couple of seconds.
-
- This should train timed about the drift of the clocks, and cause
- each machine to put a good value in /usr/tmp/.timetrim.
-
-
- vjs
-