Hardware Interrupt Latency in Protected Mode?

Hardware Interrupt Latency in Protected Mode?

Post by Wang Yo » Thu, 10 Jul 2003 01:21:45



Dear all,

I am trying to find out the hardware interrupt latency in protected
mode. The test is as followings:
1. test program (1) works as a clock generator to make 4Khz square
wave, CPU is P4 Celeron 1.7GHz;
2. test program (2) runs on another computer (PIII 933MHz). It sets
ISR for IRQ7 in protected
mode(_go32_dpmi_set_protected_mode_interrupt_vector(), no interrupt
chain). The square wave from test program (1) connects to its IRQ7,
ISR sets parallel port to 1 when entering, and reset to 0 when
leaving.
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. I am not sure if anybody did the same
test in DJGPP. Any similiar or better data? Or anybody find the same
sudden large latency? And what steps should be strictly foloowed to
restrain the latency in an acceptable range, such as < 10
microseconds?

Thanks for your patience and I am looking for your reply.

Sincerely,
Wang Yong

 
 
 

Hardware Interrupt Latency in Protected Mode?

Post by Charles Sandman » Sun, 13 Jul 2003 04:01:32


Quote:> 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.

 
 
 

Hardware Interrupt Latency in Protected Mode?

Post by Wang Yo » Sun, 13 Jul 2003 20:18:43


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


> > 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.

 
 
 

Hardware Interrupt Latency in Protected Mode?

Post by Charles Sandman » Mon, 14 Jul 2003 17:27:34


Quote:> 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.

PMODE uses a completely different code base - so if you are seeing
a similar result I suspect it's something in the hardware or BIOS
configuration.

Quote:> 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?

NMI can be generated by the hardware for many reasons - for everything
from memory errors to "advanced" functions like power management and
other "green" PC functions.

Depending on your system, you might have ECC memory - which the
chip set (not CPU) manages (should be very infrequent) errors, which
would would cause a delay while it is being processed.  There will
be similar low level error handling when communicating with other
peripherals.

Quote:> 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?

Some of the problem is bad BIOS, but some is just new features
which make them more Windows specific and less general purpose.
I've also seen the average quality of some of the legacy parts
(parallel, serial, floppy) drop over the last few years.
Sometimes a machine from a different manufacturer will work better.

Quote:> But programms running in
> pure protected mode will not call any BIOS funcitons, right?

If you take complete control of the interrupt table and replace ALL
of the vectors, you can be sure you will stay in protected mode.

Quote:> Is it possible to get an interrupt response time within small range in
> protected mode? so tough...

Yes, but you many end up having to use a different computer.
 
 
 

Hardware Interrupt Latency in Protected Mode?

Post by Eli Zaretski » Tue, 15 Jul 2003 05:00:46



> Newsgroups: comp.os.msdos.djgpp
> Date: 8 Jul 2003 09:21:45 -0700

> 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.

Sounds like some code in the BIOS.  BIOS is known to disable
interrupts for prolonged periods of time; I've seen similar problems
on occasion.  Disk I/O is the usual culprit.

Can you post the details of your system configuration (CONFIG.SYS,
AUTOEXEC.BAT, etc.)?

Quote:> And what steps should be strictly foloowed to
> restrain the latency in an acceptable range, such as < 10
> microseconds?

Unfortunately, I didn't find any work-around for this, except to
prevent the relevant BIOS code from running (which is not always
possible, alas).
 
 
 

Hardware Interrupt Latency in Protected Mode?

Post by Eli Zaretski » Tue, 15 Jul 2003 05:04:16



> Newsgroups: comp.os.msdos.djgpp
> Date: 12 Jul 2003 04:18:43 -0700

> But programms running in pure protected mode will not call any BIOS
> funcitons, right?

Wrong, unfortunately: the system will run BIOS code even if your
program doesn't.  For example, the timer tick interrupt runs its BIOS
handler 18.2 times a second.  And some resident software could cause
the disk to seek every now and then.

Quote:> Is it possible to get an interrupt response time within small range in
> protected mode? so tough...

I think your problem has nothing to do with PM.  If some BIOS code
disables interrupts for 20 msec, there's nothing you can do to avoid
the latency.  I've seen this happen with pure real-mode data-capture
program I once wrote.
 
 
 

Hardware Interrupt Latency in Protected Mode?

Post by Wang Yo » Wed, 16 Jul 2003 04:32:17


Thanks for your reply.

DOS in my computer is configurated as simple as possible. In fact, I
tried it in both FreeDOS and MSDOS. In config.sys, only
    files=20
    buffer=20
In autoexec.bat, only path is set.
When running my test program, *ALL* maskable interrupts are disabled
except IRQ7. And in my code, no chance to change to real-mode. Memory
is normal NON-ECC memory. However, since the computer is an industrial
PC, a lot of modules are integrated on the motherboard, such as
network controller (Intel 82559). With the help of both of you, I can
make sure that it's the hardware problem. But it's really difficult to
figure it out that which part causes the problem.

