In the old days of real-time systems, you would buy a real-time computer
(like a modcomp) and they would provide you all the numbers for their
platform. Unfortunately, (or fortunately), with QNX supporting so many
different types of hardware, it is impossible for QSSL to provide these
numbers (other than baselines on some common hardware for comparisons).
The statement “latency is 1.38us for Pentium 200” refers only to the
kernels worst case interrupt dispatch latency on the specific processor.
This dispatch latency comes into play every time an interrupt (from any
source) occurs; thus the worst case delay that will be seen in practice
is (1.38 + longest handler exec time) * X (where X is the number of
hardware interrupts of a higher hardware priority than the one you are
interested in). Given this fact, it is impossible for any interrupt
(other than the highest hardware priority interrupt) to see an interrupt
dispatch latency of 1.38us on a Pentium 200.
The bottom line is that anyone developing a real-time system must
independently test (on the actual hardware in question) the execution
time of all handlers that have a higher hardware priority than the
handler for which a worst case time must be known, and do the above
calculation to determine what the worst case interrupt dispatch latency
will be in practice. QNX is a tool for developing real-time systems, it
does not do your work for you; it can’t (besides, that is why you get
the big bucks 
. It would be nice if QSSL quoted the worst-case
execution paths for all of their drivers, but this would serve only to
reduce the number of drivers that QSSL could afford to support (not a
desirable situation, since I use QNX for development time, as well as
deployment time, and I want as few restrictions as possible on the types
of hardware I can use on my development box).
Again, back in the modcomp days all the hardware was designed to be
real-time as well, nowadays QSSL (by customer demand) provides drivers
for hardware that is far from ideal for real-time systems (in fact
real-time behavior was often never even considered when the hardware was
designed). Once again, it is your responsibility to choose hardware
with appropriate characteristics for your application.
-----Original Message-----
From: Alex Guryanow [mailto:gav@ets.ifmo.ru]
Posted At: Tuesday, July 10, 2001 5:47 AM
Posted To: os
Conversation: interrupt latency
Subject: Re: interrupt latency
Markus Loffler wrote:
I couldn’t find any numbers there. Searching the knowledge base gave
me
http://qdn.qnx.com/support/bok/solution.qnx?9497
However, these are just avarage latencies, there are not so useful
considering Alex’ problems.
I think average latencies are necessary for nobody. If I build a
real-time
system then the customer can ask me how many time after issuing an
interrupt the
hardware will wait for data. How can I answer this question if I know
only
average latency? The average time is say 3us but may be it can be 3ms?
Or 3s? I
need to know the worsest time. Where can I find these values? Or how
they can be
calculated? I think that my case isn’t so difficult. Possible with
commercial
version of QNX is shipped a documentation with this data?
Alex
Markus
“Operating System for Tech Supp” <> os@qnx.com> > wrote in message
news:9i5025$nmd$> 1@nntp.qnx.com> …
Markus Loffler <> loffler@ces.clemson.edu> > wrote:
Where do you actually get the info "latency is 1.38us for Pentium
200)?
See the following doc in the helpviewer:
/QNX Neutrino OS 2.11/System Architecture/The Neutrino Microkernel/
Interrupt Handling/Interrupt Latency
Barry
Markus
“Alex Guryanow” <> gav@ets.ifmo.ru> > wrote in message
news:> 3B43259A.F4AA8C07@ets.ifmo.ru> …
Markus Loffler wrote:
Also, there has been done a lot of work regarding the latency
in the
kernel.
You should install RTP 6.1 right now. But please post again if
your
performance hasn’t changed.
I have just installed 6.1 and runned all tests again.
Unfortunately
nothing has
been changed.
Has anybody already played with interrupt priorities?
Last time I have forgotten to write that identical tests with
timer
when
it is
configured to send events each 999 847 ns gives evens worse
results
(about
2
times).
May be I do something wrong? Otherwise I do’t understand how can
be
built
a
predictable system using QNX!
Alex
Markus
“Alex Guryanow” <> gav@ets.ifmo.ru> > wrote in message
news:> 3B41D372.8D2241FE@ets.ifmo.ru> …
I have a standard QNX6 installation with patch C installed. I
have
writed a little test and now I’m confusing of its results. PC
with
QNX
has a self-made ISA card that issues an interrupt (11) every
ms. My
program gets the maximum FIFO-priority and sets an interrupt
handler
using InterruptAttach call. First what does interrupt handler
is
storing
the value from ClockCycles() in a statically allocated array
of 40
000
elements. When array is filled up the program detaches
interrupt
handler
and writes this array to file. After that I analyze this file
and
calculate intervals between each interrupt… and get strange
results:
- when test is running in Photon without any user activity
allmost
all
intervals are 1 ms, but sometimes (about every 6 seconds)
they are
greather : 1ms + ~66 us
- when test is running in Photon and user plays Doom these
deviations
are more often. Not all of them are so big (66us) but about
10
times
bigger than 1.38 us (as specified for 200 MHz Pentium)
- the same results I get when test is running in Photon, user
plays
Doom
and almost all processes (spooler, dumper, logger etc) are
killed
- when test is running in text mode and almost all processes
(same
as
upper +fontmanager) are killed the results are much better
but not
ideal: about every 10 seconds I see deviation in 6 us (what
is also
bigger than 1.38 us)
And here are my questions: is it normal for QNX to have so
big
interrupt
latency? Is it not normal for a real-time OS? Can I be sure
that
these
deviations never will be bigger?
Alex
PS. QNX host is a PC with 600 MHz Celeron, 64 MB RAM, S3
Savage3D,
Micronet SP2080 PCI Ethernet card (Realtek8029AS)
\
