[comp.unix.microport] Clock loses "minutes" on V/AT 2.3

rcd@ico.ISC.COM (Dick Dunn) (09/23/88)

In article <1464@ssc.UUCP>, fyl@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..."

dave@pmafire.UUCP (Dave Remien) (09/24/88)

I had the same problem; the (well, sort of) solution is to have the
following line in your root crontab entry:

5,15,25,35,45,55 * * * * date `/etc/cmos_setup -d`

(I've forgotten the actual V/AT cmos set/read command, cmos_setup is
V/386.  The command is in /etc though.  I just called the 286, but he
can't answer the phone right now :-))

The option for the cmos read command is the one that returns the current
cmos clock time in date format (see the man page).

An interesting benefit(?!) is that the time will bounce around; the 286
I've used averages about 7 V/AT minutes for 10 sidereal minutes, on a
heavily (>90% busy) system. Not that sidereal time is too real, itself,
mind you.

The 2.3 system does lose interrupts; Microport told me that something in
the hd driver was (probably) leaving interrupts off for too long, and
the clock interrupts get lost. 'Specially bad on a busy system. 2.2
didn't do this, or nowhere near as badly.

This is their fix. It does tend to fill up the cron log
(/usr/lib/cron/g) over time.
-- 
----------
Dave Remien - WINCO Computer Engineering Group (only somewhat confused, now)
208-526-3523, 0800 to 1615 MDT; 208-524-1906, 1800 'til whenever
Potential paths: ...!{killer|bigtex}!pmafire!dave} | ...!ucdavis!egg-id!rzd

rolfe@w3vh.UUCP (Rolfe Tessem) (09/24/88)

In article <9700@ico.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
>In article <1464@ssc.UUCP>, fyl@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.  

This was present in my 2.2 as well, but was fixed in 2.3 (at least on
my 10 Mhz generic AT clone).  The CMOS is still a little more accurate
though, so I run a crontab to sync the UNIX clock with the CMOS time
once every 24 hours, in the middle of the night.

By the way, since Microport takes a lot of bashing in this group, I'd
like to mention that my System V/AT (version 2.3) has been up and running
for over two months continuously without a hiccup, as I'm writing this.
This system takes a partial newsfeed, polling UUNET a couple times a
day, and I access it extensively from remote locations since I'm
often away for weeks at a time.  The double panics went away completely
about 6 months ago when I replaced the serial card due to a lightning-
induced power surge taking it out, so I'm inclined to believe the panics
I was having previously were due to marginal serial hardware.  I'd
suggest that anyone still having serial-port-related double-panics do
some swapping of serial hardware...



-- 
UUCP:         uunet!w3vh!rolfe 			| Rolfe Tessem
INTERNET:     rolfe@w3vh.uu.net			| P.O. Box 793
AMPRNET:      rolfe@w3vh.ampr.org   [44.44.0.1]	| Great Barrington, MA 01230
PACKET RADIO: w3vh@wa2pvv 			| (413) 528-5966