I will do the same experiment on some old computers. And if you are
interested, I'll post the result.

Thanks again.

Sincerely,
Wang Yong



> > Newsgroups: comp.os.msdos.djgpp
> > Date: 8 Jul 2003 09:21:45 -0700

> > 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.

> Sounds like some code in the BIOS.  BIOS is known to disable
> interrupts for prolonged periods of time; I've seen similar problems
> on occasion.  Disk I/O is the usual culprit.

> Can you post the details of your system configuration (CONFIG.SYS,
> AUTOEXEC.BAT, etc.)?

> > And what steps should be strictly foloowed to
> > restrain the latency in an acceptable range, such as < 10
> > microseconds?

> Unfortunately, I didn't find any work-around for this, except to
> prevent the relevant BIOS code from running (which is not always
> possible, alas).

 
 
 

Hardware Interrupt Latency in Protected Mode?

Post by Alex Yeryom » Wed, 16 Jul 2003 15:55:52


Dear Wang Yong,

we have the same problem with real-time program on industrial microPC
(CPU686E unit, Geode GX1-300MHz processor, onboard flash disk,
built-in Ethernet10/100 Base-T, from Fastwel / National Semiconductor
Co).

In short word, this program gets interrupt 'start' signal from outside
then runs ADC, gets 'stop' signal and breaks ADC. Depending on ADC's
samples we culcutale some results. We should be sure that there is no
delay (or it is very small) between 'start' signal and when ADC runs.
To catch any delay, we use nanosecond oscillograph. And, as a rule, no
delay is observed. Really, we found that the delay varies a litte,
from 5 to 30 mks. Is it OK for us, because we do not disable any
interrupts and do not re-program Intel 8259 Interrupt Controller, it
works as is after startup. (By the way, we use 'rdtsc' command to
measure time intervals with high precision).

But sometimes we found that the delay is unexpectedly >80 mks! It
happens in irregular way. We tried to understand but with no success.
So, we are forced to live with that. :-(

If you will be more lucky to understand what happens and, more, how to
fix this problem, please let me know.

Alex

 
 
 

Hardware Interrupt Latency in Protected Mode?

Post by Wang Yo » Wed, 16 Jul 2003 20:30:39


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.

Sincerely,
Wang Yong


> Dear Wang Yong,

> we have the same problem with real-time program on industrial microPC
> (CPU686E unit, Geode GX1-300MHz processor, onboard flash disk,
> built-in Ethernet10/100 Base-T, from Fastwel / National Semiconductor
> Co).

> In short word, this program gets interrupt 'start' signal from outside
> then runs ADC, gets 'stop' signal and breaks ADC. Depending on ADC's
> samples we culcutale some results. We should be sure that there is no
> delay (or it is very small) between 'start' signal and when ADC runs.
> To catch any delay, we use nanosecond oscillograph. And, as a rule, no
> delay is observed. Really, we found that the delay varies a litte,
> from 5 to 30 mks. Is it OK for us, because we do not disable any
> interrupts and do not re-program Intel 8259 Interrupt Controller, it
> works as is after startup. (By the way, we use 'rdtsc' command to
> measure time intervals with high precision).

> But sometimes we found that the delay is unexpectedly >80 mks! It
> happens in irregular way. We tried to understand but with no success.
> So, we are forced to live with that. :-(

> If you will be more lucky to understand what happens and, more, how to
> fix this problem, please let me know.

> Alex

 
 
 

Hardware Interrupt Latency in Protected Mode?

Post by DJ Delori » Thu, 17 Jul 2003 00:07:51


Quote:> But sometimes we found that the delay is unexpectedly >80 mks! It
> happens in irregular way. We tried to understand but with no success.
> So, we are forced to live with that. :-(

Have you accounted for DRAM refreshes, bus masters, and all that?
 
 
 

Hardware Interrupt Latency in Protected Mode?

Post by Andris Paveni » Thu, 17 Jul 2003 03:20:02



Quote:> 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

 
 
 

1. Hardware Interrupt Latency of DOS Extender?

I'm writing software for control system and my target is based on PC.
I'm considering about using DOS Extender so I can run application in
32-bit mode,
and wondering what's the min. latency for hardware interrupt? If using
DOS Extender isn't a good solution(to run 32-bit), what might be a good
one to minimize hardware interrupt latency?

Thanks.

Tim

2. Training CD's

3. Hook hardware interrupt in protected mode?

4. High Performance OS/2 IDE Upgrade

5. Protected mode hardware interrupt processing

6. Warning!!!--Fixing Scratched Disc's

7. Calling Real Mode Interrupt from Watcom C32 (Protected Mode)

8. HP DeskJet 1100C Windows only printer ?

9. Calling Real Mode interrupt driver (TSR) from Protected Mode

10. help needed: real mode interrupts in protected mode

11. Hardware Emulation in Protected Mode

12. Interrupt latency prob.

13. DPMI Interrupt latency ?