Interrupt latency problems on MPC860

[gregory.menke at gsfc.nasa.gov]

 > > We are using RTEMS 4.5.0 on a 50MHz MPC860.  Our application relies
 > > on a particular periodic interrupt being serviced with no more
 > > than 78 microseconds of latency.  We keep having problems because
 > > that interrupt isn't being serviced on time.
 > > 
 > > There's not much else going on in the system currently.  Several
 > > tasks are asleep or blocking on I/O, but none of them should be
 > > waking up and causing a context switch.  (We've got things really
 > > stripped down trying to pin down the latency problem, so practically
 > > everything but our critical interrupt is commented out.)
 > > 
 > > Is 78us of latency for maskable interrupts a reasonable goal, or is
 > > that outside of RTEMS' performance envelope?  Any comments are welcome.
 > 
 > In general terms, this is not a problem for RTEMS itself.  However,
 > application code and the PowerPC architecture itself can make this
 > hard to achieve.
 > 
 > First, on a PPC you have to go hunting for the interrupt source 
 > and that could be bad on some boards.  One I know of had a very complicated
 > procedure to track down what happened.
 > 
 > Moreover, this really may be tough to attain on the PowerPC
 > architecture without VERY special care.  The PowerPC by default does
 > not really have interrupt priority or (without work) nesting of 
 > interrupts.  So all you have to do is take > 79 usecs to process
 > an interrupt and you are nailed.  Since (I am pretty sure about this)
 > interrupts are disabled from the time a handler is vectored by HW
 > until the entire ISR returns, you have a long window there.  
 > 
 > Any other PowerPC experts out there want to comment?

Although not on a PPC, we're running RTEMS on a MIPS R3000 at 12mhz
and have found the timer tick takes approx 70us to execute from
interrupt to return.  Context switches add considerably to it.  You
might consider tracking down the interrupt service code and looking
thru it to see where the time is being spent.  MIPS interrupt handing
is roughly analagous to the PPC, so maybe you can find and disable
something thats wasting lots of time.  If you know enough about your
board's interrupt architecture it might be possible to hack the BSP to
improve performance.

Gregm