Worstcase interrupt latency

What’s the longest time the Neutrino kernel or a QNX system process holds
interrupts disabled for? I’m trying to budget the time I have to respond to
a particular event, and I need to know the worst case situation for
interrupt latency.

Thanks,
Shaun

Shaun Jackman wrote:

What’s the longest time the Neutrino kernel or a QNX system process holds
interrupts disabled for? I’m trying to budget the time I have to respond to
a particular event, and I need to know the worst case situation for
interrupt latency.

Thanks,
Shaun

Worst case response time depends on so many factors, the only reasonable
way to get a “budget figure” for worst case interrupt latency is to test
it on your target hardware (Oscilloscope/Logic analyser). If there are
any specific anomalies in the results you obtain, then please post
specifics here. I am sure that the audience reading this group is quite
interested; and willing to help isolate whatever issues you encounter. If
you are interested in a relative comparison of QNX vs. other RTOS’s, then
you might be interested in downloading the free Dedicated Systems RTOS
evaluation project report concerning QNX. In the excerpts section of that
report, there is a graph of measured interrupt latencies on a particular
hardware configuration (worst case happens to be 3 us on the test platform

  • for whatever that is worth).

This is how I measure latency- I probe the interrupt request signal on the bus
(e.g. on the ISA bus the IRQ?? signal, on the PCI the INTA# signal) with a
digital oscilloscope (e.g. the Tek DPS scopes are excellent). You usually
need an extender card to do this, especially on the
PCI bus where the INTA# lines can be different for each slot. I make sure that
in my test interrupt routine I reset the interrupt request first thing, which then
results in the deassertion of the IRQ?? or INTA# bus signal. I set the persistance
and intensity on the oscilloscope to max so that it will store everything. This way I can see
the longest assertion of the interrupt request signal even if it happens only once.
Then under these conditions the longest assertion of the interrupt request signal is the
maximum, worst case latency.
During the test I will try to cause other drivers to execute- e.g. I will do NFS transfers
to disk which causes both the disk driver and network driver to run. I also do
a lot of scrolling which tests the video driver.

Be aware that the PCI uses shared interrupts. If your card is sharing an interrupt with
a PCI motherboard device (e.g. the USB, video, onboard ethernet) you will get bad
results if the other device is active.

“Rennie Allen” <rallen@csical.com> wrote in message news:ai7c78$im8$1@tiger.openqnx.com

Shaun Jackman wrote:

What’s the longest time the Neutrino kernel or a QNX system process holds
interrupts disabled for? I’m trying to budget the time I have to respond to
a particular event, and I need to know the worst case situation for
interrupt latency.

Thanks,
Shaun

Worst case response time depends on so many factors, the only reasonable
way to get a “budget figure” for worst case interrupt latency is to test
it on your target hardware (Oscilloscope/Logic analyser). If there are
any specific anomalies in the results you obtain, then please post
specifics here. I am sure that the audience reading this group is quite
interested; and willing to help isolate whatever issues you encounter. If
you are interested in a relative comparison of QNX vs. other RTOS’s, then
you might be interested in downloading the free Dedicated Systems RTOS
evaluation project report concerning QNX. In the excerpts section of that
report, there is a graph of measured interrupt latencies on a particular
hardware configuration (worst case happens to be 3 us on the test platform

  • for whatever that is worth).