Mail Archives: djgpp/2000/10/26/17:16:13
In article <Pine DOT SUN DOT 3 DOT 91 DOT 1001024093648 DOT 24828K-100000 AT is>,
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.
- Raw text -