Mail Archives: djgpp/2001/01/30/20:36:37.1
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.
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?
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?
Sent via Deja.com
http://www.deja.com/
- Raw text -