Re: [Xenomai-core] RTOS porting on ARM

Re: [Xenomai-core] RTOS porting on ARM

[Gilles Chanteperdrix]

gclement00 at gmail.com (Gregory CLEMENT) wrote:
 > 2007/9/11, Bill Gatliff <bgat@domain.hid>:
 > > Richard Genoud wrote:
 > > >>   For an industrial control application, i need to port an RTOS pn ARM9 specifically, cirrus logic based ARM. Can anyone suggest me the chances of porting RT Linux on this ARM core. if not any other RTOS please.
 > > >>
 > > >
 > > > Hi !
 > > >
 > > > we've started to port xenomai and RTAI to arm9 (AT91RM9200 & AT91SAM926x)
 > > >
 > > > you can download the patches here :
 > > > http://www.adeneo.adetelgroup.com/srt/adeneoen/flb/show?location.id:=1452
 > > >
 > > > Richard.
 > > >
 > >
 > > Xenomai already supports the AT91RM9200.
 > 
 > Indeed and now Xenomai supports also AT91SAM9260,  AT91SAM9261 and
 > AT91SAM9263 as our patches are now in adeos.

Hi,

I have found this mail by chance with Google, and could not leave it
unanswered.

First, let me clarify the situation of Xenomai ARM port. It is a
collective work which was started more that two years ago, long before
you (Adeneo) got some interest about it. What you did was merely to
copy/paste the AT91RM9200 port I did to get it to run on
AT91SAM926x. So, please do not let people believe that you are the
authors of this port. And, by the way, ARM ports of RTAI existed for
even more time.

 > 
 > For RTAI we have now a working systeme with have better max latency
 > than Xenomai ( 50us instead of around 100us for Xenomai). I plan to
 > update the patches on our site with this new version and communicate
 > on it on RTAI list as soon as I have some free time.

A good place for discussing about these figures would have been Xenomai
mailing list, a place where we could have answered you immediately. Are
you sure you are not comparing Xenomai user-space scheduling latency
with RTAI kernel-space scheduling latency ?

Please follow up on xenomai@xenomai.org

 > 
 > And to answer to first question there is a porting guide for
 > adeos/xenomai for arm which explain what you have to do for porting
 > adeos/Xenomai for a new ARM based SOC.
 > And in a near futur I hope ther will be the same kinf of documentation for RTAI.
 > 
 > -- 
 > Gregory CLEMENT
 > Adeneo
 > 2, chemin du Ruisseau - BP21
 > 69136 Ecully Cedex
 > France
 > Tel : +33-4 72 18 08 40


-- 


					    Gilles Chanteperdrix.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: [Xenomai-core] RTOS porting on ARM

[Gilles Chanteperdrix]

Gregory CLEMENT wrote:
 > 2007/10/8, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
 > > gclement00 at gmail.com (Gregory CLEMENT) wrote:
 > >  > 2007/9/11, Bill Gatliff <bgat@domain.hid>:
 > >  > > Richard Genoud wrote:
 > >  > > >>   For an industrial control application, i need to port an RTOS pn ARM9 specifically, cirrus logic based ARM. Can anyone suggest me the chances of porting RT Linux on this ARM core. if not any other RTOS please.
 > >  > > >>
 > >  > > >
 > >  > > > Hi !
 > >  > > >
 > >  > > > we've started to port xenomai and RTAI to arm9 (AT91RM9200 & AT91SAM926x)
 > >  > > >
 > >  > > > you can download the patches here :
 > >  > > > http://www.adeneo.adetelgroup.com/srt/adeneoen/flb/show?location.id:=1452
 > >  > > >
 > >  > > > Richard.
 > >  > > >
 > >  > >
 > >  > > Xenomai already supports the AT91RM9200.
 > >  >
 > >  > Indeed and now Xenomai supports also AT91SAM9260,  AT91SAM9261 and
 > >  > AT91SAM9263 as our patches are now in adeos.
 > >
 > > Hi,
 > >
 > > I have found this mail by chance with Google, and could not leave it
 > > unanswered.
 > >
 > > First, let me clarify the situation of Xenomai ARM port. It is a
 > > collective work which was started more that two years ago,
 > 
 > I never said anything else.

