Mail Archives: djgpp/2001/01/31/12:30:53
> From: "Alexei A. Frounze" <dummy_addressee AT hotmail DOT com>
> Newsgroups: comp.os.msdos.djgpp
> Date: Wed, 31 Jan 2001 11:33:19 -0500
>
> If there's some code which runs upon timer interrupt and the number of
> instructions there varies from tick to tick, then if we measure time using
> BIOS tick counter, we end up with certain error due to that code (SMARTDRV
> is the case).
I don't think so. Since the timer tick works at a constant frequency,
and since the time of the next tick does not depend on the time of the
previous tick, the system clock will not slow down. What will happen
is that the time when the BIOS time counter increments will vary
slightly, depending on how much code runs off the timer tick.
This of course assumes that the code in the TSR doesn't take all the
54 msec until the next tick.
AFAIK, SmartDRV has special code to make sure it only reads/writes
amount of data that is small enough to leave enough of the CPU tiume
to the foreground task.
The issue with the compression program referred to by the message to
which I responded was that running that compression program caused the
system clock to lag behind the real time by significant amounts. I
don't think such a slow-down of the system clock can be caused by any
reasonable TSR which hooks the timer tick (and SmartDRV is a
reasonable TSR).
- Raw text -