From: "Alexei A. Frounze" <dummy_addressee AT hotmail DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DJGPP timer slowdown
Date: Wed, 31 Jan 2001 16:59:34 -0500
Lines: 48
Message-ID: <95a1qh$gkt4b$1@ID-57378.news.dfncis.de>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010131103626 DOT 29266V-100000 AT is> <959emd$g57sf$1 AT ID-57378 DOT news DOT dfncis DOT de> <9003-Wed31Jan2001192619+0200-eliz AT is DOT elta DOT co DOT il>
NNTP-Posting-Host: ip136.rochester6.ny.pub-ip.psi.net (38.26.84.136)
X-Trace: fu-berlin.de 980978322 17462411 38.26.84.136 (16 [57378])
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

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).