From: dcasale AT my-deja DOT com Newsgroups: comp.os.msdos.djgpp Subject: Re: Elapsed time? Date: Thu, 26 Oct 2000 21:00:59 GMT Organization: Deja.com - Before you buy. Lines: 65 Message-ID: <8ta628$4t7$1@nnrp1.deja.com> References: NNTP-Posting-Host: 199.249.234.30 X-Article-Creation-Date: Thu Oct 26 21:00:59 2000 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) X-Http-Proxy: 1.1 x53.deja.com:80 (Squid/1.1.22) for client 199.249.234.30 X-MyDeja-Info: XMYDJUIDdcasale To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com In article , djgpp AT delorie DOT com wrote: > > On Mon, 23 Oct 2000 dcasale AT my-deja DOT com wrote: > > > > > I've noticed that when I run the compression program, the system > > > > clock slows down. > > > > > > Please tell the details, in particular how did you notice that the > > > clock slows down, and how much does it slow down. Also, what > > > library functions do you use to calculate the amount of time a > > > certain calculation takes? > > > > I noticed because, when I set the time using the DOS TIME command, > > and when calling asctime to print the starting and ending time, the > > ending time is usually several minutes slow. I first tried using > > ftime to get the starting and ending time, for calculation > > purposes. When I noticed the slowdown, I switched to uclock. > > Still not accurate. > > That's really, REALLY weird... I could perhaps believe that using > uclock might have adverse effects on the system clock, because uclock > reprograms the timer chip (although I've never seen any such adverse > effects on any machine I used). But ftime doesn't even futz with the > timer chip, it simply calls two documented DOS functions to get the > current date and time. > > > My program is, obviously, extremely disk-intensive. I'm caching > > reads and writes with separate 5MB buffers. Could this cause the > > problem? > > No disk I/O should ever affect the system clock. Are you absolutely sure about that? I've noticed the WinBloze clock slowing down sometimes, when there's a lot of disk activity or processor-intensive activity going on. What's interesting is that a previous version of this same DOS program didn't cache the input or output and had a much less noticeable slowdown -- about 10 percent. > > The clock slows down by as much as 50% either way, by the way. > > Are you sure your program, or one of the tools you use to measure > time, don't hook the timer tick interrupt? Your description surely > sounds like some timer interrupt handler that somehow doesn't chain to > the previous handler. If the original timer tick handler, that's part > of the system BIOS, doesn't get some of the ticks, the system time > will indeed slow down. I could list every interrupt call I use, if it would help. Almost all of them are disk IO related. My program grabs all of the LFN and file info directly off the disk before doing any compression. I've got an interrupt call to look up the MBCS lead byte table in there too, although it isn't currently being called. None of them have anything to do with the system clock. What's even more interesting is that the clock is slow after the program finishes, but a system reboot resets the clock to the proper time. Hmmm... Damon Casale, damon AT redshift DOT com "Compression speeds are relative." -- anonymous astronomer/programmer Sent via Deja.com http://www.deja.com/ Before you buy.