Read the quoted text again: "we've started to port xenomai and RTAI to arm9 (AT91RM9200 & AT91SAM926x)"

 > >  > For RTAI we have now a working systeme with have better max latency
 > >  > than Xenomai ( 50us instead of around 100us for Xenomai). I plan to
 > >  > update the patches on our site with this new version and communicate
 > >  > on it on RTAI list as soon as I have some free time.
 > >
 > > A good place for discussing about these figures would have been Xenomai
 > > mailing list, a place where we could have answered you immediately. Are
 > > you sure you are not comparing Xenomai user-space scheduling latency
 > > with RTAI kernel-space scheduling latency ?
 > 
 > I thought a best place was RTAI list, as we ever communicated on
 > Xenomai latency on xenomai and adeos list. For example in
 > https://mail.gna.org/public/adeos-main/2007-05/msg00002.html .
 > Unfortunately, I have now a lot to do, and a very few extra time for
 > it :o/ I hope will be able to work on it soon.
 > 
 > 
 > Sorry if it this thread hurt you, it wasn't our intention to claim a
 > work we didn't have done. And I hope we will be able to work again on
 > the subject as there is still room for improvement.

The thing I do not appreciate is the claim about latencies. Either you
are right, and we should find what the problem is, or you are comparing
apples and oranges, and your statistics are totally irrelevant.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] RTOS porting on ARM

[Gilles Chanteperdrix]

On 10/9/07, Gregory CLEMENT <gclement00@domain.hid> wrote:
> 2007/10/9, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> > Gregory CLEMENT wrote:
> >  > 2007/10/8, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> >  > > gclement00 at gmail.com (Gregory CLEMENT) wrote:
> >  > >  > 2007/9/11, Bill Gatliff <bgat@domain.hid>:
> >  > >  > > Richard Genoud wrote:
> >  > >  > > >>   For an industrial control application, i need to port an RTOS pn ARM9 specifically, cirrus logic based ARM. Can anyone suggest me the chances of porting RT Linux on this ARM core. if not any other RTOS please.
> >  > >  > > >>
> >  > >  > > >
> >  > >  > > > Hi !
> >  > >  > > >
> >  > >  > > > we've started to port xenomai and RTAI to arm9 (AT91RM9200 & AT91SAM926x)
> >  > >  > > >
> >  > >  > > > you can download the patches here :
> >  > >  > > > http://www.adeneo.adetelgroup.com/srt/adeneoen/flb/show?location.id:=1452
> >  > >  > > >
> >  > >  > > > Richard.
> >  > >  > > >
> >  > >  > >
> >  > >  > > Xenomai already supports the AT91RM9200.
> >  > >  >
> >  > >  > Indeed and now Xenomai supports also AT91SAM9260,  AT91SAM9261 and
> >  > >  > AT91SAM9263 as our patches are now in adeos.
> >  > >
> >  > > Hi,
> >  > >
> >  > > I have found this mail by chance with Google, and could not leave it
> >  > > unanswered.
> >  > >
> >  > > First, let me clarify the situation of Xenomai ARM port. It is a
> >  > > collective work which was started more that two years ago,
> >  >
> >  > I never said anything else.
> >
> > Read the quoted text again: "we've started to port xenomai and RTAI to arm9 (AT91RM9200 & AT91SAM926x)"
>
> OK, but it is not me who said this. The person who said this wasn't
> really aware of our work, and misunderstood what we have done.
>
> >
> >  > >  > For RTAI we have now a working systeme with have better max latency
> >  > >  > than Xenomai ( 50us instead of around 100us for Xenomai). I plan to
> >  > >  > update the patches on our site with this new version and communicate
> >  > >  > on it on RTAI list as soon as I have some free time.
> >  > >
> >  > > A good place for discussing about these figures would have been Xenomai
> >  > > mailing list, a place where we could have answered you immediately. Are
> >  > > you sure you are not comparing Xenomai user-space scheduling latency
> >  > > with RTAI kernel-space scheduling latency ?
> >  >
> >  > I thought a best place was RTAI list, as we ever communicated on
> >  > Xenomai latency on xenomai and adeos list. For example in
> >  > https://mail.gna.org/public/adeos-main/2007-05/msg00002.html .
> >  > Unfortunately, I have now a lot to do, and a very few extra time for
> >  > it :o/ I hope will be able to work on it soon.
> >  >
> >  >
> >  > Sorry if it this thread hurt you, it wasn't our intention to claim a
> >  > work we didn't have done. And I hope we will be able to work again on
> >  > the subject as there is still room for improvement.
> >
> > The thing I do not appreciate is the claim about latencies. Either you
> > are right, and we should find what the problem is, or you are comparing
> > apples and oranges, and your statistics are totally irrelevant.
>
> But you have the test latency we ran. We compared latency in the best
> mode of both RTAI and Xenomai, ie in kernel mode.

