Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!cs.utexas.edu!ico!rcd From: rcd@ico.ISC.COM (Dick Dunn) Newsgroups: comp.unix.microport Subject: Re: Clock loses "minutes" on V/AT 2.3 Summary: this is an ooooold problem Keywords: clock V/AT 2.3 5-star Message-ID: <9700@ico.ISC.COM> Date: 23 Sep 88 04:43:48 GMT References: <1464@ssc.UUCP> Distribution: na Organization: Interactive Systems Corp, Boulder, CO Lines: 35 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..."