Mail Archives: djgpp/2001/01/31/17:06:40
Timer itself generates IRQs at a constant rate, right. But the DOS program
being run under windows (or with presense of such things as SMARTDRV) can
not have a perfect time measurement and perfect cycle measurement. Try to
reread my post and see why. I guess I explained clearly.
Good Luck
--
Alexei A. Frounze
alexfru [AT] chat [DOT] ru
frounze [AT] ece [DOT] rochester [DOT] edu
http://alexfru.chat.ru
http://members.xoom.com/alexfru/
http://welcome.to/pmode/
"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il> wrote in message
news:9003-Wed31Jan2001192619+0200-eliz AT is DOT elta DOT co DOT il...
> > 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 -