gryma biloy wrote:
> On Mon, Jan 31, 2011 at 11:53 AM, Philippe Gerum <[email protected]> wrote:
>> On Mon, 2011-01-31 at 11:51 +0100, Gilles Chanteperdrix wrote:
>>> Philippe Gerum wrote:
>>>> On Mon, 2011-01-31 at 09:55 +0100, gryma biloy wrote:
>>>>> Hello,
>>>>>
>>>>> On a project running Linux on a beagle board, I'd like to add the
>>>>> following capabilities to my platform :
>>>>> - real time processes with periodic tasks (10ms, 100ms & 200 ms) and
>>>>> a low jitter (< 50 us)
>>>> Kernel space apps then, likely. Userland apps (the recommended way)
>>>> probably have a larger worst-case jitter on this hardware, albeit still
>>>> below 100 us. Gilles?
>>> Las time I checked, latency measured on a 720MHz omap3 was around 55us
>>> with a 1ms period and 35us with a 100us period.
>> Yeah, I suspect that longer periods ( >= 10 ms ) may introduce more
>> opportunities for cache eviction due to linux activity, and therefore
>> higher jittery, even if bounded.
>
> Does this mean that the main reason for jittery is due to the cache ?
> What would be the other reasons, if any ?
interrupt latency is mainly due to interrupts masking sections in the
kernel, and the time to reach the code of the interrupt handler when an
interrupt is received, including the time it takes to preempt current
context to go to interrupt mode, then to access the hardware to mask/ack
the interrupt.
scheduling latency (of the higher priority task) is bound roughly by
interrupt latency plus the time that it takes to switch context in
kernel-space, plus the time that it takes to return to user-space.
All these paths are made of code which is executed and which access
data, and so which execution time depend on both I-cache and D-cache.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
