From: Charles Sandmann 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.