? on QNX 4.25 Interrupt Service Inhibiting or Delays

We are working with a system that performs time capture with a 1 microsecond
resolution when an interrupt is serviced.
We inject a test interrupt trigger on a periodic basis with an accuracy of
+/- 15 microseconds.
Captured time data shows varying interrupt service latencies from of 5 to
220 microseconds.
The interrupt service process is set at the highest priority (29).
The interrupt service process captures the time ( 8 inport calls) and exits.
PROC_32 is set to (26)
Our processor is a Pentium 166.
We are setting up some test cases to isolate this part of our application
but are interested in any experience that anyone else may have had with
interrupt blocking or latencies.

Is anyone aware of any reason or observation that QNX would inhibit or delay
interrupt servicing?

Bob Blair
WINTEC Inc
rblair@wintec-inc.com

You might also want to make sure that this interrupt is the highest priority
interrupt!

(Options to proc, I believe)

Other interrupt service routines may be introducing the latencies.


Bob Blair <rblair@wintec-inc.com> wrote in message
news:8trrg2$39b$1@inn.qnx.com

We are working with a system that performs time capture with a 1
microsecond
resolution when an interrupt is serviced.
We inject a test interrupt trigger on a periodic basis with an accuracy of
+/- 15 microseconds.
Captured time data shows varying interrupt service latencies from of 5 to
220 microseconds.
The interrupt service process is set at the highest priority (29).
The interrupt service process captures the time ( 8 inport calls) and
exits.
PROC_32 is set to (26)
Our processor is a Pentium 166.
We are setting up some test cases to isolate this part of our application
but are interested in any experience that anyone else may have had with
interrupt blocking or latencies.

Is anyone aware of any reason or observation that QNX would inhibit or
delay
interrupt servicing?

Bob Blair
WINTEC Inc
rblair@wintec-inc.com

Bob Blair <rblair@wintec-inc.com> wrote:

We are working with a system that performs time capture with a 1 microsecond
resolution when an interrupt is serviced.
We inject a test interrupt trigger on a periodic basis with an accuracy of
+/- 15 microseconds.
Captured time data shows varying interrupt service latencies from of 5 to
220 microseconds.
The interrupt service process is set at the highest priority (29).
The interrupt service process captures the time ( 8 inport calls) and exits.
PROC_32 is set to (26)
Our processor is a Pentium 166.
We are setting up some test cases to isolate this part of our application
but are interested in any experience that anyone else may have had with
interrupt blocking or latencies.

Is anyone aware of any reason or observation that QNX would inhibit or delay
interrupt servicing?

  • something disables interrupts
  • there is a higher priority interrupt being processed
  • there are other interrupts being processed

What interrupt is yours using? What is the highest priority irq on the
machine? (Default is irq 3, can be modified with command line option to
Proc32.) What else is using interrupts? (sin irq)

-David

Thanks for your inputs.

We are using interrupt 5.
Interrupts 3 and 4 are not used in our system (we do not have a mouse
attached and Network cards are at higher interrupts)
Nesting is enabled and we will try setting int 5 as the default for proc32.
We do not explicitly do anything to inhibit interrupt operation.

We are still working to quantify latency performance on our system as well
as workarounds to using interrupts.
I will post any usefull test results I obtain.

Bob

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:8ts84u$njh$4@nntp.qnx.com

Bob Blair <> rblair@wintec-inc.com> > wrote:
We are working with a system that performs time capture with a 1
microsecond
resolution when an interrupt is serviced.
We inject a test interrupt trigger on a periodic basis with an accuracy
of
+/- 15 microseconds.
Captured time data shows varying interrupt service latencies from of 5
to
220 microseconds.
The interrupt service process is set at the highest priority (29).
The interrupt service process captures the time ( 8 inport calls) and
exits.
PROC_32 is set to (26)
Our processor is a Pentium 166.
We are setting up some test cases to isolate this part of our
application
but are interested in any experience that anyone else may have had with
interrupt blocking or latencies.

Is anyone aware of any reason or observation that QNX would inhibit or
delay
interrupt servicing?

  • something disables interrupts
  • there is a higher priority interrupt being processed
  • there are other interrupts being processed

What interrupt is yours using? What is the highest priority irq on the
machine? (Default is irq 3, can be modified with command line option to
Proc32.) What else is using interrupts? (sin irq)

-David

Bob Blair <rblair@wintec-inc.com> wrote:

Thanks for your inputs.

We are using interrupt 5.
Interrupts 3 and 4 are not used in our system (we do not have a mouse
attached and Network cards are at higher interrupts)
Nesting is enabled and we will try setting int 5 as the default for proc32.
We do not explicitly do anything to inhibit interrupt operation.

