<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 13, 2016 at 1:37 PM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">On Thu, Oct 13, 2016 at 11:21 AM, Jakob Viketoft <span dir="ltr"><<a href="mailto:jakob.viketoft@aacmicrotec.com" target="_blank">jakob.viketoft@aacmicrotec.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div>
<div style="direction:ltr;font-family:arial;color:rgb(0,0,0);font-size:10pt"><br>
<div><font size="2" face="Tahoma" color="#000000"><b>From:</b> Joel Sherrill [<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>]</font><br>
<div style="font-family:tahoma;font-size:13px">
<div style="font-family:tahoma;font-size:13px">
<div style="font-family:tahoma;font-size:13px">
<div style="font-family:tahoma;font-size:13px">
<div dir="ltr"><font size="2" face="Tahoma" color="#000000"><b>Sent:</b> Thursday, October 13, 2016 17:38<br>
<b>To:</b> Jakob Viketoft<br>
<b>Cc:</b> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<b>Subject:</b> Re: Time spent in ticks...</font><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span class="gmail-m_7333073006368272809gmail-">>I don't have an or1k handy so ran on a sparc/erc32 simulator/
<div>>It is is a SPARC v7 at 15 Mhz. </div>
<div><br>
</div>
<div>>These times are in microseconds and based on the tmtests.</div>
<div>>Specifically tm08and tm27.</div>
<div><br>
</div>
<div>
<div>>(1) rtems_clock_tick: only case - 52</div>
</div>
<div>
<div>>(2) rtems interrupt: entry overhead returns to interrupted task - 12</div>
<div>>(3) rtems interrupt: exit overhead returns to interrupted task - 4</div>
<div>>(4) rtems interrupt: entry overhead returns to nested interrupt - 11</div>
<div>>(5) rtems interrupt: exit overhead returns to nested interrupt - 3</div>
</div>
<div><br></div></span></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div></span><div>The above was from the master with SMP enabled. I repeated it with</div><div>SMP disabled and it had no impact.</div><div><br></div><div>Since the timing change is post 4.11, I decided to try 4.11 with SMP disabled:</div><div><br></div><div>rtems_clock_tick: only case - 42<br></div><div><div>rtems interrupt: entry overhead returns to interrupted task - 11</div><span class="gmail-"><div>rtems interrupt: exit overhead returns to interrupted task - 4</div></span><span class="gmail-"><div>rtems interrupt: entry overhead returns to nested interrupt - 11</div></span><span class="gmail-"><div>rtems interrupt: exit overhead returns to nested interrupt - 3</div></span></div><div><br></div><div>So 42 + 12 + 4 = 58 microseconds, 58 * 15 = 870 cycles</div><div><br></div><div>So the overhead has gone up some but as Pavel says it is quite likely</div><div>some mathematical operation on 64 bit types is slow on your CPU.</div><div><br></div><div>HINT: If you can write a benchmark for 64-bit operations,</div><div>it would be a good comparison between CPUs and might</div><div>highlight where the software implementation needs improvement.</div></div></div></div></blockquote><div><br></div><div>I decided that another good point of reference was the powerpc/psim BSP. It </div><div>reports the benchmarks in instructions:</div><div><br></div><div>(1) rtems_clock_tick: only case - 229<br></div><div><div>(2) rtems interrupt: entry overhead returns to interrupted task - 102</div><div>(3) rtems interrupt: exit overhead returns to interrupted task - 95</div><div>(4) rtems interrupt: entry overhead returns to nested interrupt - 105</div><div>(5) rtems interrupt: exit overhead returns to nested interrupt - 85</div></div><div><br></div><div>229 + 102 + 96 = 427 instructions.</div><div><br></div><div>That seems roughly inline with the erc32 which is 1 cycle for all instructions</div><div>except loads which are 3 and stores which are 2. And the sparc has</div><div>register windows so entering and exiting an ISR can potentially save</div><div>and restore a lot of registers.</div><div><br></div><div>So I am still leaning to Pavel's explanation that some primitive operation</div><div>is really inefficient.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="direction:ltr;font-family:arial;color:rgb(0,0,0);font-size:10pt"><div><div style="font-family:tahoma;font-size:13px"><div style="font-family:tahoma;font-size:13px"><div style="font-family:tahoma;font-size:13px"><div style="font-family:tahoma;font-size:13px"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_7333073006368272809gmail-"><div>
</div>
<div>>The clock tick test has 100 tasks but it looks like they are blocked on a semaphore</div>
<div>>without timeout.</div>
<div><br>
</div>
<div>>Your times look WAY too high. Maybe the interrupt is stuck on and </div>
<div>>not being cleared. </div>
<div><br>
</div>
<div>>On the erc32, a nominal "nothing to do clock tick" would be 1+2+3 from</div>
<div>>above or 52+12+4 = 68 microseconds. 68 * 15 = 1020 machine cycles.</div>
<div>>So at a higher clock rate, it should be even less time.</div>
<div><br>
</div>
<div>>My gut feeling is that I think something is wrong with the ISR handler</div>
<div>>and it is stuck. But the performance is definitely way too high.</div>
<div><br>
</div>
</span><div>>--joel<br>
<br>
(Sorry if the format got somewhat I garbled, anything but top-posting have to be done manually...)<br>
<br>
I re-tested my case using an -O3 optimization (we have been using -O0 during development for debugging purposes) and I got a good performance boost, but I'm still nowhere near your numbers. I can vouch for that the interrupt (exception really) isn't stuck,
 but that the code unfortunately takes a long time to compute. I have a subsecond counter (1/16 of a second) which I'm sampling at various places in the code, storing its numbers to a buffer in memory so as to interfere with the program as little as possible.<br>
<br>
With -O3, a tick handling still takes ~320 us to perform, but the weight has now shifted. tc_windup takes ~214 us and the rest is obviously _Watchdog_Tick(). When fragmenting the tc_windup function to find the worst speed bumps the biggest contribution (~122
 us) seem to be coming from scale factor recalculation. Since it's 64 bits, it's turned into a software function which can be quite time-consuming apparently.<br>
<br>
Even though _Watchdog_Tick() "only" takes ~100 us now, it still sound much higher than your total tick with a slower system (we're running at 50 MHz).<br>
<br>
Is there anything we can do to improve these numbers? Is Clock_isr intended to be run uninterrupted as it is now? Can't see that much of the BSP patch code has anything to do with the speed of what I'm looking at right now...<span class="gmail-m_7333073006368272809gmail-"><br>
<br>
     /Jakob<br>
<br>
<br>
<font size="2"><font color="0000FF"><b><font face="Arial"><font color="000000">Jakob Viketoft<br>
</font></font></b></font><font face="Arial"><font color="000000">Senior Engineer in RTL and embedded software<br>
<br>
ÅAC Microtec AB<br>
Dag Hammarskjölds väg 48<br>
SE-751 83 Uppsala, Sweden<br>
<br>
T: +46 702 80 95 97<br>
<a href="http://www.aacmicrotec.com" target="_blank">http://www.aacmicrotec.com</a></font></font></font></span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div style="font-family:"times new roman";color:rgb(0,0,0);font-size:16px">
<div></div>
</div>
</div>
</div>

</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>