Date:	Wed, 31 Jan 2001 10:36:49 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp AT delorie DOT com
Subject:	Re: DJGPP timer slowdown
In-Reply-To:	<957onh$6iv$1@nnrp1.deja.com>
Message-ID:	<Pine.SUN.3.91.1010131103626.29266V-100000@is>
MIME-Version:	1.0
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

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

Could someone please explain what this is all about?

> By the way, a friend of mine made the suggestion that calling a disk
> access interrupt (such as INT13h, AH=0x42h or AH=0x43h) and reading or
> writing a lot of sectors in a 32-bit protected mode program might cause
> timer ticks to be lost during the interrupt.  Does anyone know if this
> might be the case

First, no DJGPP library function calls functions 42h or 43h of Int 13h.

Second, AFAIK, the BIOS doesn't disable interrupts for prolonged
periods of time (unlike DOS), so I don't think timer ticks can be
lost.

And third, I don't see how protected-mode programs are relevant here,
since the BIOS function is called after switching the CPU to real mode
anyway.

> or is it just SmartDrive that's the culprit?

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

- Raw text -