Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!wuarchive!uunet!mcsun!ukc!axion!delluk!tim From: tim@delluk.uucp (Tim Wright) Newsgroups: sco.opendesktop,comp.unix.sysv386 Subject: Re: SCO Unix, ALR FlexCACHE losing time Message-ID: Date: 4 Jan 91 09:07:52 GMT References: <1991Jan01.162400.6155@litwin.com> <1991Jan2.221527.15181@gsm001.uucp> Sender: usenet@delluk.uucp (Usenet posting login) Organization: Dell Computer Corp., Bracknell, UK Lines: 49 In <1991Jan2.221527.15181@gsm001.uucp> gsm@gsm001.uucp (Geoffrey S. Mendelson) writes: >in Message-ID: <1991Jan01.162400.6155@litwin.com> >Dr. Victor L. Rice writes: >> >>What gives ??? Why am I losing over a second a day ?? >>-- ... >2: When UNIX (and MS-DOS) are booted, the read the battery backed up clock. > From then on they update the time on each "clock tick interupt". > Most device drivers, especially disk, turn off interupts while they > are running. > The clock will be "off" 1/60 of a second until the interupt gets processed. > Since disk drivers don't want to be interupted, they turn off interupts > during transfers. If for some reason they are busy for more than 1/60 of > a second you loose any clock ticks after the first. > If you have a tape or SCSI driver that is hit very hard you may see this. > Also a serial card driver may block interupts, but not likely for that > long a time. > Is this really the case? How often do the above drivers do an 'splhi()' which would lock out the clock. I can't imagine it happens that much. The AT&T 3B15 had a bug where the disk buffer cache code locked out the clock and it really knocked the time out of whack when busy. From memory, v7-style block drivers lock the buffer cache with spl6, which doesn't affect the clock. I suppose a driver doing "programmed-io" might want to lock out all interrupts but I can't see that squirting 512 bytes in a loop takes that long on a modern system ! Anybody care to comment/correct me. >Also a note on accuracy: > > 1% would be 864 seconds a day or 14 minutes 24 seconds > .1% would be 86 seconds a day or 1 minute 26 seconds > .01% would be 8.6 seconds a day > 1 second a day is 1/86400 or 1 in almost 1 part in one hundred thousand. >How many scientific instruments can boast that accuracy? Well my casio wristwatch (quite cheap) is GUARANTEED accurate to 15 seconds a month or ~ 1/172800. I fail to see why the RTC-chip manufacturers can't make one at least as good (except for pricing considerations :-) Tim -- Tim Wright, Dell Computer Corp. (UK) | Email address Bracknell, Berkshire, RG12 1RW | Domain: tim@dell.co.uk Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim "What's the problem? You've got an IQ of six thousand, haven't you?"