We are still working to quantify latency performance on our system as well
as workarounds to using interrupts.
I will post any usefull test results I obtain.

Something else we’ve just start to get suspicous about internally is
SMM (System Management Mode) on x86 systems – where the BIOS can take
over control of the machine for a period of time, and it isn’t under control
of the OS. We are doing some investigation currently.

-David


Bob

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:8ts84u$njh$> 4@nntp.qnx.com> …
Bob Blair <> rblair@wintec-inc.com> > wrote:
We are working with a system that performs time capture with a 1
microsecond
resolution when an interrupt is serviced.
We inject a test interrupt trigger on a periodic basis with an accuracy
of
+/- 15 microseconds.
Captured time data shows varying interrupt service latencies from of 5
to
220 microseconds.
The interrupt service process is set at the highest priority (29).
The interrupt service process captures the time ( 8 inport calls) and
exits.
PROC_32 is set to (26)
Our processor is a Pentium 166.
We are setting up some test cases to isolate this part of our
application
but are interested in any experience that anyone else may have had with
interrupt blocking or latencies.

Is anyone aware of any reason or observation that QNX would inhibit or
delay
interrupt servicing?

  • something disables interrupts
  • there is a higher priority interrupt being processed
  • there are other interrupts being processed

What interrupt is yours using? What is the highest priority irq on the
machine? (Default is irq 3, can be modified with command line option to
Proc32.) What else is using interrupts? (sin irq)

-David

Can you tell me the exact make and model ( including revision) of the mother board?
As David mentioned we suspect that smm is geting called and we need a board that does this for testing. Have you disabled usb support in the bios ( usb is EVIL it polls for devices)

Is there a small test case we can try here?


Previously, David Gibbs wrote in comp.os.qnx:
{ Bob Blair <rblair@wintec-inc.com> wrote:
{ > Thanks for your inputs.
{
{ > We are using interrupt 5.
{ > Interrupts 3 and 4 are not used in our system (we do not have a mouse
{ > attached and Network cards are at higher interrupts)
{ > Nesting is enabled and we will try setting int 5 as the default for proc32.
{ > We do not explicitly do anything to inhibit interrupt operation.
{
{ > We are still working to quantify latency performance on our system as well
{ > as workarounds to using interrupts.
{ > I will post any usefull test results I obtain.
{
{ Something else we’ve just start to get suspicous about internally is
{ SMM (System Management Mode) on x86 systems – where the BIOS can take
{ over control of the machine for a period of time, and it isn’t under control
{ of the OS. We are doing some investigation currently.
{
{ -David


Pat Ford email: pford@qnx.com
QNX Software Systems, Ltd. WWW: http://www.qnx.com
(613) 591-0931 (voice) mail: 175 Terence Matthews
(613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8

A year or so ago I was working with a Cyrix GMX processor
on the NS Webpad. We saw just this kind of behavior related
to SMM. The chip emulated a SoundBlaster as well as some
of the video modes. There were some native video modes which
I believe helped.

From my brief discussions with someone more knowledgable,
there is NO way to mask the SMM. In fact there should be no
way to detect its operation other than the cpu latencies.


Previously, Pat Ford wrote in comp.os.qnx:

Can you tell me the exact make and model ( including revision) of the mother board?
As David mentioned we suspect that smm is geting called and we need a board that does this for testing. Have you disabled usb support in the bios ( usb is EVIL it polls for devices)

Mitchell Schoenbrun --------- maschoen@pobox.com

Previously, Mitchell Schoenbrun wrote in comp.os.qnx:
{ A year or so ago I was working with a Cyrix GMX processor
{ on the NS Webpad. We saw just this kind of behavior related
{ to SMM.

Thanks another data point

{The chip emulated a SoundBlaster as well as some
{ of the video modes. There were some native video modes which
{ I believe helped.
{
{ From my brief discussions with someone more knowledgable,
{ there is NO way to mask the SMM. In fact there should be no
{ way to detect its operation other than the cpu latencies.

Close but, the oiapic ( example the i82093AA) is just a fancy 8259
you can write to its registers.

{
{
{ Previously, Pat Ford wrote in comp.os.qnx:
{ > Can you tell me the exact make and model ( including revision) of the mother board?
{ > As David mentioned we suspect that smm is geting called and we need a board that does this for testing. Have you disabled usb support in the bios ( usb is EVIL it polls for devices)
{
{ Mitchell Schoenbrun --------- maschoen@pobox.com
{
{


Pat Ford email: pford@qnx.com
QNX Software Systems, Ltd. WWW: http://www.qnx.com
(613) 591-0931 (voice) mail: 175 Terence Matthews
(613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8