On Tue, Mar 27, 2018 at 8:05 AM, BRIARD Sebastien <
sebastien.bri...@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@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.hu...@embedded-brains.de]
> Envoyé : mardi 27 mars 2018 14:20
> À : BRIARD Sebastien; users@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.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> _______________________________________________
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
