RTEMS Interrupt Latency and Semaphore Release Obtain Latency

[Joel Sherrill]

Jamie Bowman wrote:
>
> All
>
>  
>
> I wonder if I could tap in to the groups experience with writing ISRs 
> within a typical RTEMS driver model.
>
>  
>
I hope someone else will pipe up with more specifics.
>
> We have written a number of drivers for various low level UART styled 
> devices. These devices can work in either polled or interrupt mode. In 
> interrupt mode we use the SIMPLE BINARY SEMAPHORE to synchronise 
> events between our ISRs and the Read and Write routines of driver e.g. 
> within the ISR we use rtems_semaphore_release and within the read and 
> write routines block until rtems_semaphore_obtain is successful.
>
>  
>
> What we have observed so far is that the ISR takes a relatively long 
> time to be serviced, 10us [200 clock cycles] up to 40us [800 clock 
> cycles],
>
At the 10us level, that isn't bad given your clock speed.  200 clock 
cycles isn't that many
instructions and the SPARC has lots of registers to save (2 cycles per) 
and restore (3 cycles per).

800 cycles is longer but not out of reason given a few factors.

  + ISR could occur when interrupts are disabled at application level.
  + ISR could occur during another interrupt and be deferred a bit.
  + (most likely) ISR could result in window overflow and LOTS of
      memory accesses.  Just read the code in 
cpukit/score/cpu/sparc/cpu_asm.S
     in _ISR_Handler.

> and that the time between releasing the semaphore within the ISR and 
> the Read or Write Routines being released varies considerably, 20us 
> [400 clock cycles]  up to 80us [1600 clock cycles].
>
Again if you had a quick entry (no window overflow), then the exit is 
likely cheap with
no window restore.  But there is also the factor of context switching to 
a new task.
So even more memory access and code loading.

> We also have noted that the time between releasing the semaphore 
> within the ISR and the Read or Write Routines being released on the 
> first time of execution always appears to be significantly longer than 
> subsequent times.
>
>  
>
The first time could indicate a lot of things.

+ destination code isn't in cache
+ destination read/write routine wasn't entered yet.
    (e.g. app is doing something else)
+ normal scheduling. May not be most important task.
+first time task runs has entry overhead from RTEMS and
   application task init in it.

> Our devices are attached directly to the interrupt lines on a SPARC 
> Leon 2 processor. The processor runs at 20 MHz and we are using rtems 4.8.
>
>  
>
> My first question would be are these delays typical of an RTEMS based 
> system?
>
On a SPARC and knowing nothing of your application, I would say that 
they are register
windows and large register sets plus "normal" issues like scheduling, 
task priority,
application task doing something else, etc could easily explain this.
>
> Secondly is there a way of improving the performance by reducing these 
> latencies in some way?
>
You could be using termios and buffering more data.  Do you really need 
to wake up a task on EVERY
character?  Can't the task wait for N characters or a time limit?  
Termios supports that.  So the task
only wakes up every nth character or x milliseconds or if the read is 
satisfied.

Termios handles all this for you.

> Lastly is the SIMPLE BINARY SEMAPHORE the correct synchronisation 
> mechanism to use in this instance?
>
>  
>
If you want the task to wake up everytime.
>
> Thank you for in advance for your assistance.
>
>  
>
>             Jamie
>


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