[Xenomai-help] Is xenomai OK for early boot purpose ?

[Xenomai-help] Is xenomai OK for early boot purpose ?

[gryma biloy]

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)
  - early boot operations (i.e. being able to perform some tasks asap
after a power on reset)

I've searched for solutions over the net and Xenomai seems to be a
possible candidate to fulfill
these constraints. Can you please share your knowledge to confirm that
Xenomai would make
the job (especially on the early boot side) ?

Also, I don't have a clear understanding of Xenomai availability
during the Linux kernel startup.
If a statically link Xenomai to the kernel, when would it be operational ?

Thanks a lot for your help,

--
Gryma

Re: [Xenomai-help] Is xenomai OK for early boot purpose ?

[Philippe Gerum]

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?

>   - early boot operations (i.e. being able to perform some tasks asap
> after a power on reset)
> 
> I've searched for solutions over the net and Xenomai seems to be a
> possible candidate to fulfill
> these constraints. Can you please share your knowledge to confirm that
> Xenomai would make
> the job (especially on the early boot side) ?
> 

I don't see how Xenomai could directly help in any way for the early
boot goal. If you question is about whether Xenomai initializes fast
enough, and early enough during the linux boot process for kicking rt
applications as soon as possible, then the answer is yes, that should
do.

> Also, I don't have a clear understanding of Xenomai availability
> during the Linux kernel startup.
> If a statically link Xenomai to the kernel, when would it be operational ?
> 

When built statically into the kernel, Xenomai initializes along with
the linux drivers. So once this init stage is passed, Xenomai is up and
running, ready to run applications.

> Thanks a lot for your help,
> 
> --
> Gryma
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.

Re: [Xenomai-help] Is xenomai OK for early boot purpose ?

[Gilles Chanteperdrix]

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.

>
>>   - early boot operations (i.e. being able to perform some tasks asap
>> after a power on reset)
>>
>> I've searched for solutions over the net and Xenomai seems to be a
>> possible candidate to fulfill
>> these constraints. Can you please share your knowledge to confirm that
>> Xenomai would make
>> the job (especially on the early boot side) ?
>>
>
> I don't see how Xenomai could directly help in any way for the early
> boot goal. If you question is about whether Xenomai initializes fast
> enough, and early enough during the linux boot process for kicking rt
> applications as soon as possible, then the answer is yes, that should
> do.

Well, user-space applications will not get started before user-space is
started, i.e. basically before root filesystem has been mounted and init
is running. You could write your real-time application as the init
application, but that would be kind of awkward.

-- 
					    Gilles.

Re: [Xenomai-help] Is xenomai OK for early boot purpose ?

[Philippe Gerum]

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.

> 
> >
> >>   - early boot operations (i.e. being able to perform some tasks asap
> >> after a power on reset)
> >>
> >> I've searched for solutions over the net and Xenomai seems to be a
> >> possible candidate to fulfill
> >> these constraints. Can you please share your knowledge to confirm that
> >> Xenomai would make
> >> the job (especially on the early boot side) ?
> >>
> >
> > I don't see how Xenomai could directly help in any way for the early
> > boot goal. If you question is about whether Xenomai initializes fast
> > enough, and early enough during the linux boot process for kicking rt
> > applications as soon as possible, then the answer is yes, that should
> > do.
> 
> Well, user-space applications will not get started before user-space is
> started, i.e. basically before root filesystem has been mounted and init
> is running. You could write your real-time application as the init
> application, but that would be kind of awkward.
> 

-- 
Philippe.

Re: [Xenomai-help] Is xenomai OK for early boot purpose ?

[gryma biloy]

On Mon, Jan 31, 2011 at 11:53 AM, Philippe Gerum <rpm@xenomai.org> 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 ?



>> >>   - early boot operations (i.e. being able to perform some tasks asap
>> >> after a power on reset)
>> >>

>> >
>> > I don't see how Xenomai could directly help in any way for the early
>> > boot goal. If you question is about whether Xenomai initializes fast
>> > enough, and early enough during the linux boot process for kicking rt
>> > applications as soon as possible, then the answer is yes, that should
>> > do.
>>
>> Well, user-space applications will not get started before user-space is
>> started, i.e. basically before root filesystem has been mounted and init
>> is running. You could write your real-time application as the init
>> application, but that would be kind of awkward.


Understand. I will make a try a see if I can meet some of my constraints.

Thanks for your replies,

-- 
Gryma

Re: [Xenomai-help] Is xenomai OK for early boot purpose ?

[Philippe Gerum]

On Mon, 2011-01-31 at 12:01 +0100, gryma biloy wrote:
> On Mon, Jan 31, 2011 at 11:53 AM, Philippe Gerum <rpm@xenomai.org> 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 ?