If I read the statistics you posted on the Adeos mailing list, here:
https://mail.gna.org/public/adeos-main/2007-06/msg00023.html

You had latencies smaller than 100us already in user-space. So, the
fact that you get higher latencies in kernel-space is highly
suspicious.

> In RTAI path from it to RTAI seems more direct than in Xenomai even in
> kernel mode. I say this by reading code, it is not just a guess. So it
> is not surprising to me that there is better latency in RTAI. I am not
> sure there is a problem to find, the software architecture are
> different.

Latencies are supposed to be due to hardware effects, the software
path should have little effect. If software has such an high effect
then we have a problem. But as I said, a 100 us latency in
kernel-space is suspicious if you get latencies smaller than 100us in
user-space.

> You can test RTAI on AT91RM9200 (as AT91RM9200 is merly equal to
> AT91SAM926x) the patches are on RTAI contrib repository:
> http://www.rtai.org/RTAICONTRIB/

You are the one who publishes comparisons, so you are the one who
should run the tests rigorously.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-core] RTOS porting on ARM

[Gregory CLEMENT]

2007/10/9, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> On 10/9/07, Gregory CLEMENT <gclement00@domain.hid> wrote:
> > 2007/10/9, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> > > Gregory CLEMENT wrote:
> > >  > 2007/10/8, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> > >  > > gclement00 at gmail.com (Gregory CLEMENT) wrote:
> > >  > >  > 2007/9/11, Bill Gatliff <bgat@domain.hid>:
> > >  > >  > > Richard Genoud wrote:
> > >  > >  > > >>   For an industrial control application, i need to port an RTOS pn ARM9 specifically, cirrus logic based ARM. Can anyone suggest me the chances of porting RT Linux on this ARM core. if not any other RTOS please.
> > >  > >  > > >>
> > >  > >  > > >
> > >  > >  > > > Hi !
> > >  > >  > > >
> > >  > >  > > > we've started to port xenomai and RTAI to arm9 (AT91RM9200 & AT91SAM926x)
> > >  > >  > > >
> > >  > >  > > > you can download the patches here :
> > >  > >  > > > http://www.adeneo.adetelgroup.com/srt/adeneoen/flb/show?location.id:=1452
> > >  > >  > > >
> > >  > >  > > > Richard.
> > >  > >  > > >
> > >  > >  > >
> > >  > >  > > Xenomai already supports the AT91RM9200.
> > >  > >  >
> > >  > >  > Indeed and now Xenomai supports also AT91SAM9260,  AT91SAM9261 and
> > >  > >  > AT91SAM9263 as our patches are now in adeos.
> > >  > >
> > >  > > Hi,
> > >  > >
> > >  > > I have found this mail by chance with Google, and could not leave it
> > >  > > unanswered.
> > >  > >
> > >  > > First, let me clarify the situation of Xenomai ARM port. It is a
> > >  > > collective work which was started more that two years ago,
> > >  >
> > >  > I never said anything else.
> > >
> > > Read the quoted text again: "we've started to port xenomai and RTAI to arm9 (AT91RM9200 & AT91SAM926x)"
> >
> > OK, but it is not me who said this. The person who said this wasn't
> > really aware of our work, and misunderstood what we have done.
> >
> > >
> > >  > >  > For RTAI we have now a working systeme with have better max latency
> > >  > >  > than Xenomai ( 50us instead of around 100us for Xenomai). I plan to
> > >  > >  > update the patches on our site with this new version and communicate
> > >  > >  > on it on RTAI list as soon as I have some free time.
> > >  > >
> > >  > > A good place for discussing about these figures would have been Xenomai
> > >  > > mailing list, a place where we could have answered you immediately. Are
> > >  > > you sure you are not comparing Xenomai user-space scheduling latency
> > >  > > with RTAI kernel-space scheduling latency ?
> > >  >
> > >  > I thought a best place was RTAI list, as we ever communicated on
> > >  > Xenomai latency on xenomai and adeos list. For example in
> > >  > https://mail.gna.org/public/adeos-main/2007-05/msg00002.html .
> > >  > Unfortunately, I have now a lot to do, and a very few extra time for
> > >  > it :o/ I hope will be able to work on it soon.
> > >  >
> > >  >
> > >  > Sorry if it this thread hurt you, it wasn't our intention to claim a
> > >  > work we didn't have done. And I hope we will be able to work again on
> > >  > the subject as there is still room for improvement.
> > >
> > > The thing I do not appreciate is the claim about latencies. Either you
> > > are right, and we should find what the problem is, or you are comparing
> > > apples and oranges, and your statistics are totally irrelevant.
> >
> > But you have the test latency we ran. We compared latency in the best
> > mode of both RTAI and Xenomai, ie in kernel mode.
>
> If I read the statistics you posted on the Adeos mailing list, here:
> https://mail.gna.org/public/adeos-main/2007-06/msg00023.html
>
> You had latencies smaller than 100us already in user-space. So, the
> fact that you get higher latencies in kernel-space is highly
> suspicious.

