From: "Alexei A. Frounze" <dummy_addressee AT hotmail DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DJGPP timer slowdown
Date: Tue, 30 Jan 2001 22:38:20 -0500
Lines: 62
Message-ID: <95819a$g08aj$1@ID-57378.news.dfncis.de>
References: <3a66161d DOT 226362160 AT news DOT sci DOT fi> <945a90$ckgq1$1 AT ID-57378 DOT news DOT dfncis DOT de> <3a6746e4 DOT 36130587 AT news DOT sci DOT fi> <947nrf$cdrkr$1 AT ID-57378 DOT news DOT dfncis DOT de> <3a6775dd DOT 9880436 AT news DOT sci DOT fi> <947ugl$cr0q9$1 AT ID-57378 DOT news DOT dfncis DOT de> <957onh$6iv$1 AT nnrp1 DOT deja DOT com>
NNTP-Posting-Host: ip250.rochester6.ny.pub-ip.psi.net (38.26.84.250)
X-Trace: fu-berlin.de 980912236 16785747 38.26.84.250 (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

<dcasale AT my-deja DOT com> wrote in message news:957onh$6iv$1 AT nnrp1 DOT deja DOT com...
> In article <947ugl$cr0q9$1 AT ID-57378 DOT news DOT dfncis DOT de>,
>   "Alexei A. Frounze" <dummy_addressee AT hotmail DOT com> wrote:
> > "Lasse Kärkkäinen / Tronic" <tronic2 AT sci DOT fi DOT don'tSPAMmeBUTremoveTHIS>
> wrote
> > in message news:3a6775dd DOT 9880436 AT news DOT sci DOT fi...
> > > Yep. That's not a problem, because I'm develeloping a benchmark for
> > > DOS-use.
> >
> > 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.

Perhaps this is the case. You may always carry out a few experiments and
often find out what's going on.

Unless you dig into quantum mechanics, everything has a reason for which it
happens and there's a possibility to name the reason. In quantum mechanics
you deal with probabilities, Heisenberg relation and similar stuff and this
is an exciting feature of the micro world... Even though, this doesn't
appear to us in the usual life like that but it's what happens inside. Cool,
isn't it? Somebody said (was it Einstain?): The god doesn't play dice. For
sure he plays, if he exists. :)

> 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, or is it just SmartDrive that's the culprit?

I've never heard about that...

> Damon Casale, damon AT WRONG DOT redshift DOT com (remove the obvious)
> If someone slowed down every clock in the universe by an equal
> proportion, would anyone notice?

Perhaps "by an equal *value*" would be more reasonable (or did I get you
wrong?). :)

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/