<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 13, 2016 at 3:51 AM, Jakob Viketoft <span dir="ltr"><<a href="mailto:jakob.viketoft@aacmicrotec.com" target="_blank">jakob.viketoft@aacmicrotec.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">Hello everyone,<br>
<br>
We're running on an or1k-based BSP off of 4.11 (with the patches I've forwarded in February last year) and have seen some strange sluggishness in the system. When measuring using a standalone peripheral clock, I can see that we spend between 0.8 - 1.4 ms just handling the tick. This sounds a bit absurd to me and I just wanted to send out a couple of questions to see if anyone has an inkling of what is going on. I haven't been able to test with the or1k-simulator (and the generic_or1k BSP) as it won't easily compile with a newer gcc, but I'm running on real hardware. The patches I made don't sound like big hold-ups to me either, but a second pair of eyes is of course always welcome.<br>
<br>
To the questions:<br>
1. On the or1k-cpu RTEMS bsp, timer ticks are using the cpu-internal timer, which when timing out results in a timer exception. Clock_isr is installed as the exception handler for this and thus have complete control of the cpu for it's duration. Is this as the Clock_isr is intended to run, i.e. no other tasks or interrupts are allowed during tick handling? Just want to make sure there is no mismatch between the or1k setup in RTEMS and how Clock_isr is intended to run.<br>
<br>
2. Running a very simple test application with three tasks, I delved into the _Timecounter_Tick part of the Clock_isr and I have seen the tc_windup() is using ~340 us quite consistently and _Watchdog_Tick() is using ~630 when all tasks are started. What numbers can be seen at other systems, i.e. what should I expect as normal here? Any ideas on what can be wrong? I'll keep digging and try to discern any individual culprits as well.<br>
<br></blockquote><div><br></div><div>I don't have an or1k handy so ran on a sparc/erc32 simulator/</div><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><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><div>--joel</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">
Oh, and we use 10000 as base for the tick quantum.<br>
<br>
(If anyone is interested in looking at our code, bsps and toolchains can be downloaded at <a href="http://repo.aacmicrotec.com" rel="noreferrer" target="_blank">repo.aacmicrotec.com</a>.)<br>
<br>
Best regards,<br>
<br>
      /Jakob<br>
<br>
<br>
Jakob Viketoft<br>
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: <a href="tel:%2B46%20702%2080%2095%2097" value="+46702809597">+46 702 80 95 97</a><br>
<a href="http://www.aacmicrotec.com" rel="noreferrer" target="_blank">http://www.aacmicrotec.com</a><br>
______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
</blockquote></div><br></div></div>