I mailed Steve Thomas at High Level Hardware about timekeeping on Orions, and received the following reply. The bit in double arrows is my original mail to him. Glossary: IOC Input/Output Controller, a circuit board in Orion which interfaces to disks, the ring front end, tape drives, the console etc etc > From: Steve Thomas > Date: Fri, 24 Apr 87 10:50:08 BST > To: mg@uucp.ukc.ac.uk > Subject: Re: real time clocks > >> We have had a user query about the accuracy of the real time clock on >> orions, claiming that one of the hosts was five minutes out. >> >> At UKC, /etc/rc sets the time from a central time server (eagle), and >> appear to lose real time at a rate of about 10 seconds per day. >> >> Where is the kernel's 50Hz clock interrupt derived from, and what accuracy >> of time-keeping is likely? > > It's actually a (nominally) 60Hz clock, derived by dividing down the 4MHz > clock on IOC 0. This frequency is controlled by an 8MHz crystal, and > typically runs slightly slow, losing about 4s per day. Early IOCs had > a different sort of 8MHz crystal which lost about 32s per day, but I > don't suppose you've still got any of those. Even earlier systems had > a misfeature whereby the division was all wrong and the system gained > 138s per day because of the software for a net 106s per day; you > certainly don't have any of those. > > Every time the clock ticks, the kernel adds 1000000/60 = 16666 microsecond > to it's idea of the time. Because of rounding errors, this strategy > loses 3.456s per day. Under 4.1BSD, these errors didn't occur because > the system counted in ticks. On our new computer and on the Vax, ticks > are at 100Hz so there's no problem there. > > Adding these together, you lose 7-8s per day, close enough to your > guess of 10s. > > Also on the IOC there's a battery backed-up real-time clock which is > only consulted on initial boot. This clock is controlled by a 32.768kHz > crystal on the IOC which is typically *much* more accurate - out by > <10s per year, somewhat better than you find on DEC hardware. So, > the time of day is reset by rebooting, even without troubling eagle. > > Hope this clears everything up. > > Steve Accordingly, the Orions no longer set the time of day from /etc/rc, but each relies on its own real-time clock. Orions may be expected to lose a few seconds for each day since they last rebooted. This gives no change whatsoever in the accuracy of time-keeping, since it will still be set from reality at reboot and loses from there, but it *does* mean that the Orions no longer have to rely on other things before they can be brought up in the event of a power cut. Reducing inter-system dependencies also improves reliability. (The jargon!) Before anyone suggests it, setting the date nightly might seem like a good idea to keep the kernel's idea of time more nearly in step with reality, but this would cause discontinuities in time which is likely to confuse many software subsystems. Martin