peter@hp-pcd.UUCP (Peter Robinson) (11/02/83)
#N:hp-pcd:19500005:000:715
hp-pcd!peter Nov 1 08:33:00 1983
We are running 4.1bsd on a VAX 750 and after a year of fairly good timekeeping,
our software clock has begun losing up to 5 minutes a day. DEC replaced the
hardware interval clock with a new one, but it seems not to have made any
difference. The only significant change I have made to the system is to
install a Unibus driver for the ABLE VMZ/32 (dmf.c).
I would appreciate any tips on what might be causing the problem. Is it true
that there is a variable in the system which allows you to change the interrupt
rate of the interval clock and thus change the software clock speed?
Thanks,
Peter Robinson
Hewlett-Packard PCD
Corvallis, OR.
{...ucbvax!hplabs, harpo, ogcvax}!hp-pcd!peterptw@vaxine.UUCP (P. T. Withington) (11/04/83)
This is a longstanding bug which I have never found any answer to. I suspect it has to do with clock ticks getting lost on a heavily loaded VAX. (There is no code to deal with interval timer overrun.) It shows up more on a 750 because it is easier to overload. My pet peeve is that the VAX has this nifty high-resolution time-of-year clock that Unix only bothers to look at at boot time, and then maintains its time using an interval timer to approximate a line frequency clock (at a significantly poorer resolution). I understand the history of this organization, but... So an immediate solution is to reboot often enough to keep your time inaccuracy down. This also gives you an excuse to fsck, clean /tmp, etc. There is a mention of a long-standing time bug being fixed in 4.2, but I haven't had a chance to see what they do. (I'm betting they read the TOY clock when the interval timer overruns.) 't` --Tucker (ptw@vaxine.UUCP) ~
rees@apollo.UUCP (Jim Rees) (11/07/83)
The software clock losing time on a Vax under 4.1bsd is a well known problem, and there has been a fix out for a long time. If I don't see the fix posted in a few days I will dig it out myself and post it.