From: Andris Pavenis To: djgpp AT delorie DOT com, atlas_wang AT yahoo DOT com (Wang Yong) Subject: Re: Hardware Interrupt Latency in Protected Mode? Date: Tue, 15 Jul 2003 21:20:02 +0300 User-Agent: KMail/1.5.2 References: <78a4a70a DOT 0307080821 DOT bdb7edb AT posting DOT google DOT com> <96eb2770 DOT 0307142255 DOT 37239f2f AT posting DOT google DOT com> <78a4a70a DOT 0307150330 DOT 81156e0 AT posting DOT google DOT com> In-Reply-To: <78a4a70a.0307150330.81156e0@posting.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307152120.03120.pavenis@latnet.lv> Reply-To: djgpp AT delorie DOT com On Tuesday 15 July 2003 14:30, Wang Yong wrote: > Well, I am doing the same test on a very old industrial PC now, which > has Pentium 90, SiS chipset, ISA Graphic Card, no PCI slot. On board > there has only IDE, 2 serial ports, 1 parallel port, 2 PS/2 (keyboard > and mouse). No network card. OS is FreeDOS. Input is 4KHz square wave > from function generator. > > The singals are very stable observed from logical analyzer. Suppose > the time instant of nterrupt singal to IRQ7 is zero. Then the response > of ISR is about 6.x microseonds later, and ISR ends at 9.x > microseconds. And the testing program have been running for about 10 > hours. > > So, we can make sure that the sudden jitter of interrupt response time > in my previous post is due to hardware (or bios). I'll try to figure > out which part causes this problem. After all, the fact that new > generation of hardware gets bad result is really infrustrating. > I have one my old DOS real mode TSR for hardware control, which uses periodic interrupts generated by 8053 chip on some ISA board. As they are periodic with rather high accuracy (card takes frequency from atomic time standard, currently here it comes from hydrogen time standard), so I can look for interrupt jitter, by reading clock (analogous to uclock()) from interrupt procedure. Of course PC clock drifts, but I can fit main line with some function and to look for shifted events. Initially main control program was also real mode one. Now I'm using DJGPP for that. Changing to DJGPP increased a bit frequency of delayed interrupts, but max. delay was about 100 microseconds on old 486DX4100. I got similar increase when loaded EMM386. Majority of events fits in 5-10 microsecond range and only realtively very few were shifted more. Tests were done rather long time ago, so I may not remember accuratelly. It is of course different from handling interrupts in protected mode, but switching to real mode for interrupt and after that back requires additional time, but it didn't seem to be very noticeable I have thought about changing to Real Time Linux for that task (perhaps RTAI), but haven't even began to write anything. Andris