Where do you see it is in user space ? The latency are colected in
kernel module, it is just display wich is in user space.
Then the 100us I mentionned are under calibrator load, which is the
application which give the worse resulats. On the result yout point
the max lantency is 200us.
We reached 100us by set dbgu priority to 6, and maintain timer
priority to 7. Indeed serial output on dbu give bad latency as it its
peripheral ID is 0, so with the same level of priority in AIC, its
interrupt are treated first. We change this in adeos fot both RTAI and
Xenomai.
Maybe this change can be done in adeos main tree.

>
> > In RTAI path from it to RTAI seems more direct than in Xenomai even in
> > kernel mode. I say this by reading code, it is not just a guess. So it
> > is not surprising to me that there is better latency in RTAI. I am not
> > sure there is a problem to find, the software architecture are
> > different.
>
> Latencies are supposed to be due to hardware effects, the software
> path should have little effect. If software has such an high effect
> then we have a problem. But as I said, a 100 us latency in
> kernel-space is suspicious if you get latencies smaller than 100us in
> user-space.
>
> > You can test RTAI on AT91RM9200 (as AT91RM9200 is merly equal to
> > AT91SAM926x) the patches are on RTAI contrib repository:
> > http://www.rtai.org/RTAICONTRIB/
>
> You are the one who publishes comparisons, so you are the one who
> should run the tests rigorously.

I thinks our tests are rigorous, but I am open to disuss of it.

>
> --
>                                                Gilles Chanteperdrix
>


-- 
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
France
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41

www.adetelgroup.com

Re: [Xenomai-core] RTOS porting on ARM

[Gilles Chanteperdrix]

On 10/9/07, Gregory CLEMENT <gclement00@domain.hid> wrote:
> 2007/10/9, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> > You had latencies smaller than 100us already in user-space. So, the
> > fact that you get higher latencies in kernel-space is highly
> > suspicious.
>
> Where do you see it is in user space ? The latency are colected in
> kernel module, it is just display wich is in user space.

No, the first and third test mentions clearly "periodic user-mode
task", which means that you launched the latency test with no -t
option or with -t 0, in this case, latencies are collected in
user-space. If you want to collect latencies in kernel space, you
should run latency with the -t 1 (kernel-space thread) or -t 2
(kernel-space timer handler) option.

> Then the 100us I mentionned are under calibrator load, which is the
> application which give the worse resulats. On the result yout point
> the max lantency is 200us.

Ok, I missed this one because I did not see the RTT header.

> We reached 100us by set dbgu priority to 6, and maintain timer
> priority to 7. Indeed serial output on dbu give bad latency as it its
> peripheral ID is 0, so with the same level of priority in AIC, its
> interrupt are treated first. We change this in adeos fot both RTAI and
> Xenomai.
> Maybe this change can be done in adeos main tree.

