Mail Archives: djgpp/2000/10/24/03:40:46
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.
> 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.
- Raw text -