interrupt latency

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
21

Mario Charest wrote:

“Alex Guryanow” <> gav@ets.ifmo.ru> > wrote in message
news:> 3B4C586F.B8C99A77@ets.ifmo.ru> …


Rennie Allen wrote:

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

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 how can be this tested?

Instrumented kernel.

Sorry, what is it “instrumented kernel”?

it
does not do your work for you; it can’t (besides, that is why you get
the big bucks > :slight_smile:> . 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

why? are these drivers developped not by QSSL?

This take lots of time to test. Plus it also mean everytime a single line
of relavent code is modified the whole testing has to be done all over
again.
Very time consuming. QA already seems to have their hands full > :wink:

why to test? Cannot be this calculated using knowledge of each instruction time?



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

Ok, in develpment box one can use the hardware and drivers which interrupt
handling times are unknown, but in
working real-time system should be used only that hardware which latencies
are well known. IMHO.

Yes but how QNX can tell which hardware you’ve decide to use?

They don’t should tell this. The developper of the system should select those
hardware for target system which time latencies are known.


Hence
their number would be meaningless anyway. Further more, since latency
is also affected by hardware (chipset) tracking this info (if it’s available
in the
first place)

How big is this hardware latency?

Alex

22

“Alex Guryanow” <gav@ets.ifmo.ru> wrote in message
news:3B4D7124.BA73A053@ets.ifmo.ru…

Mitchell Schoenbrun wrote:

Previously, Mario Charest wrote in qdn.public.qnxrtp.os:

And not to mention, DMA operation, PCI master card,
SMM (or is it SMI) mode etc.


For the familiar, DMA can steal a percentage of
the bus, usually on a predicatable basis. There is a
“burst” mode that could be a serious problem with hard real
time. SMM/SMI (I don’t recall which it is either) is either

Sorry for a possible dumb question, but wat is it SMM/SMI?

It’s a “feature” in the CPU that allow the BIOS to run powersafe
features without the OS (any OS) even knowing about it.

And I think, that if DMA can bring so many problems then it can be
disabled (standard installation of QNX has this option)

That’s true for IDE (at the expense of performance ). But not
for Ethernet card or SCSI card.

Alex

23

“Alex Guryanow” <gav@ets.ifmo.ru> wrote in message
news:3B4D74BB.C6E28E6B@ets.ifmo.ru…

Mario Charest wrote:

“Alex Guryanow” <> gav@ets.ifmo.ru> > wrote in message
news:> 3B4C586F.B8C99A77@ets.ifmo.ru> …


Rennie Allen wrote:

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

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 how can be this tested?

Instrumented kernel.

Sorry, what is it “instrumented kernel”?

it
does not do your work for you; it can’t (besides, that is why you
get
the big bucks > :slight_smile:> . 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

why? are these drivers developped not by QSSL?

This take lots of time to test. Plus it also mean everytime a single
line
of relavent code is modified the whole testing has to be done all over
again.
Very time consuming. QA already seems to have their hands full > :wink:

why to test? Cannot be this calculated using knowledge of each instruction
time?

You must be kidding right ? :wink: Instruction time is totaly different for
each model
of processor, 80386, 80486, Pentium I/II/III/IV, AMD K6 K6-2, Althon…
And then thrown in support for Arm, PowerPC, SH3…
Plus on latest processor, pipelining, branch prediction, cache, memory
latency etc
turned calculating executing time into a science…

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

Ok, in develpment box one can use the hardware and drivers which
interrupt
handling times are unknown, but in
working real-time system should be used only that hardware which
latencies
are well known. IMHO.

Yes but how QNX can tell which hardware you’ve decide to use?

They don’t should tell this. The developper of the system should select
those
hardware for target system which time latencies are known.


Hence
their number would be meaningless anyway. Further more, since latency
is also affected by hardware (chipset) tracking this info (if it’s
available
in the
first place)

How big is this hardware latency?

Alex
\

24

So the question is:

  • Which drivers use InterruptAttachEvent and which don’t?
  • The ones that don’t, why can’t they use it?

Markus

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

QNX6 allows you to attach an event directly to a hardware interrupt
(InterruptAttachEvent) without providing an interrupt handler, so that
there is, in effect, no interrupt dispatch latency at all (i.e. the
interrupt is handled completely in kernel context, and the event is
queued to the process that attached it, with scheduling occurring as
expected). It is quite simply impossible to be any “more” of an RTOS in
this respect. It is probably because of this capability that it was
decided not to allow setting of the hardware priority, since this
capability enables use of the OS priority structure with interrupt
handlers (better in many ways - and certainly more portable - than being
able to set some “foreign” h/w based priority).

-----Original Message-----
From: Mitchell Schoenbrun [mailto:> maschoen@pobox.com> ]
Posted At: Wednesday, July 11, 2001 10:17 AM
Posted To: os
Conversation: interrupt latency
Subject: Re: interrupt latency


Previously, Alex Guryanow wrote in qdn.public.qnxrtp.os:

OK, I understand. It can therefore interrupt handlers be not necessary
in general? I think
this problem at all would not be, if interrupts were processed only
through messages. Because now the priorities system is broken by
interrupt handlers in drivers and user soft.

Well QSSL seems to recommend that you limit your interrupt handler
to as little code as possible. In the extreme as you seem to suggest
you could always trigger a pulse, and then let the scheduler decide
which code will run. This gives you maximum control. It would be nice
if QSSL would publish some details on the load each driver might
place on the system. If ever the sources are released, the answers
will be available. They could potentially even show us the interrupt
handlers for otherwise un-releaseable drivers.


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

25

If drivers don’t use InterruptAttachEvent then it is most likely to
improve performance, since you are substituting dispatch latency for
scheduling latency (with all the good things that scheduling latency
brings - like priority based scheduling). The dilemma is always one of
throughput performance of development time environment vs predictability
of deployed system. IMO disk drivers can justify using InterruptAttach,
since they are important to development time performance, and unlikely
to be used in a hard real-time deployment.

-----Original Message-----
From: Markus Loffler [mailto:loffler@ces.clemson.edu]
Posted At: Thursday, July 12, 2001 7:46 AM
Posted To: os
Conversation: interrupt latency
Subject: Re: interrupt latency


So the question is:

  • Which drivers use InterruptAttachEvent and which don’t?
  • The ones that don’t, why can’t they use it?

Markus

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

QNX6 allows you to attach an event directly to a hardware interrupt
(InterruptAttachEvent) without providing an interrupt handler, so that
there is, in effect, no interrupt dispatch latency at all (i.e. the
interrupt is handled completely in kernel context, and the event is
queued to the process that attached it, with scheduling occurring as
expected). It is quite simply impossible to be any “more” of an RTOS
in
this respect. It is probably because of this capability that it was
decided not to allow setting of the hardware priority, since this
capability enables use of the OS priority structure with interrupt
handlers (better in many ways - and certainly more portable - than
being
able to set some “foreign” h/w based priority).

-----Original Message-----
From: Mitchell Schoenbrun [mailto:> maschoen@pobox.com> ]
Posted At: Wednesday, July 11, 2001 10:17 AM
Posted To: os
Conversation: interrupt latency
Subject: Re: interrupt latency


Previously, Alex Guryanow wrote in qdn.public.qnxrtp.os:

OK, I understand. It can therefore interrupt handlers be not
necessary
in general? I think
this problem at all would not be, if interrupts were processed only
through messages. Because now the priorities system is broken by
interrupt handlers in drivers and user soft.

Well QSSL seems to recommend that you limit your interrupt handler
to as little code as possible. In the extreme as you seem to suggest
you could always trigger a pulse, and then let the scheduler decide
which code will run. This gives you maximum control. It would be
nice
if QSSL would publish some details on the load each driver might
place on the system. If ever the sources are released, the answers
will be available. They could potentially even show us the interrupt
handlers for otherwise un-releaseable drivers.


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

26

Markus Loffler wrote:

So the question is:

  • Which drivers use InterruptAttachEvent and which don’t?
  • The ones that don’t, why can’t they use it?

Good questions. I think one should add another:

  • What software (not only drivers) uses InterruptAttach function and/or
    disables interrupts (and for what time)?

because I’m not shure that for example Doom does not use interrupts for better
time synchronisation

Alex

Markus

“Rennie Allen” <> RAllen@csical.com> > wrote in message
news:> D4907B331846D31198090050046F80C905CCD2@exchangecal.hq.csical.com> …
QNX6 allows you to attach an event directly to a hardware interrupt
(InterruptAttachEvent) without providing an interrupt handler, so that
there is, in effect, no interrupt dispatch latency at all (i.e. the
interrupt is handled completely in kernel context, and the event is
queued to the process that attached it, with scheduling occurring as
expected). It is quite simply impossible to be any “more” of an RTOS in
this respect. It is probably because of this capability that it was
decided not to allow setting of the hardware priority, since this
capability enables use of the OS priority structure with interrupt
handlers (better in many ways - and certainly more portable - than being
able to set some “foreign” h/w based priority).

-----Original Message-----
From: Mitchell Schoenbrun [mailto:> maschoen@pobox.com> ]
Posted At: Wednesday, July 11, 2001 10:17 AM
Posted To: os
Conversation: interrupt latency
Subject: Re: interrupt latency


Previously, Alex Guryanow wrote in qdn.public.qnxrtp.os:

OK, I understand. It can therefore interrupt handlers be not necessary
in general? I think
this problem at all would not be, if interrupts were processed only
through messages. Because now the priorities system is broken by
interrupt handlers in drivers and user soft.

Well QSSL seems to recommend that you limit your interrupt handler
to as little code as possible. In the extreme as you seem to suggest
you could always trigger a pulse, and then let the scheduler decide
which code will run. This gives you maximum control. It would be nice
if QSSL would publish some details on the load each driver might
place on the system. If ever the sources are released, the answers
will be available. They could potentially even show us the interrupt
handlers for otherwise un-releaseable drivers.


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

27

Mario Charest wrote:

it
does not do your work for you; it can’t (besides, that is why you
get
the big bucks > :slight_smile:> . 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

why? are these drivers developped not by QSSL?

This take lots of time to test. Plus it also mean everytime a single
line
of relavent code is modified the whole testing has to be done all over
again.
Very time consuming. QA already seems to have their hands full > :wink:

why to test? Cannot be this calculated using knowledge of each instruction
time?

You must be kidding right ? > :wink: > Instruction time is totaly different for
each model
of processor, 80386, 80486, Pentium I/II/III/IV, AMD K6 K6-2, Althon…
And then thrown in support for Arm, PowerPC, SH3…
Plus on latest processor, pipelining, branch prediction, cache, memory
latency etc
turned calculating executing time into a science…

No, I’m absolutely serious. For each processor at each frequency the
time of each instruction is well known. When you know these times and
instructions the driver consist of then needed execution
times can be calculated without any hand-work. IMHO.
Because the developper of real-time system need to know the worst
time for each driver, interrupt handler etc, then by these calculations
one should assume that pipelining is disabled (or what is worst case for
pipelining?),
cache is disabled.
And memory latencies are well known too. If QSSL says that in HDD
driver in interrupt handler they have 100 memory read/write operations then
using time specifications for
particular RAM the developper can calcaulate additional latencies on one’s own.

Mario, what is instrumented kernel? Is it a tool developped by QSSL for testing
purposes?

Alex

28

Alex,
on 6.1, go to the helpviewer, you’ll quickly find info about the
instrumental kernel.
Markus

“Alex Guryanow” <gav@ets.ifmo.ru> wrote in message
news:3B4DD799.13824B1D@ets.ifmo.ru…

Mario Charest wrote:

it
does not do your work for you; it can’t (besides, that is why
you
get
the big bucks > :slight_smile:> . 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

why? are these drivers developped not by QSSL?

This take lots of time to test. Plus it also mean everytime a
single
line
of relavent code is modified the whole testing has to be done all
over
again.
Very time consuming. QA already seems to have their hands full > :wink:

why to test? Cannot be this calculated using knowledge of each
instruction
time?

You must be kidding right ? > :wink: > Instruction time is totaly different
for
each model
of processor, 80386, 80486, Pentium I/II/III/IV, AMD K6 K6-2, Althon…
And then thrown in support for Arm, PowerPC, SH3…
Plus on latest processor, pipelining, branch prediction, cache, memory
latency etc
turned calculating executing time into a science…

No, I’m absolutely serious. For each processor at each frequency the
time of each instruction is well known. When you know these times and
instructions the driver consist of then needed execution
times can be calculated without any hand-work. IMHO.
Because the developper of real-time system need to know the worst
time for each driver, interrupt handler etc, then by these calculations
one should assume that pipelining is disabled (or what is worst case for
pipelining?),
cache is disabled.
And memory latencies are well known too. If QSSL says that in HDD
driver in interrupt handler they have 100 memory read/write operations
then
using time specifications for
particular RAM the developper can calcaulate additional latencies on one’s
own.

Mario, what is instrumented kernel? Is it a tool developped by QSSL for
testing
purposes?

Alex

29

“Alex Guryanow” <gav@ets.ifmo.ru> wrote in message
news:3B4DD799.13824B1D@ets.ifmo.ru…

Mario Charest wrote:

No, I’m absolutely serious. For each processor at each frequency the
time of each instruction is well known. When you know these times and
instructions the driver consist of then needed execution
times can be calculated without any hand-work. IMHO.

Because the developper of real-time system need to know the worst
time for each driver, interrupt handler etc, then by these calculations
one should assume that pipelining is disabled (or what is worst case for
pipelining?),

To my knowledge pipelining cannot be disable,

I remember doing that with Psos and a 68000, Psos would provide
duration for each OS call, that was amazing. I also
remember optimizing code by hand counting cycle and stuff.
But I’d bet you Psos would not release number like that
on a PowerPC…

cache is disabled.

That means the speed of a Pentium II 200Mzh will be
roughly equal to a 486. The result would become totaly
irrelavent.

And memory latencies are well known too.

I don’t agree, memory latencies depends on where the data was load
from, are they on page boundaries or not. This would require a huge
amount of work to obtain that information.

If QSSL says that in HDD
driver in interrupt handler they have 100 memory read/write operations
then
using time specifications for particular RAM the developper can calcaulate
additional latencies on one’s own.

I think you are oversimplifying. A simple add operation on Pentium
III can go from 0 cycle (because of pipeline) to over 5 if not more,
depending on cache
misses and if you through in DMA. What about SMP …


QSSL cannot release numbers that would make any kind of sense.


Mario, what is instrumented kernel? Is it a tool developped by QSSL for
testing
purposes?

Yes. It’s a different version of the kernel that permits recording of every
event in
the system, interrupt, messages, switching, signal etc. This kernel is not
part
of the basic product it’s an add-on that must be purchase. Great tool to
figure
out what is happening behind the scene. This is probably what you need :wink:

Alex

30

Previously, Mario Charest wrote in qdn.public.qnxrtp.os:

It’s a “feature” in the CPU that allow the BIOS to run powersafe
features without the OS (any OS) even knowing about it.

It also can be used to emulate hardware. For example, hardware
can be used on a lap top to simulate 640x480 by stretching
bits. This is needed because LCD screens do not have adjustable
resolutions.

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

31

Previously, Alex Guryanow wrote in qdn.public.qnxrtp.os:

No, I’m absolutely serious. For each processor at each frequency the
time of each instruction is well known. When you know these times and
instructions the driver consist of then needed execution
times can be calculated without any hand-work. IMHO.

This is true in principle. However, all Pentium’s have a
fairly complex pipeline. I read all about it in a book
“Micahel Abrash’s Graphics Programming Black Book Special
Edition”. It’s really eye poping. All Pentiums have
effectively two exectution processors with separate
pipelines, but they are not symmetric. The secondary
pipeline can sometime execute a subset of the instruction
set simultaneously. The rules for which a simultaneous
execution can take place are extremely complex and not well
documented. In some cases the behavior is not documented at
all.

If that is not complicated enough, specifics of the cache operation
are important.

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

32

“Mitchell Schoenbrun” <maschoen@pobox.com> wrote in message
news:Voyager.010712130618.1202E@schoenbrun.com…

Previously, Alex Guryanow wrote in qdn.public.qnxrtp.os:

No, I’m absolutely serious. For each processor at each frequency the
time of each instruction is well known. When you know these times and
instructions the driver consist of then needed execution
times can be calculated without any hand-work. IMHO.

This is true in principle. However, all Pentium’s have a
fairly complex pipeline. I read all about it in a book
“Micahel Abrash’s Graphics Programming Black Book Special
Edition”. It’s really eye poping. All Pentiums have
effectively two exectution processors with separate
pipelines, but they are not symmetric. The secondary
pipeline can sometime execute a subset of the instruction
set simultaneously. The rules for which a simultaneous
execution can take place are extremely complex and not well
documented. In some cases the behavior is not documented at
all.

I wouldn’t be surprise if it changes from stepping to stepping!
Meaning it may behave differently depending when you bought
the CPU :wink:

If that is not complicated enough, specifics of the cache operation
are important.

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

33

Alex Guryanow <gav@ets.ifmo.ru> wrote in message
news:3B4D7124.BA73A053@ets.ifmo.ru…

Mitchell Schoenbrun wrote:

Previously, Mario Charest wrote in qdn.public.qnxrtp.os:

And not to mention, DMA operation, PCI master card,
SMM (or is it SMI) mode etc.

time. SMM/SMI (I don’t recall which it is either) is either

Sorry for a possible dumb question, but wat is it SMM/SMI?

could probably find out from Intel

searching back through the newsgroup, comes up with
news:MPG.15634a47604be34f989684@inn.qnx.com

Alex

34

Previously, Mario Charest wrote in qdn.public.qnxrtp.os:

I wouldn’t be surprise if it changes from stepping to stepping!
Meaning it may behave differently depending when you bought
the CPU > :wink:

Possibly, although they do document some of it, which would
imply that they are bound.

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