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

[Kate Feng]

Peter Dufault wrote:

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

Thanks for your  explaination.  Yes, I agree the numbers are valuable
to look at.  It's an interesting  test.


However,  it's interesting to test the IRQ latency benchmark software
in RTEMS4.7  as well except   I  might not be able to test it in 4.7
within
next  two months.


My impression is that Till Strumann improved the clockIsr()
routine of c/src/lib/libcpu/powerpc/mpc6xx/clock/c_clock.c
to optimize the interrupt  overhead  for all the PowerPCs.
He filed the  PR #773.

However, in the  following thread :
http://www.rtems.com/ml/rtems-users/2005/march/msg00134.html

Till Straumann wrote:

>BTW: I should also have disabled interrupts around the update
>to avoid the race condition [higher priority IRQ between mfdec
>and mtdec].

Till,  may I know  if this issue  was solved or defined somewhere in
the RTEMS4.7?  This is not in PR#773.


Thanks,
Kate


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