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 11:33:19 -0500
Lines: 53
Message-ID: <959emd$g57sf$1@ID-57378.news.dfncis.de>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010131103626 DOT 29266V-100000 AT is>
NNTP-Posting-Host: ip78.rochester6.ny.pub-ip.psi.net (38.26.84.78)
X-Trace: fu-berlin.de 980958739 16949135 38.26.84.78 (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

"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il> wrote in message
news:Pine DOT SUN DOT 3 DOT 91 DOT 1010131103626 DOT 29266V-100000 AT is...
>
> On Wed, 31 Jan 2001 dcasale AT my-deja DOT com wrote:
>
> > > The thing is that if there is some code that executes upon timer
> > > interrupt or another interrupt happens inbetween tick waiting loop
> > > and RDTSC, we have an incorrect value. And the more code is there,
> > > the more error. This way, if you have drivers like SMARTDRV, RTC may
> > > be useless until you flush the disk cache completely. And this is
> > > worsen under windows by other things.
> >
> > [snip]
> >
> > Ah ha!!
> >
> > I posted a long while ago about a timer slowdown that happened in my
> > compression program.  With compression turned off, the timer was
> > accurate, but with compression turned on, it was slow.  Now I know why,
> > based on what was written above.  I _was_ running SmartDrive.
>
> Sorry, I'm not following (and I don't see the rest of the thread, so I
> cannot figure out if there's something else in the snipped parts that
> would help understand this).
>
> What does all the above have to do with slowing down the system clock?
> AFAICS, it talks about the results of RDTSC, not about the system
> clock.
>
> I also cannot figure out what does SmartDRV have to do with the system
> clock (or RDTSC, for that matter).

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). Same thing with RDTSC - if any interrupt happens between the
point we read the time (from BIOS tick counter or anything else) and RDTSC
instruction and there's a lot of extra code in ISR, RDTSC gives us an
adjusted value. These both things lead to a certain error in CPU frequency
measurement unless we get a rid of all those interrupts and stuff which
takes different amount of time.
This is the issue.

> AFAIK, SmartDRV doesn't work on the BIOS level.  It works on the block
> device (i.e. IOCTL) level.

I think there's reason to read extra clusters in the FAT chain rather than
next physically neighboring sectors. So SMARTDRV must work on DOS level in
order to provide better performance.

Good Luck