Interrupt Latency and Scheduling Latency

QNX Newsgroups (Archives) qdn.public.qnx4
1

Hi,

We are currently working on a project that requires implementation of
time deterministic monitoring and control of a missile launcher. We have
already discussed the project requirements with our client. Based on the
discussion we have completed our work on software design documents.

The user is familiar with Vxworks and understands the functioning of
RTOS. He wants us to confirm the interrupt latency and scheduling latency
for QNX RTOS. We checked up QNX 4.25 documentation for the info about this.
We have noted that the interrupt latency and scheduling latency are
specified in microseconds. What we do not undertand is how to prove that
these durations are actually as per the documentation.

If anyone has tried to confirm the latency durations for QNX, kindly
comment on this issue. It would help if someone can suggest a method for
confirming the typical latencies specified in the QNX documents.

Thanks in advance,
Krupa

2

Krupa (krupah@hotmail.com) wrote:
: Hi,

: We are currently working on a project that requires implementation of
: time deterministic monitoring and control of a missile launcher. We have
: already discussed the project requirements with our client. Based on the
: discussion we have completed our work on software design documents.

: The user is familiar with Vxworks and understands the functioning of
: RTOS. He wants us to confirm the interrupt latency and scheduling latency
: for QNX RTOS. We checked up QNX 4.25 documentation for the info about this.
: We have noted that the interrupt latency and scheduling latency are
: specified in microseconds. What we do not undertand is how to prove that
: these durations are actually as per the documentation.

: If anyone has tried to confirm the latency durations for QNX, kindly
: comment on this issue. It would help if someone can suggest a method for
: confirming the typical latencies specified in the QNX documents.

How crude do you want to get? In a previous life, I built a hardware
testjig that did just this (not for QNX, but for an 8051 microcontroller).
Basically, you take a dual trace oscilloscope, and a programmable pulse
generator. Hook the pulse generator to an interrupt line and one of the
scope inputs. Create an interrupt service routine that toggles some
hardware that’s connected to the second trace input. Watch and enjoy.

For scheduling latency, arrange two processes so that one causes the other
to be scheduled (however you wish to define that – send it a message,
a proxy, a signal, whatever). Have both processes tickle oscilloscope
lines.

It’s not the prettiest, but it works :slight_smile:

Cheers,
-RK

–

Robert Krten, PARSE Software Devices; email my initials at parse dot com
Consulting, Systems Architecture / Design, Drivers, Training, QNX 4 & Neutrino
Check out our new QNX 4 and Neutrino (QRTP) books at http://www.parse.com/
Wanted PDP-8/9/10/11/12 Systems/documentation/spare parts! Will trade books!

3

You could also use DejaView to get the scheduling latency, but AFAIK,
outside of an ICE, the method that Rob describes is the only way to get
an accurate interrupt latency measurement.

-----Original Message-----
From: nospam2@parse.com (Robert Krten) [mailto:nospam2@parse.com]
Posted At: Tuesday, August 28, 2001 11:10 AM
Posted To: qnx4
Conversation: Interrupt Latency and Scheduling Latency
Subject: Re: Interrupt Latency and Scheduling Latency


Krupa (krupah@hotmail.com) wrote:
: Hi,

: We are currently working on a project that requires
implementation of
: time deterministic monitoring and control of a missile launcher. We
have
: already discussed the project requirements with our client. Based on
the
: discussion we have completed our work on software design documents.

: The user is familiar with Vxworks and understands the functioning
of
: RTOS. He wants us to confirm the interrupt latency and scheduling
latency
: for QNX RTOS. We checked up QNX 4.25 documentation for the info about
this.
: We have noted that the interrupt latency and scheduling latency are
: specified in microseconds. What we do not undertand is how to prove
that
: these durations are actually as per the documentation.

: If anyone has tried to confirm the latency durations for QNX,
kindly
: comment on this issue. It would help if someone can suggest a method
for
: confirming the typical latencies specified in the QNX documents.

How crude do you want to get? In a previous life, I built a hardware
testjig that did just this (not for QNX, but for an 8051
microcontroller).
Basically, you take a dual trace oscilloscope, and a programmable pulse
generator. Hook the pulse generator to an interrupt line and one of the
scope inputs. Create an interrupt service routine that toggles some
hardware that’s connected to the second trace input. Watch and enjoy.

