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] crashing 2.6.22
On Mon, 2007-10-08 at 10:45 +0200, Gilles Chanteperdrix wrote: Ooops. By reading all my mails, I would have avoided reinventing this wheel on my own. Your patch is almost what I posted yesterday to fix the vmalloc issue. Looks like we no longer need the last hunk of it on recent kernels, right? Yes, it fixes an issue which was fixed a long time ago. Yeah, my mistake. I've postponed this patch and forgot to push it forward again after the testing period in my cooker. Sorry about that. Jan PS: We should really consider using bug trackers for Adeos and Xenomai! I have a few (minor) patches hanging around as well, but things quickly get lost when bigger problems pop up. We have bug trackers, the point is think about using them. Indeed. We even have patch trackers we could activate. Either we use them, or any patch sent for inclusion should be posted in a separate mail to the -core list, with a [PATCH] header. I'm sometimes missing them because they are part of a lengthy conversation, buried under lots of mail I could fast-forward a bit aggressively. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
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] [PATCH] documentation: rtdm functions available in user space
Johan Borkhuis wrote: When checking the documentation I found that a lot of rtdm functions are indicated as available in user space, but AFAIK these functions are only available in kernel space or interrupt contect. The documentation is generated using ksrc/skin/rtdm/drvlib.c. Below is a patch file that corrects this. (I did not check other documentation to see if there are more functions defined for use in user space) The problem is not User-space task, but rather the headline Environments. The latter term is obviously not that clear. It is meant to express the Execution context of the service caller. Would that term make it clearer? Thanks for picking this up, 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
[Xenomai-core] RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
Here, they are the last latency we get on AT91SAM9261-EK. As just now I haven't the board at home, I send the last result we stored. The prority of dbgu should be set to 6 instead of 7, but I can't assure it, for Xenomai. first Xenomai: #insmod /lib/modules/2.6.20.13/kernel/drivers/xenomai/testing/xeno_timerbench.ko #cd /usr/xenomai/bin/ #./latency -t 2 -p 150 -h -H 500 ---|--param|range-|--samples HSD|min| 3 - 4 |6 HSD|min| 4 - 5 | 12 HSD|min| 5 - 6 |5 HSD|min| 6 - 7 | 128 HSD|min| 7 - 8 | 405 HSD|min| 8 - 9 | 18 ---|--param|range-|--samples HSD|avg| 3 - 4 |6 HSD|avg| 4 - 5 | 12 HSD|avg| 5 - 6 |5 HSD|avg| 6 - 7 | 1248 HSD|avg| 7 - 8 | 1159824 HSD|avg| 8 - 9 | 1188725 HSD|avg| 9 - 10 | 238045 HSD|avg| 10 - 11 |78398 HSD|avg| 11 - 12 | 134973 HSD|avg| 12 - 13 | 132552 HSD|avg| 13 - 14 | 129661 HSD|avg| 14 - 15 | 137458 HSD|avg| 15 - 16 |49208 HSD|avg| 16 - 17 | 4532 HSD|avg| 17 - 18 | 2793 HSD|avg| 18 - 19 | 2494 HSD|avg| 19 - 20 | 2489 HSD|avg| 20 - 21 | 2373 HSD|avg| 21 - 22 | 3677 HSD|avg| 22 - 23 |15370 HSD|avg| 23 - 24 | 173411 HSD|avg| 24 - 25 | 181883 HSD|avg| 25 - 26 | 1509 HSD|avg| 26 - 27 | 5058 HSD|avg| 27 - 28 | 9483 HSD|avg| 28 - 29 |19691 HSD|avg| 29 - 30 |18397 HSD|avg| 30 - 31 |24228 HSD|avg| 31 - 32 |19539 HSD|avg| 32 - 33 |20438 HSD|avg| 33 - 34 |17420 HSD|avg| 34 - 35 |19943 HSD|avg| 35 - 36 |15057 HSD|avg| 36 - 37 |12100 HSD|avg| 37 - 38 | 1873 HSD|avg| 38 - 39 | 417 HSD|avg| 39 - 40 | 347 HSD|avg| 40 - 41 | 282 HSD|avg| 41 - 42 | 177 HSD|avg| 42 - 43 | 106 HSD|avg| 43 - 44 | 108 HSD|avg| 44 - 45 | 94 HSD|avg| 45 - 46 | 138 HSD|avg| 46 - 47 | 114 HSD|avg| 47 - 48 | 109 HSD|avg| 48 - 49 | 50 HSD|avg| 49 - 50 | 35 HSD|avg| 50 - 51 | 40 HSD|avg| 51 - 52 | 32 HSD|avg| 52 - 53 | 23 HSD|avg| 53 - 54 | 21 HSD|avg| 54 - 55 | 13 HSD|avg| 55 - 56 | 12 HSD|avg| 56 - 57 | 13 HSD|avg| 57 - 58 | 15 HSD|avg| 58 - 59 | 24 HSD|avg| 59 - 60 | 13 HSD|avg| 60 - 61 | 22 HSD|avg| 61 - 62 | 29 HSD|avg| 62 - 63 | 13 HSD|avg| 63 - 64 |7 HSD|avg| 64 - 65 |8 HSD|avg| 65 - 66 | 13 HSD|avg| 66 - 67 |8 HSD|avg| 67 - 68 |7 HSD|avg| 68 - 69 |5 HSD|avg| 69 - 70 |8 HSD|avg| 70 - 71 |4 HSD|avg| 71 - 72 |9 HSD|avg| 72 - 73 |8 HSD|avg| 73 - 74 | 13 HSD|avg| 74 - 75 |9 HSD|avg| 75 - 76 |6 HSD|avg| 76 - 77 |4 HSD|avg| 77 - 78 |5 HSD|avg| 78 - 79 | 11 HSD|avg| 79 - 80 |1 HSD|avg| 80 - 81 |2 HSD|avg| 81 - 82 |1 HSD|avg| 82 - 83 |4 HSD|avg| 83 - 84 |4 HSD|avg| 84 - 85 |6 HSD|avg| 85 - 86 |5 HSD|avg| 86 - 87 |1 HSD|avg| 87 - 88 |3 HSD|avg| 88 - 89 |2 HSD|avg| 89 - 90 |2 HSD|avg| 90 - 91 |1 HSD|avg| 92 - 93 |2 HSD|avg| 93 - 94 |1 HSD|avg| 94 - 95 |1 HSD|avg| 95 - 96 |1 HSD|avg| 96 - 97 |1 HSD|avg| 99 -100 |1 HSD|avg| 110 -111 |1 ---|--param|range-|--samples HSD|max| 25 - 26 |2 HSD|max| 26 - 27 |1 HSD|max| 27 - 28 |1 HSD|max| 29 - 30 |4 HSD|max| 30 - 31 |4 HSD|max| 31 - 32 |7 HSD|max| 32 - 33 | 18 HSD|max| 33 - 34 | 18 HSD|max| 34 - 35 | 36 HSD|max| 35 - 36 | 59 HSD|max| 36 - 37 | 72 HSD|max| 37 - 38 | 42 HSD|max| 38 - 39 | 40 HSD|max| 39 - 40 | 20 HSD|max| 40 - 41 | 26 HSD|max| 41 - 42 | 27 HSD|max| 42 - 43 | 25 HSD|max| 43 - 44 | 18 HSD|max| 44 - 45 | 16 HSD|max| 45 - 46 |8 HSD|max| 46 - 47 |3 HSD|max| 47 - 48 |3 HSD|max| 48 - 49 |8 HSD|max| 49 - 50 |2 HSD|max| 50 - 51 |5 HSD|max| 51 - 52 |4 HSD|max| 52 - 53 |3 HSD|max| 53 - 54 |2 HSD|max| 54 - 55 |2 HSD|max| 55 - 56 |2 HSD|max| 56 - 57 |3 HSD|max| 57 - 58 |4 HSD|max| 58 - 59 |7 HSD|max| 59 - 60 |4 HSD|max| 60 - 61 |1 HSD|max| 61 - 62 |4 HSD|
Re: [Xenomai-core] RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
Gregory CLEMENT wrote: Here, they are the last latency we get on AT91SAM9261-EK. As just now I haven't the board at home, I send the last result we stored. The prority of dbgu should be set to 6 instead of 7, but I can't assure it, for Xenomai. Hmm, hardware interrupt priorities must not impact the worst-case latency if I-pipe acks and mask them appropriately (the worst case is when multiple interrupts happen in a row, not at the same time). But this statement is not based on knowledge about potential pitfalls of this arch. Are there specialities that require this tweaking? first Xenomai: #insmod /lib/modules/2.6.20.13/kernel/drivers/xenomai/testing/xeno_timerbench.ko #cd /usr/xenomai/bin/ Which versions were you using for both tests? Do you still have the involved .configs? #./latency -t 2 -p 150 -h -H 500 ... ---|||||- RTS| 3.480| 11.779| 99.163| 0|14:23:01/14:23:01 It was run under calibrator load during more than 14 hours. Now RTAI: Oneshot timer with 500µs period, LATENCY =6000ns and SETUPTIME 1500 duration : 17h 1970/01/1 22:34:51 RTH|lat min|ovl min|lat avg|lat max|ovl max| overruns RTD| 3221| 2577| 4997| 26095| 53801| 0 RTD| 3221| 2577| 5163| 25451| 53801| 0 RTD| 3221| 2577| 5159| 25128| 53801| 0 RTD| 3221| 2577| 4799| 23518| 53801| 0 RTD| 3221| 2577| 4828| 25128| 53801| 0 RTD| 3221| 2577| 5089| 23518| 53801| 0 RTD| 3221| 2577| 4580| 23840| 53801| 0 RTD| 3221| 2577| 4924| 25128| 53801| 0 RTD| 3221| 2577| 4740| 24806| 53801| 0 RTD| 3221| 2577| 4251| 25128| 53801| 0 Again, what would simplify the discussion enormously is a function back-trace of the measured maximum latencies, just like latency -f generates. The numbers will become worse, for sure, but we would gain a very good overview about what is executed and what delayed which kernel. If you see a chance to perform such a test and you need some hints on the tracer setup (or did you use it before?), please let us know! 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
[Xenomai-core] Fwd: RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
-- Forwarded message -- From: Gregory CLEMENT [EMAIL PROTECTED] Date: 9 oct. 2007 21:07 Subject: Re: [Xenomai-core] RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK To: Jan Kiszka [EMAIL PROTECTED] 2007/10/9, Jan Kiszka [EMAIL PROTECTED]: Gregory CLEMENT wrote: Here, they are the last latency we get on AT91SAM9261-EK. As just now I haven't the board at home, I send the last result we stored. The prority of dbgu should be set to 6 instead of 7, but I can't assure it, for Xenomai. Hmm, hardware interrupt priorities must not impact the worst-case latency if I-pipe acks and mask them appropriately (the worst case is when multiple interrupts happen in a row, not at the same time). But this statement is not based on knowledge about potential pitfalls of this arch. Are there specialities that require this tweaking? Indeed there was little impact on Xenomai, but a big impact in RTAI. I believe that in RTAI (or at least in our RTAI port), there is longer critical section than in Xenomai. We observe big latency when calibrator was writing a lot of \r on serial line, that was causing a lot of interrupts. I think that during a critical section (IT disabled), we get an timer interrupt and a serial interrupt. As serial interrupt has bigger priority it is treated first and as during an interrupt serial driver can send or receive 256 character, it can add a big delay. first Xenomai: #insmod /lib/modules/2.6.20.13/kernel/drivers/xenomai/testing/xeno_timerbench.ko #cd /usr/xenomai/bin/ Which versions were you using for both tests? Do you still have the involved .configs? Both version are 2.6.20.13 I join the config files. #./latency -t 2 -p 150 -h -H 500 ... ---|||||- RTS| 3.480| 11.779| 99.163| 0|14:23:01/14:23:01 It was run under calibrator load during more than 14 hours. Now RTAI: Oneshot timer with 500µs period, LATENCY =6000ns and SETUPTIME 1500 duration : 17h 1970/01/1 22:34:51 RTH|lat min|ovl min|lat avg|lat max|ovl max| overruns RTD| 3221| 2577| 4997| 26095| 53801| 0 RTD| 3221| 2577| 5163| 25451| 53801| 0 RTD| 3221| 2577| 5159| 25128| 53801| 0 RTD| 3221| 2577| 4799| 23518| 53801| 0 RTD| 3221| 2577| 4828| 25128| 53801| 0 RTD| 3221| 2577| 5089| 23518| 53801| 0 RTD| 3221| 2577| 4580| 23840| 53801| 0 RTD| 3221| 2577| 4924| 25128| 53801| 0 RTD| 3221| 2577| 4740| 24806| 53801| 0 RTD| 3221| 2577| 4251| 25128| 53801| 0 Again, what would simplify the discussion enormously is a function back-trace of the measured maximum latencies, just like latency -f generates. The numbers will become worse, for sure, but we would gain a very good overview about what is executed and what delayed which kernel. If you see a chance to perform such a test and you need some hints on the tracer setup (or did you use it before?), please let us know! OK for try it, at least for Xenomai as the function exists, but I can't do it tonight and not this week in fact. 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 -- 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 config-RTAI Description: Binary data config-Xenomai Description: Binary data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Fwd: RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
Gregory CLEMENT wrote: -- Forwarded message -- From: Gregory CLEMENT [EMAIL PROTECTED] Date: 9 oct. 2007 21:07 Subject: Re: [Xenomai-core] RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK To: Jan Kiszka [EMAIL PROTECTED] 2007/10/9, Jan Kiszka [EMAIL PROTECTED]: Gregory CLEMENT wrote: Here, they are the last latency we get on AT91SAM9261-EK. As just now I haven't the board at home, I send the last result we stored. The prority of dbgu should be set to 6 instead of 7, but I can't assure it, for Xenomai. Hmm, hardware interrupt priorities must not impact the worst-case latency if I-pipe acks and mask them appropriately (the worst case is when multiple interrupts happen in a row, not at the same time). But this statement is not based on knowledge about potential pitfalls of this arch. Are there specialities that require this tweaking? Indeed there was little impact on Xenomai, but a big impact in RTAI. I believe that in RTAI (or at least in our RTAI port), there is longer critical section than in Xenomai. We observe big latency when calibrator was writing a lot of \r on serial line, that was causing a lot of interrupts. I think that during a critical section (IT disabled), we get an timer interrupt and a serial interrupt. As serial interrupt has bigger priority it is treated first and as during an interrupt serial driver can send or receive 256 character, it can add a big delay. Again, the priority should not be the issue. The issue is likely that a pending or just being handled non-RT IRQ can stall some RT IRQ at hardware level. That must not happen. I-pipe rather has to log, acknowledge, and possibly mask that line quickly so that RT IRQs can be delivered again. We just revealed a similar problem over i386 about fasteoi-type IRQs. What type of IRQs are involved here? Maybe it's the same bug. first Xenomai: #insmod /lib/modules/2.6.20.13/kernel/drivers/xenomai/testing/xeno_timerbench.ko #cd /usr/xenomai/bin/ Which versions were you using for both tests? Do you still have the involved .configs? Both version are 2.6.20.13 I join the config files. Hmm, I wonder why we have this difference in the configs: # diff -u config-RTAI config-Xenomai [...] @@ -147,7 +243,7 @@ # AT91 Board Options # # CONFIG_MTD_AT91_DATAFLASH_CARD is not set -# CONFIG_MTD_NAND_AT91_BUSWIDTH_16 is not set +CONFIG_MTD_NAND_AT91_BUSWIDTH_16=y # # AT91 Feature Selections Can accessing the flash delay interrupts significantly, and may this switch here have impact on the delay? Sorry for potential stupid questions, I'm not familiar with this arch yet. #./latency -t 2 -p 150 -h -H 500 ... ---|||||- RTS| 3.480| 11.779| 99.163| 0|14:23:01/14:23:01 It was run under calibrator load during more than 14 hours. Now RTAI: Oneshot timer with 500µs period, LATENCY =6000ns and SETUPTIME 1500 duration : 17h 1970/01/1 22:34:51 RTH|lat min|ovl min|lat avg|lat max|ovl max| overruns RTD| 3221| 2577| 4997| 26095| 53801| 0 RTD| 3221| 2577| 5163| 25451| 53801| 0 RTD| 3221| 2577| 5159| 25128| 53801| 0 RTD| 3221| 2577| 4799| 23518| 53801| 0 RTD| 3221| 2577| 4828| 25128| 53801| 0 RTD| 3221| 2577| 5089| 23518| 53801| 0 RTD| 3221| 2577| 4580| 23840| 53801| 0 RTD| 3221| 2577| 4924| 25128| 53801| 0 RTD| 3221| 2577| 4740| 24806| 53801| 0 RTD| 3221| 2577| 4251| 25128| 53801| 0 Again, what would simplify the discussion enormously is a function back-trace of the measured maximum latencies, just like latency -f generates. The numbers will become worse, for sure, but we would gain a very good overview about what is executed and what delayed which kernel. If you see a chance to perform such a test and you need some hints on the tracer setup (or did you use it before?), please let us know! OK for try it, at least for Xenomai as the function exists, but I can't do it tonight and not this week in fact. Thanks advance! BTW, you don't need to apply black magic in order to instrument RTAI: As you measure in the kernel anyway, you just need to add an ipipe_trace_freeze(measured_latency) at the point where a new maximum latency is detected in RTAI's benchmark module. In theory, the tracer should also work over RTAI out-of-the-box (but I'm not aware of anyone actually using it there). More info on the tracer can be found in the Xenomai wiki, BTW. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list
Re: [Xenomai-core] Fwd: RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
Gregory CLEMENT wrote: first Xenomai: #insmod /lib/modules/2.6.20.13/kernel/drivers/xenomai/testing/xeno_timerbench.ko #cd /usr/xenomai/bin/ Which versions were you using for both tests? Do you still have the involved .configs? Both version are 2.6.20.13 I join the config files. BTW, the attached Xenomai config is obviously not the one that was used for the test: # # Testing drivers # # CONFIG_XENO_DRIVERS_TIMERBENCH is not set Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
