RTEMS Interrupt Latency and Semaphore Release Obtain Latency

[Manuel Coutinho]

Hi

 

 

1. From our experience, these values in time that you are showing are
typical for RTEMS. Maybe a little bit faster or slower, depending on the
cases, but in general they are a good approximation.

 

2. Unless you crack the RTEMS code itself and be almost a genius or have
lots of time.I guess it will be very hard to improve those times :)

 

3. For synchronization purposes, you could also use the rtems_event_send or
the rtems_message_queue_send. Believe the first one is the fastest.

 

 

Also, don't forget to measure the time that an interrupt exit (from the last
C instruction of the ISR to the first C instruction of your application)
takes.it can also take a while.

 

A small point on those numbers you got.I believe that those numbers are very
difficult lower. RTEMS is already very good in terms of performance.

Well, its just my opinion :)

 

PS: Joel comments on the previous mail are also very good.

 

Kind regards

Manuel Coutinho

 

  _____  

From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org]
On Behalf Of Jamie Bowman
Sent: Thursday, September 17, 2009 1:23 PM
To: rtems-users at rtems.org
Subject: Re: RTEMS Interrupt Latency and Semaphore Release Obtain Latency

 

All

 

I wonder if I could tap in to the groups experience with writing ISRs within
a typical RTEMS driver model.

 

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

 

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?

Secondly is there a way of improving the performance by reducing these
latencies in some way? 

Lastly is the SIMPLE BINARY SEMAPHORE the correct synchronisation mechanism
to use in this instance?

 

Thank you for in advance for your assistance.

 

            Jamie

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20090917/5dc28453/attachment-0001.html>