Re: [Xenomai-core] RTOS porting on ARM
Gregory CLEMENT wrote: 2007/10/8, Gilles Chanteperdrix [EMAIL PROTECTED]: gclement00 at gmail.com (Gregory CLEMENT) wrote: 2007/9/11, Bill Gatliff [EMAIL PROTECTED]: 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/msg2.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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTOS porting on ARM
gclement00 at gmail.com (Gregory CLEMENT) wrote: 2007/9/11, Bill Gatliff [EMAIL PROTECTED]: 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-core@gna.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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTOS porting on ARM
2007/10/9, Gilles Chanteperdrix [EMAIL PROTECTED]: On 10/9/07, Gregory CLEMENT [EMAIL PROTECTED] wrote: 2007/10/9, Gilles Chanteperdrix [EMAIL PROTECTED]: Gregory CLEMENT wrote: 2007/10/8, Gilles Chanteperdrix [EMAIL PROTECTED]: gclement00 at gmail.com (Gregory CLEMENT) wrote: 2007/9/11, Bill Gatliff [EMAIL PROTECTED]: 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/msg2.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. --
Re: [Xenomai-core] RTOS porting on ARM
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTOS porting on ARM
On 10/9/07, Gregory CLEMENT [EMAIL PROTECTED] wrote: 2007/10/9, Gilles Chanteperdrix [EMAIL PROTECTED]: 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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTOS porting on ARM
Gregory CLEMENT wrote: 2007/10/9, Jan Kiszka [EMAIL PROTECTED]: 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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTOS porting on ARM
2007/10/9, Jan Kiszka [EMAIL PROTECTED]: Gregory CLEMENT wrote: 2007/10/9, Jan Kiszka [EMAIL PROTECTED]: 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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTOS porting on ARM
[Switching the account to underline again that this is my personal POV.] Gregory CLEMENT wrote: 2007/10/9, Jan Kiszka [EMAIL PROTECTED]: Gregory CLEMENT wrote: 2007/10/9, Jan Kiszka [EMAIL PROTECTED]: 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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core