Well, that is interesting. But it would have been nice to tell us
about this, so that we could have fixed the I-pipe patch.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-core] RTOS porting on ARM

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> gclement00 at gmail.com (Gregory CLEMENT) wrote:
>  > 
>  > For RTAI we have now a working systeme with have better max latency
>  > than Xenomai ( 50us instead of around 100us for Xenomai). I plan to
>  > update the patches on our site with this new version and communicate
>  > on it on RTAI list as soon as I have some free time.
> 
> A good place for discussing about these figures would have been Xenomai
> mailing list, a place where we could have answered you immediately. Are
> you sure you are not comparing Xenomai user-space scheduling latency
> with RTAI kernel-space scheduling latency ?

Me too asked Gregory for some discussion on this long ago but received
no response.

Anyway, the critical thing beyond latencies remains *maintenance*. If
someone decides to apply I-pipe on RTAI *and* doesn't forget to
contribute to the mandatory bits of the Adeos project, work actively
within that community (test new versions and report results, track down
bugs, port to new kernels releases, etc.), anyone would benefit in the
end. BTW, that would surely stimulate discussions about differing
numbers on both sides as well.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] RTOS porting on ARM

[Jan Kiszka]

Gregory CLEMENT wrote:
> 2007/10/9, Jan Kiszka <jan.kiszka@domain.hid>:
>> Gilles Chanteperdrix wrote:
>>> gclement00 at gmail.com (Gregory CLEMENT) wrote:
>>>  >
>>>  > For RTAI we have now a working systeme with have better max latency
>>>  > than Xenomai ( 50us instead of around 100us for Xenomai). I plan to
>>>  > update the patches on our site with this new version and communicate
>>>  > on it on RTAI list as soon as I have some free time.
>>>
>>> A good place for discussing about these figures would have been Xenomai
>>> mailing list, a place where we could have answered you immediately. Are
>>> you sure you are not comparing Xenomai user-space scheduling latency
>>> with RTAI kernel-space scheduling latency ?
>> Me too asked Gregory for some discussion on this long ago but received
>> no response.
>>
>> Anyway, the critical thing beyond latencies remains *maintenance*. If
>> someone decides to apply I-pipe on RTAI *and* doesn't forget to
>> contribute to the mandatory bits of the Adeos project, work actively
>> within that community (test new versions and report results, track down
>> bugs, port to new kernels releases, etc.), anyone would benefit in the
>> end. BTW, that would surely stimulate discussions about differing
>> numbers on both sides as well.
> 
> And you think we didn't contribute to adeos projects, test new version
> and report result???
> Because it is exactly what we have done.

You did this for the startup of this port, and it is highly appreciated.
But such things require lasting effort. Probably I'm just so sceptical
because there have been many people before posting patches once and then
never again. Just look at RTAI's ARM history of the last, mmh, 4 years.
I'm always happy being proved wrong regarding such scepticisms of mine!

> Our result on RTAI are pretty recent, and the lack of discussion on it
> is only a lack of time and not a lack of wiling.

Then I'm looking forward to have this now, e.g. backed up with tracer
outputs of both variants.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] RTOS porting on ARM

[Gregory CLEMENT]

2007/10/9, Jan Kiszka <jan.kiszka@domain.hid>:
> Gregory CLEMENT wrote:
> > 2007/10/9, Jan Kiszka <jan.kiszka@domain.hid>:
> >> Gilles Chanteperdrix wrote:
> >>> gclement00 at gmail.com (Gregory CLEMENT) wrote:
> >>>  >
> >>>  > For RTAI we have now a working systeme with have better max latency
> >>>  > than Xenomai ( 50us instead of around 100us for Xenomai). I plan to
> >>>  > update the patches on our site with this new version and communicate
> >>>  > on it on RTAI list as soon as I have some free time.
> >>>
> >>> A good place for discussing about these figures would have been Xenomai
> >>> mailing list, a place where we could have answered you immediately. Are
> >>> you sure you are not comparing Xenomai user-space scheduling latency
> >>> with RTAI kernel-space scheduling latency ?
> >> Me too asked Gregory for some discussion on this long ago but received
> >> no response.
> >>
> >> Anyway, the critical thing beyond latencies remains *maintenance*. If
> >> someone decides to apply I-pipe on RTAI *and* doesn't forget to
> >> contribute to the mandatory bits of the Adeos project, work actively
> >> within that community (test new versions and report results, track down
> >> bugs, port to new kernels releases, etc.), anyone would benefit in the
> >> end. BTW, that would surely stimulate discussions about differing
> >> numbers on both sides as well.
> >
> > And you think we didn't contribute to adeos projects, test new version
> > and report result???
> > Because it is exactly what we have done.
>
> You did this for the startup of this port, and it is highly appreciated.
> But such things require lasting effort. Probably I'm just so sceptical
> because there have been many people before posting patches once and then
> never again. Just look at RTAI's ARM history of the last, mmh, 4 years.
> I'm always happy being proved wrong regarding such scepticisms of mine!