The main reason for more jittery with longer periods is due to the cache
if you compare a high frequency loop and a lower one. When the rt system
is idle, waiting for the next wakeup, the linux activity resumes and
evicts a bunch of cachelines for running its own processes. So next time
the rt system is resumed, a significant time will be spent refilling the
cache with the rt program, starting with some real-time IRQ handler
itself. This is why you always get better latencies when running a 10Khz
sampling loop, than you would get for 1Khz. This can be observed on all
archs Xenomai supports.

On ARM, the memory subsystem is often involved in jittery for different
reasons (ask Gilles why he implemented FCSE for instance).

> 
> 
> 
> >> >>   - early boot operations (i.e. being able to perform some tasks asap
> >> >> after a power on reset)
> >> >>
> 
> >> >
> >> > I don't see how Xenomai could directly help in any way for the early
> >> > boot goal. If you question is about whether Xenomai initializes fast
> >> > enough, and early enough during the linux boot process for kicking rt
> >> > applications as soon as possible, then the answer is yes, that should
> >> > do.
> >>
> >> Well, user-space applications will not get started before user-space is
> >> started, i.e. basically before root filesystem has been mounted and init
> >> is running. You could write your real-time application as the init
> >> application, but that would be kind of awkward.
> 
> 
> Understand. I will make a try a see if I can meet some of my constraints.
> 
> Thanks for your replies,
> 

-- 
Philippe.

Re: [Xenomai-help] Is xenomai OK for early boot purpose ?

[Gilles Chanteperdrix]

gryma biloy wrote:
> On Mon, Jan 31, 2011 at 11:53 AM, Philippe Gerum <rpm@xenomai.org> 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.

Re: [Xenomai-help] Is xenomai OK for early boot purpose ?

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Mon, 2011-01-31 at 12:01 +0100, gryma biloy wrote:
>> On Mon, Jan 31, 2011 at 11:53 AM, Philippe Gerum <rpm@xenomai.org> 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 ?
> 
> 
> The main reason for more jittery with longer periods is due to the cache
> if you compare a high frequency loop and a lower one. When the rt system
> is idle, waiting for the next wakeup, the linux activity resumes and
> evicts a bunch of cachelines for running its own processes. So next time
> the rt system is resumed, a significant time will be spent refilling the
> cache with the rt program, starting with some real-time IRQ handler
> itself. This is why you always get better latencies when running a 10Khz
> sampling loop, than you would get for 1Khz. This can be observed on all
> archs Xenomai supports.
> 
> On ARM, the memory subsystem is often involved in jittery for different
> reasons (ask Gilles why he implemented FCSE for instance).

Well actually, this effect can not be observed on ARMv4/v6 without FCSE,
because the cache is flushed at each context switch.

-- 
					    Gilles.

Re: [Xenomai-help] Is xenomai OK for early boot purpose ?

[Philippe Gerum]

On Mon, 2011-01-31 at 12:17 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Mon, 2011-01-31 at 12:01 +0100, gryma biloy wrote:
> >> On Mon, Jan 31, 2011 at 11:53 AM, Philippe Gerum <rpm@xenomai.org> 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 ?
> > 
> > 
> > The main reason for more jittery with longer periods is due to the cache
> > if you compare a high frequency loop and a lower one. When the rt system
> > is idle, waiting for the next wakeup, the linux activity resumes and
> > evicts a bunch of cachelines for running its own processes. So next time
> > the rt system is resumed, a significant time will be spent refilling the
> > cache with the rt program, starting with some real-time IRQ handler
> > itself. This is why you always get better latencies when running a 10Khz
> > sampling loop, than you would get for 1Khz. This can be observed on all
> > archs Xenomai supports.
> > 
> > On ARM, the memory subsystem is often involved in jittery for different
> > reasons (ask Gilles why he implemented FCSE for instance).
> 
> Well actually, this effect can not be observed on ARMv4/v6 without FCSE,
> because the cache is flushed at each context switch.
> 

Unfortunately, we do have memory subsystem issues not directly involving
tlb flushes and FCSE over v5. Typically, the lack of hw-assisted
broadcasting of DMA operations with arm11/mpcore in SMP mode is a real
pain as well.

-- 
Philippe.

Re: [Xenomai-help] Is xenomai OK for early boot purpose ?

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> gryma biloy wrote:
>> On Mon, Jan 31, 2011 at 11:53 AM, Philippe Gerum <rpm@xenomai.org> 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.

In particular, things could be improved if we found a way to use the
SRAM on OMAP3, either for some critical code, or data, or both. This of
course, if you do not need the SRAM on OMAP3 (so, if you do not use the
hardware accelerated multi-media capabilities, I guess). I have this
idea in mind for some time, but never found time to try it. Probably
much easier for data than for code, though not impossible.

-- 
					    Gilles.