Interrupt latency in RTEMS (Zedboard)

[Joel Sherrill]

On Tue, Mar 27, 2018 at 8:05 AM, BRIARD Sebastien <
sebastien.briard at thalesaleniaspace.com> wrote:

> Okay, I realized how I was confusing clock tick (for timekeeping) and
> interrupt latency and why the result were not the ones I expected.
> I still have one question, is there a macro to choose/impose the processor
> frequency ?
>

If you mean the actual clock rate of the CPU, then it would be a BSP
specific option and
it would have to match the hardware. All the BSP options for this BSP are in
c/src/lib/libbsp/arm/xilinx_zynq/configure.ac.

For the clock tick length, you have to balance overloading the CPU with
clock tick
interrupts on one extreme and not advancing time on the other. Your 1
microsecond
per tick is dangerously close to the no forward progress end. At some
point, you
have to consider that it takes a minimum number of instructions to process
the
interrupt and from that a minimum length of time.

At near 1 Mhz, you can probably handle the 1 usec clock ticks alone but
there won't
be much time left to do real work. I experimented years ago on a 400 Mhz
embedded PowerPC and you could go very low on the clock tick but it was
clear from the test code I was running that you lost more and more
non-interrupt
processing time to do application processing. So as the interrupt rate went
up,
the overall application throughput went down.

A similar situation can occur in network programs where the overhead of each
socket read/write is high enough where it begins to dominate for small
transfers.

--joel


>
> -----Message d'origine-----
> De : BRIARD Sebastien
> Envoyé : mardi 27 mars 2018 14:33
> À : 'Sebastian Huber'; users at rtems.org
> Objet : RE: Interrupt latency in RTEMS (Zedboard)
>
> I am using the expiration of a timer. And basically I am doing two things:
> -  I keep measuring time in my main loop
> - when I am in the handler I take a new measure of the time.
>
> It was a quick, not so rigorous test, with global variables.
>
> Here is the code :
> // Global variable for tests //
> volatile bool signal_sent;
> rtems_interval lat=0 ;
> rtems_id main_task;
>
> //handler //
> rtems_timer_service_routine test_signal_from_isr(rtems_id  timer, void
>  *arg)
> {
>   rtems_interval *rag = (rtems_interval*)arg ;
>   lat = rtems_clock_get_uptime_nanoseconds() - *rag ;
>   signal_sent = TRUE;
> }
>
> // main task //
> rtems_task Init(  rtems_task_argument argument) {
>   rtems_status_code     status;
>   rtems_id              timer;
>   rtems_interval now;
>
>   // index to repeat test //
>   int i = 0 ;
>   main_task = rtems_task_self();
>   printf("ticks per seconds : %02ld \n",rtems_clock_get_ticks_per_second())
> ;
>
>   /*
>    *  Timer used in multiple ways
>    */
>   status = rtems_timer_create( 1, &timer );
>   assert( status == RTEMS_SUCCESSFUL );
>
>   while(i<10)
>   {
>   /*
>    * Test Signal from ISR
>    */
>   signal_sent = FALSE;
>
>   status = rtems_timer_fire_after( timer, 20, test_signal_from_isr,
> (void*) &now );
>   assert( status == RTEMS_SUCCESSFUL );
>
>   while (1) {
>     now = rtems_clock_get_uptime_nanoseconds() ;
>     if ( signal_sent )
>       break;
>   }
>   printf(" interrupt latency : %ld ns \n",lat) ;
>   puts( "Signal sent from ISR has been processed" );
>   i++;
>   }
>   puts( "*** END OF SIGNAL FROM TSR TEST ***" );
>   exit( 0 ); // generera un RTEMS fatal
> }
>
> /* configuration information */
> #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
>
> #define CONFIGURE_MICROSECONDS_PER_TICK   1
>
> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
>
> #define CONFIGURE_MAXIMUM_TASKS             1
> #define CONFIGURE_MAXIMUM_TIMERS            1
>
> #define CONFIGURE_INIT
> #include <rtems/confdefs.h>
>
> -----Message d'origine-----
> De : Sebastian Huber [mailto:sebastian.huber at embedded-brains.de]
> Envoyé : mardi 27 mars 2018 14:20
> À : BRIARD Sebastien; users at rtems.org
> Objet : Re: Interrupt latency in RTEMS (Zedboard)
>
> Hello Sebastien,
>
> could you give a code example how you measure the interrupt latency?
> Which interrupt do you use?
>
> The time keeping is independent of the clock tick configuration.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20180327/00a47e0b/attachment-0002.html>