Interrupt latency problems on MPC860

[Joel Sherrill]

leonp wrote:
> 
> On Wednesday 14 November 2001 22:43, you wrote:
> > We are using RTEMS 4.5.0 on a 50MHz MPC860.
> Our case is MPC860 at 25MHz.
> 
> > 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.
> What exactly do you call 'latency'? As far as I was able to understand from
> the following posts you include the interrupt processing time into this
> figure. Am I right?

Interrupt latency is one of those things where multiple views exist.  Here is
the RTEMS view:

http://www.oarcorp.com/rtemsdoc-4.5.0/rtemsdoc/html/supplements/sparc/sparc00055.html

A section of that says:

> The worst case interrupt latency for a real-time executive is based upon the following components: 
> 
>     + the longest period of time interrupts are disabled by the executive, 
>     + the overhead required by the executive at the beginning of each ISR, 
>     + the time required for the CPU to vector the interrupt, and 
>       for some microprocessors, the length of the longest instruction. 



> Anyway, when we measured the time between the IRQ line change and the first
> instruction been reached in the user ISR routine with oscilloscope, it was
> 14micro at our 25MHz Power Quick with instructions cache 'on' and data cache
> 'off'.

This seems like you are measuring the 1st and 2nd components in agreement with
our definition.  

I think Phil is taking a broader view that probably includes whatever effect
actual ISR processing and returning from the ISR is having.  

Phil do you have a way to measure what Leon has measured?  Or can you verify
you are not nesting interrupts? If you are not nesting, that would be a dead
giveaway why this happens.

If you are nesting, then focus on interrupt disable in drivers and how long
it takes to figure out what to vector on your CPU/board.  I have seen 
PPC boards where this was actually a time-consuming task accessing multiple
slow peripherals.

> Also, may be you have some kind of measurement problem?

One can only hope but I assume there is another indication they don't
make the 78 usec mark.

> > Is 78us of latency for maskable interrupts a reasonable goal, or is
> > that outside of RTEMS' performance envelope?  Any comments are welcome.
> Hope this helps...

On a reasonable speed CPU and careful interrupt management, I still believe
this 
is well within reason.

> --
> Dr.Leon M.Pollak
> Director
> PLR Information Systems Ltd.
> leonp at plris.com

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985