Date: Wed, 31 Jan 2001 10:36:49 +0200 (IST) From: Eli Zaretskii 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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.