There is no more post on adeos mailing list just because we didn't
change it, since our last post.
As I mentioned earlier we just set dbgu priority level at a different
level, it is not a big change, but I will post the patch for it.

> > Our result on RTAI are pretty recent, and the lack of discussion on it
> > is only a lack of time and not a lack of wiling.
>
> Then I'm looking forward to have this now, e.g. backed up with tracer
> outputs of both variants.

As I mentionned, that for now, I am deep under load ? Because I am,
and so I will do my best but time is not extensible unforutnately.

>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT SE 2
> Corporate Competence Center Embedded Linux
>


-- 
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
France
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41

www.adetelgroup.com

Re: [Xenomai-core] RTOS porting on ARM

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3153 bytes --]

[Switching the account to underline again that this is my personal POV.]

Gregory CLEMENT wrote:
> 2007/10/9, Jan Kiszka <jan.kiszka@domain.hid>:
>> Gregory CLEMENT wrote:
>>> 2007/10/9, Jan Kiszka <jan.kiszka@domain.hid>:
>>>> Gilles Chanteperdrix wrote:
>>>>> gclement00 at gmail.com (Gregory CLEMENT) wrote:
>>>>>  >
>>>>>  > For RTAI we have now a working systeme with have better max latency
>>>>>  > than Xenomai ( 50us instead of around 100us for Xenomai). I plan to
>>>>>  > update the patches on our site with this new version and communicate
>>>>>  > on it on RTAI list as soon as I have some free time.
>>>>>
>>>>> A good place for discussing about these figures would have been Xenomai
>>>>> mailing list, a place where we could have answered you immediately. Are
>>>>> you sure you are not comparing Xenomai user-space scheduling latency
>>>>> with RTAI kernel-space scheduling latency ?
>>>> Me too asked Gregory for some discussion on this long ago but received
>>>> no response.
>>>>
>>>> Anyway, the critical thing beyond latencies remains *maintenance*. If
>>>> someone decides to apply I-pipe on RTAI *and* doesn't forget to
>>>> contribute to the mandatory bits of the Adeos project, work actively
>>>> within that community (test new versions and report results, track down
>>>> bugs, port to new kernels releases, etc.), anyone would benefit in the
>>>> end. BTW, that would surely stimulate discussions about differing
>>>> numbers on both sides as well.
>>> And you think we didn't contribute to adeos projects, test new version
>>> and report result???
>>> Because it is exactly what we have done.
>> You did this for the startup of this port, and it is highly appreciated.
>> But such things require lasting effort. Probably I'm just so sceptical
>> because there have been many people before posting patches once and then
>> never again. Just look at RTAI's ARM history of the last, mmh, 4 years.
>> I'm always happy being proved wrong regarding such scepticisms of mine!
> 
> There is no more post on adeos mailing list just because we didn't
> change it, since our last post.
> As I mentioned earlier we just set dbgu priority level at a different
> level, it is not a big change, but I will post the patch for it.

Tiny change, but probably significant impact. Every generic improvement
is worth posting. You will help others to exploit it, and you will also
allow other professionals to give you feedback on the changes. The old
story of open source.

>>> Our result on RTAI are pretty recent, and the lack of discussion on it
>>> is only a lack of time and not a lack of wiling.
>> Then I'm looking forward to have this now, e.g. backed up with tracer
>> outputs of both variants.
> 
> As I mentionned, that for now, I am deep under load ? Because I am,
> and so I will do my best but time is not extensible unforutnately.

I understand that (as long as you do not spread half-explained
benchmarks at the same time). Well, maybe you then recall even better
the concerns I sent you earlier about required future maintenance
efforts vs. available time...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]