delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2003/07/15/14:19:24

From: Andris Pavenis <pavenis AT latnet DOT lv>
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
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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019