Date: Wed, 31 Jan 2001 19:26:19 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: djgpp AT delorie DOT com Message-Id: <9003-Wed31Jan2001192619+0200-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6 In-reply-to: <959emd$g57sf$1@ID-57378.news.dfncis.de> (dummy_addressee AT hotmail DOT com) Subject: Re: DJGPP timer slowdown References: <959emd$g57sf$1 AT ID-57378 DOT news DOT dfncis DOT de> Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Alexei A. Frounze" > 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).