Clock loses "minutes" on V/AT 2.3

[Dick Dunn]

In article <1464 at ssc.UUCP>, fyl at ssc.UUCP (Phil Hughes) writes:
> The clock has always run slow on V/AT 2.3 running on our 5-star system...
> ...Here is what [I] found...
> The clock looses minutes.  In other words, if I boot and set the clock,
> some time later it will be 1 minute slow or 2 minutes slow or whatever...

This is a long-standing problem.  It is present in my 2.2.0 system; I had
it as of June or so of '87.  The suggested fix, back then, was to put
something in crontab to reset the UNIX clock from the battery-backed-up
CMOS clock.  This made the gross- level timekeeping accurate, but having
the time shift backward (from the bug) and forward (from the patch) by a
whole minute causes various problems.

> To me, it sounds like a lost interrupt.  The 5-star is a strange beast...

I don't see how a lost interrupt could do it, and, by the way, it happens
on other systems.  From what I know, my NEC clone is fairly faithful to how
things should work, and it has the problem.

The reason I doubt a lost interrupt is that the clock interrupts occur at
HZ intervals, namely 1/60 sec on the 286.  This doesn't seem to have any
connection to the full-minute (3600 tick) error.

The problem is serious in that it can cause cron jobs to run twice and, if
they're not careful about interlocking against themselves, curdle sig-
nificant parts of the known universe:  Cron wakes up, sees it's time to run
a job, does it, the clock moves backwards, cron checks the time before
sleeping again and figures out what to run next.  Things which might expect
to run once in n hours can run less than a minute apart...nasty.

I'd like to know whether 2.4 (or whatever is the current most recent final
release) still has the problem...if I could get any info about it.
-- 
Dick Dunn      UUCP: {ncar,nbires}!ico!rcd           (303)449-2870
   ...Worst-case analysis must never begin with "No one would ever want..."