IRQ latency (was Re: RTEMS-MVME5500 BSP v1.3 available)
dufault at hda.com
Wed Aug 10 01:30:37 UTC 2005
On Aug 9, 2005, at 2:49 PM, Kate Feng wrote:
> Peter Dufault wrote :
>> Data acquisition interrupt (copies data off PCI board, posts
>> semaphore): 22KHz 15KHz
> The former one is for RTEMS and the later one is for vxWorks.
> RTEMS interrupt outperformed vxWorks by 30%, which I interprete
> it as the "average case" instead of the "worst case". However,
> looking at the average performance I got even for the loaded
> system (attached at the end), it seems that RTEMS is 30%
> slower on the "average" case. This puzzles me. The difference
> between my RTEMS system and his is :
> 1. RTEMS4.6 with gcc-3.2 v.s. RTEMS4.7 with gcc-4.0
> 2. optimized v.s. non-optimized.
> 3. system bus counter's IRQ v.s. PMC module's IRQ, which should
> not make a difference for the optimized version.
> 4. native O.S. thread v.s. pthread for the benchmark software.
What I'm quoting above as "Data acquisition interrupt" is something
complicated. You'd have to go back and read the original
description, but it is obtained by taking a loaded system with the
task load described originally, including a heavy network load with
system network tasks running that I don't know the internals of, and
increasing the data acquisition interrupt rate (which drives the
"synchronous" parts of the application), until the highest priority
task that fields the semaphore posted from that interrupt fails to
finish before a second interrupt shows up.
This means my above comparison is a comparison where part of the
application mix (the network part) is being treated as a black box.
To show how artificial my nubers are, let me point out that I can
think of a reorganization of that highest priority task where I could
split out part that could happen less frequently, and allow that to
run at a lower priority as a separate task, and the all of a sudden
the "Data acquisition rate" could increase, but it would probably
increase about the same for vxWorks and RTEMS, which is why I think
the numbers are valuable to look at.
So this isn't an "average case", it's a "worse-case in an
application", since the interrupt rate is increased until it fails
even once in an extended multi-day run under an artificially high
load and then backed off to get the quoted numbers.
More information about the users