Hello everyone,
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.
To the questions:
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.
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.
Oh, and we use 10000 as base for the tick quantum.
(If anyone is interested in looking at our code, bsps and toolchains can be
downloaded at repo.aacmicrotec.com.)
Best regards,
/Jakob
Jakob Viketoft
Senior Engineer in RTL and embedded software
ÅAC Microtec AB
Dag Hammarskjölds väg 48
SE-751 83 Uppsala, Sweden
T: +46 702 80 95 97
http://www.aacmicrotec.com
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
