Date: Wed, 1 Nov 2000 10:29:21 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: djgpp AT delorie DOT com Subject: Re: Elapsed time? In-Reply-To: <8tnm7j$mgi$1@nnrp1.deja.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Tue, 31 Oct 2000 dcasale AT my-deja DOT com wrote: > > > > No disk I/O should ever affect the system clock. > > > > > > Are you absolutely sure about that? > > > > Yes. The timer interrupt has the highest priority, and so should not > > be affected by almost anything else. > > _Should_ not be? Well obviously it _is_ being affected. I'm not arguing with the facts. I'm trying to give you feedback, based on the best of my knowledge, as to whether a given direction of trying to figure out the causes for the slow-down are worth your hassle. To the best of my knowledge, unless some TSR or device driver messes with your clock, disk I/O cannot slow down the timer, and neither can any CPU-intensive code such as compression. So I'd suggest to look for the reasons not in disk I/O or compression code (if none of them messes with the timer interrupt), but elsewhere. > > > I've noticed the WinBloze clock slowing down sometimes, when there's > > > a lot of disk activity or processor-intensive activity going on. > > > > Is that the same machine, or did you try this on several different > > systems? If that's the same machine, my first suspicion would be > > either some optional software that you have installed there, or a > > hardware problem. > > At least two different systems. What OS/versions did you run on both machines? Do both machines have similar or identical setup (TSRs and device drivers loaded)? Did you try to run the program on vanilla DOS system, without any TSRs and device drivers? How about posting CONFIG.SYS and AUTOEXEC.BAT? > That makes me wonder. Is there some way to read the CMOS clock on the > fly? Of course. You can read that clock by accessing ports 70h and 71h.