IRQ latency (was Re: RTEMS-MVME5500 BSP v1.3 available)

[Peter Dufault]

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.

Peter