Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!pasteur!ames!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!milano!bigtex!pmafire!dave From: dave@pmafire.UUCP (Dave Remien) Newsgroups: comp.unix.microport Subject: Re: Clock loses "minutes" on V/AT 2.3 Summary: It does Keywords: clock loses time V/AT 2.3 Message-ID: <462@pmafire.UUCP> Date: 23 Sep 88 20:20:04 GMT References: <1464@ssc.UUCP> Reply-To: dave@pmafire.UUCP (Dave Remien) Distribution: na Organization: WINCO, INEL, Idaho Lines: 29 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