From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Hardware Interrupt Latency in Protected Mode?
Date:	Fri, 11 Jul 2003 19:01:32 CDT
Organization:	Rice University, Houston, TX
Lines:	24
Message-ID:	<3f0f4fdc.sandmann@clio.rice.edu>
References:	<78a4a70a DOT 0307080821 DOT bdb7edb AT posting DOT google DOT com>
NNTP-Posting-Host:	clio.rice.edu
X-Trace:	joe.rice.edu 1057968425 9787 128.42.105.3 (12 Jul 2003 00:07:05 GMT)
X-Complaints-To:	abuse AT rice DOT edu
NNTP-Posting-Date:	Sat, 12 Jul 2003 00:07:05 +0000 (UTC)
X-NewsEditor:	ED-1.5.9
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

> Both programs are compiled by DJGPP v2.03, gcc 3.23. DPMI host is
> CWSDPMI v5. I use CWSPARAM to disable virtual memory, so no paging
> will occur. And in program (2), ALL hareware interrupt are disabled
> expect IRQ7, main() is an infinite loop: for (;;) {}. Therefore,
> technically, no mode switching will occur in program (2) during test.

> I use logical analyzer to capture the interrupt latency (time between
> the low-to-high edge of interrupt source signal from program (1) to
> low-to-high edge of signal from program (2)). Normally, the latency is
> less than 6 microseconds, which is really reasonable. However,
> sometimes (in 1 or 2 hours), a very large latency, 30 to 60
> microseconds, can be observed. 

There is nothing in the software which should caus this to happen.
I suspect that something in the hardware triggers this - maybe a
NMI - or a bus reset.

You might try PMODE (which has an even lower latency) to see how it
works for you.  Since it doesn't enable paging, maybe the hardware
will respond differently, I don't know.

- Raw text -