From: atlas_wang AT yahoo DOT com (Wang Yong) Newsgroups: comp.os.msdos.djgpp Subject: Re: Hardware Interrupt Latency in Protected Mode? Date: 12 Jul 2003 04:18:43 -0700 Organization: http://groups.google.com/ Lines: 44 Message-ID: <78a4a70a.0307120318.2d3e8ce@posting.google.com> References: <78a4a70a DOT 0307080821 DOT bdb7edb AT posting DOT google DOT com> <3f0f4fdc DOT sandmann AT clio DOT rice DOT edu> NNTP-Posting-Host: 202.156.2.218 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1058008724 32173 127.0.0.1 (12 Jul 2003 11:18:44 GMT) X-Complaints-To: groups-abuse AT google DOT com NNTP-Posting-Date: 12 Jul 2003 11:18:44 GMT To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Thanks for your reply! In fact, I really did the experiment again and again. I changed the interrupt source to a function generator, which can provide more stable square wave. And I tried PMODE, too. But similiar result was got. I am not clear with NMI or bus reset. In what cases NMI or bus reset will be triggered? In my mind, only power off can trigger NMI. But how about bus reset? Actually, I find that some dos programs have strange behaviors in new CPUs, such as P3 or P4, but work well in some old Pentium systems. Maybe it is due to the bad design of bios? But programms running in pure protected mode will not call any BIOS funcitons, right? Is it possible to get an interrupt response time within small range in protected mode? so tough... Sincerely, Wang Yong Charles Sandmann wrote in message news:<3f0f4fdc DOT sandmann AT clio DOT rice DOT edu>... > > 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.