<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 27, 2018 at 8:05 AM, BRIARD Sebastien <span dir="ltr"><<a href="mailto:sebastien.briard@thalesaleniaspace.com" target="_blank">sebastien.briard@thalesaleniaspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Okay, I realized how I was confusing clock tick (for timekeeping) and interrupt latency and why the result were not the ones I expected.<br>
I still have one question, is there a macro to choose/impose the processor frequency ?<br></blockquote><div><br></div><div>If you mean the actual clock rate of the CPU, then it would be a BSP specific option and</div><div>it would have to match the hardware. All the BSP options for this BSP are in</div><div>c/src/lib/libbsp/arm/xilinx_zynq/<a href="http://configure.ac">configure.ac</a>.</div><div><br></div><div>For the clock tick length, you have to balance overloading the CPU with clock tick</div><div>interrupts on one extreme and not advancing time on the other. Your 1 microsecond</div><div>per tick is dangerously close to the no forward progress end. At some point, you</div><div>have to consider that it takes a minimum number of instructions to process the</div><div>interrupt and from that a minimum length of time. </div><div><br></div><div>At near 1 Mhz, you can probably handle the 1 usec clock ticks alone but there won't</div><div>be much time left to do real work. I experimented years ago on a 400 Mhz</div><div>embedded PowerPC and you could go very low on the clock tick but it was</div><div>clear from the test code I was running that you lost more and more non-interrupt</div><div>processing time to do application processing. So as the interrupt rate went up,</div><div>the overall application throughput went down.</div><div><br></div><div>A similar situation can occur in network programs where the overhead of each</div><div>socket read/write is high enough where it begins to dominate for small </div><div>transfers. </div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-----Message d'origine-----<br>
De : BRIARD Sebastien<br>
Envoyé : mardi 27 mars 2018 14:33<br>
À : 'Sebastian Huber'; <a href="mailto:users@rtems.org">users@rtems.org</a><br>
Objet : RE: Interrupt latency in RTEMS (Zedboard)<br>
<div><div class="h5"><br>
I am using the expiration of a timer. And basically I am doing two things:<br>
- I keep measuring time in my main loop<br>
- when I am in the handler I take a new measure of the time.<br>
<br>
It was a quick, not so rigorous test, with global variables.<br>
<br>
Here is the code :<br>
// Global variable for tests //<br>
volatile bool signal_sent;<br>
rtems_interval lat=0 ;<br>
rtems_id main_task;<br>
<br>
//handler //<br>
rtems_timer_service_routine test_signal_from_isr(rtems_id timer, void *arg)<br>
{<br>
rtems_interval *rag = (rtems_interval*)arg ;<br>
lat = rtems_clock_get_uptime_<wbr>nanoseconds() - *rag ;<br>
signal_sent = TRUE;<br>
}<br>
<br>
// main task //<br>
rtems_task Init( rtems_task_argument argument) {<br>
rtems_status_code status;<br>
rtems_id timer;<br>
rtems_interval now;<br>
<br>
// index to repeat test //<br>
int i = 0 ;<br>
main_task = rtems_task_self();<br>
printf("ticks per seconds : %02ld \n",rtems_clock_get_ticks_per_<wbr>second()) ;<br>
<br>
/*<br>
* Timer used in multiple ways<br>
*/<br>
status = rtems_timer_create( 1, &timer );<br>
assert( status == RTEMS_SUCCESSFUL );<br>
<br>
while(i<10)<br>
{<br>
/*<br>
* Test Signal from ISR<br>
*/<br>
signal_sent = FALSE;<br>
<br>
status = rtems_timer_fire_after( timer, 20, test_signal_from_isr, (void*) &now );<br>
assert( status == RTEMS_SUCCESSFUL );<br>
<br>
while (1) {<br>
now = rtems_clock_get_uptime_<wbr>nanoseconds() ;<br>
if ( signal_sent )<br>
break;<br>
}<br>
printf(" interrupt latency : %ld ns \n",lat) ;<br>
puts( "Signal sent from ISR has been processed" );<br>
i++;<br>
}<br>
puts( "*** END OF SIGNAL FROM TSR TEST ***" );<br>
exit( 0 ); // generera un RTEMS fatal<br>
}<br>
<br>
/* configuration information */<br>
#define CONFIGURE_APPLICATION_NEEDS_<wbr>CONSOLE_DRIVER<br>
#define CONFIGURE_APPLICATION_NEEDS_<wbr>CLOCK_DRIVER<br>
<br>
#define CONFIGURE_MICROSECONDS_PER_<wbr>TICK 1<br>
<br>
#define CONFIGURE_RTEMS_INIT_TASKS_<wbr>TABLE<br>
<br>
#define CONFIGURE_MAXIMUM_TASKS 1<br>
#define CONFIGURE_MAXIMUM_TIMERS 1<br>
<br>
#define CONFIGURE_INIT<br>
#include <rtems/confdefs.h><br>
<br>
-----Message d'origine-----<br>
De : Sebastian Huber [mailto:<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@<wbr>embedded-brains.de</a>]<br>
Envoyé : mardi 27 mars 2018 14:20<br>
À : BRIARD Sebastien; <a href="mailto:users@rtems.org">users@rtems.org</a><br>
</div></div>Objet : Re: Interrupt latency in RTEMS (Zedboard)<br>
<div class="HOEnZb"><div class="h5"><br>
Hello Sebastien,<br>
<br>
could you give a code example how you measure the interrupt latency?<br>
Which interrupt do you use?<br>
<br>
The time keeping is independent of the clock tick configuration.<br>
<br>
--<br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116">+49 89 189 47 41-16</a><br>
Fax : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109">+49 89 189 47 41-09</a><br>
E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-<wbr>brains.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
______________________________<wbr>_________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div></div>