For scheduling latency, arrange two processes so that one causes the
other
to be scheduled (however you wish to define that – send it a message,
a proxy, a signal, whatever). Have both processes tickle oscilloscope
lines.

It’s not the prettiest, but it works :slight_smile:

Cheers,
-RK

–

Robert Krten, PARSE Software Devices; email my initials at parse dot com
Consulting, Systems Architecture / Design, Drivers, Training, QNX 4 &
Neutrino
Check out our new QNX 4 and Neutrino (QRTP) books at
http://www.parse.com/
Wanted PDP-8/9/10/11/12 Systems/documentation/spare parts! Will trade
books!

4

Hello Rennie

Is DejaVuew an offically released product for QNX 4?

Bill Caroselli

“Rennie Allen” <RAllen@csical.com> wrote in message
news:64F00D816A85D51198390050046F80C9A43E@exchangecal.hq.csical.com…

You could also use DejaView to get the scheduling latency, but AFAIK,
outside of an ICE, the method that Rob describes is the only way to get
an accurate interrupt latency measurement.

5

something else that is useful is the use of the rdtsc instruction available
on pentium processors. gives you 1/clockspeed free running timer resolution.

there are sources and test code available in an archive called sysdbg.tgz
in the free software section of our site.

i recommend this archive to anyone doing qnx4 realtime work… it can
let you finely determine the time between qnx receiving the interrupt and
the running of your handler, plus the readying of your main program via
proxy trigger.

but as rennie and rob have said, the only true way to determine interrupt
latency is from an external source of interrupts and a scope.


Rennie Allen <RAllen@csical.com> wrote:

You could also use DejaView to get the scheduling latency, but AFAIK,
outside of an ICE, the method that Rob describes is the only way to get
an accurate interrupt latency measurement.

-----Original Message-----
From: > nospam2@parse.com > (Robert Krten) [mailto:> nospam2@parse.com> ]
Posted At: Tuesday, August 28, 2001 11:10 AM
Posted To: qnx4
Conversation: Interrupt Latency and Scheduling Latency
Subject: Re: Interrupt Latency and Scheduling Latency



Krupa (> krupah@hotmail.com> ) wrote:
: Hi,

: We are currently working on a project that requires
implementation of
: time deterministic monitoring and control of a missile launcher. We
have
: already discussed the project requirements with our client. Based on
the
: discussion we have completed our work on software design documents.

: The user is familiar with Vxworks and understands the functioning
of
: RTOS. He wants us to confirm the interrupt latency and scheduling
latency
: for QNX RTOS. We checked up QNX 4.25 documentation for the info about
this.
: We have noted that the interrupt latency and scheduling latency are
: specified in microseconds. What we do not undertand is how to prove
that
: these durations are actually as per the documentation.

: If anyone has tried to confirm the latency durations for QNX,
kindly
: comment on this issue. It would help if someone can suggest a method
for
: confirming the typical latencies specified in the QNX documents.

How crude do you want to get? In a previous life, I built a hardware
testjig that did just this (not for QNX, but for an 8051
microcontroller).
Basically, you take a dual trace oscilloscope, and a programmable pulse
generator. Hook the pulse generator to an interrupt line and one of the
scope inputs. Create an interrupt service routine that toggles some
hardware that’s connected to the second trace input. Watch and enjoy.

For scheduling latency, arrange two processes so that one causes the
other
to be scheduled (however you wish to define that – send it a message,
a proxy, a signal, whatever). Have both processes tickle oscilloscope
lines.

It’s not the prettiest, but it works > :slight_smile:

Cheers,
-RK

–

Robert Krten, PARSE Software Devices; email my initials at parse dot com
Consulting, Systems Architecture / Design, Drivers, Training, QNX 4 &
Neutrino
Check out our new QNX 4 and Neutrino (QRTP) books at
http://www.parse.com/
Wanted PDP-8/9/10/11/12 Systems/documentation/spare parts! Will trade
books!

–
Randy Martin randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579