* [Xenomai] Linux port to ARM Allwinner A13 @ 2013-02-26 0:11 Paul 2013-02-25 22:28 ` Gilles Chanteperdrix 0 siblings, 1 reply; 11+ messages in thread From: Paul @ 2013-02-26 0:11 UTC (permalink / raw) To: xenomai Here is a first port for OLINUXINO A13 board. http://www.crubille.lautre.net/xenomai_sun5i/ipipe-linuxsun5i-3.4.24.beta.patch and apply the standart xenomai-2.6.2.1 procedure on a sunxi linux kernel from : "git clone git://github.com/linux-sunxi/linux-sunxi.git -b sunxi-3.4" I think that the A10/A13 port in the official linux tree is still too unstable to port on it. The patch is a basic but functionnal version. I attempt to use priority interrupt, but go in trouble. If i can have comments about this point? If somebody is interested in it for A10, it is very easy to adapt, and i can do it and send the patch. Paul Crubillé --------------------------------------------------------------------------------------------------- Running it, i get latency -t 2 -p 100 == Sampling period: 100 us == Test mode: in-kernel timer handler == All results in microseconds RTT| 00:00:01 (in-kernel timer handler, 100 us period, priority 99) RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst RTD| 5.583| 6.265| 11.167| 0| 0| 5.583| 11.167 RTD| 6.125| 6.258| 10.917| 0| 0| 5.583| 11.167 RTD| 5.500| 6.270| 12.000| 0| 0| 5.500| 12.000 "lat worst" is mostly under 20 us but can go up for 30 ns. latency -p 100 == Sampling period: 100 us == Test mode: periodic user-mode task == All results in microseconds warming up... RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99) RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst RTD| 11.999| 12.708| 21.333| 0| 0| 11.999| 21.333 RTD| 12.624| 12.791| 21.541| 0| 0| 11.999| 21.541 RTD| 12.458| 12.791| 26.458| 0| 0| 11.999| 26.458 "lat worst" is mostly under 40 us but can go up for 80 ns. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Linux port to ARM Allwinner A13 2013-02-26 0:11 [Xenomai] Linux port to ARM Allwinner A13 Paul @ 2013-02-25 22:28 ` Gilles Chanteperdrix 2013-03-11 9:15 ` Paul 0 siblings, 1 reply; 11+ messages in thread From: Gilles Chanteperdrix @ 2013-02-25 22:28 UTC (permalink / raw) To: Paul; +Cc: xenomai On 02/26/2013 01:11 AM, Paul wrote: > > Here is a first port for OLINUXINO A13 board. > > http://www.crubille.lautre.net/xenomai_sun5i/ipipe-linuxsun5i-3.4.24.beta.patch > > and apply the standart xenomai-2.6.2.1 procedure on a sunxi linux kernel > from : > "git clone git://github.com/linux-sunxi/linux-sunxi.git -b sunxi-3.4" Hi, good news the I-pipe patch for ARM is ported to yet another board! If you wish the patch to be distributed with Xenomai, please generate a -pre and -post patches. If you generate pre and post patches, we can update the I-pipe patch with your pre and post patches remaining valid. If you do otherwise, your patch will bitrot fast. Since I have been talking about it so many times, I guess we should provide a script to generate the -pre and -post patches. > > I think that the A10/A13 port in the official linux tree is still too > unstable to port on it. > > > The patch is a basic but functionnal version. I attempt to use priority > interrupt, but go in trouble. > If i can have comments about this point? Probably not much more than what you can find in the porting guide. > > If somebody is interested in it for A10, it is very easy to adapt, and i > can do it and send the patch. > > Paul Crubillé > > --------------------------------------------------------------------------------------------------- > > Running it, i get > > > latency -t 2 -p 100 > == Sampling period: 100 us > == Test mode: in-kernel timer handler > == All results in microseconds > RTT| 00:00:01 (in-kernel timer handler, 100 us period, priority 99) > RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat > best|--lat worst > RTD| 5.583| 6.265| 11.167| 0| 0| 5.583| > 11.167 > RTD| 6.125| 6.258| 10.917| 0| 0| 5.583| > 11.167 > RTD| 5.500| 6.270| 12.000| 0| 0| 5.500| > 12.000 > > > "lat worst" is mostly under 20 us but can go up for 30 ns. > > latency -p 100 > == Sampling period: 100 us > == Test mode: periodic user-mode task > == All results in microseconds > warming up... > RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99) > RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat > best|--lat worst > RTD| 11.999| 12.708| 21.333| 0| 0| 11.999| > 21.333 > RTD| 12.624| 12.791| 21.541| 0| 0| 11.999| > 21.541 > RTD| 12.458| 12.791| 26.458| 0| 0| 11.999| > 26.458 > > "lat worst" is mostly under 40 us but can go up for 80 ns. Tests done without load are meaningless, try xeno-test or dohell. -- Gilles. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Linux port to ARM Allwinner A13 2013-02-25 22:28 ` Gilles Chanteperdrix @ 2013-03-11 9:15 ` Paul 2013-03-11 7:47 ` Gilles Chanteperdrix 0 siblings, 1 reply; 11+ messages in thread From: Paul @ 2013-03-11 9:15 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai Hello, Here are pre and post patch for xenomai on sun5i (allwinner A13). It should work for sun4i (allwinner A10) too, but is not tested for this proc. The tested kernels are wget https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r1.tar.gz and wget https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r2.tar.gz It implement priority interrupt masking. I check the priority masking with a preempt test which is derived from the latency test: The real time task loop for 1/4 of its period reading and rereading the clock, so i get the min, avg and worst case that the task can be preempted while it is running. If you are interested in this test, i can post it when I have modified the output messages. Paul Crubillé -------------- next part -------------- A non-text attachment was scrubbed... Name: pre.patch Type: text/x-patch Size: 9073 bytes Desc: not available URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130311/7536eef3/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: post.patch Type: text/x-patch Size: 20084 bytes Desc: not available URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130311/7536eef3/attachment-0001.bin> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Linux port to ARM Allwinner A13 2013-03-11 9:15 ` Paul @ 2013-03-11 7:47 ` Gilles Chanteperdrix 2013-03-11 8:15 ` Gilles Chanteperdrix ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Gilles Chanteperdrix @ 2013-03-11 7:47 UTC (permalink / raw) To: Paul; +Cc: xenomai On 03/11/2013 10:15 AM, Paul wrote: > Hello, > > Here are pre and post patch for xenomai on sun5i (allwinner A13). It > should work for sun4i (allwinner A10) too, but is not tested for this > proc. > > The tested kernels are > > wget > https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r1.tar.gz > > and > wget > https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r2.tar.gz Fine, > but the pre patch touches a lot of things which I believe it should not be touching, like entry.S. Is it because your patch is based on 3.2.24 and not 3.2.21? If that is the case, the post patch should undo the changes made by the pre patch. The coding style you use is not really the kernel coding style, see: Documentation/CodingStyle For sunxi_enable_irqdesc/sunxi_disable_irqdesc, you could use a switch case, or even better, define a macro SW_INT_SRCPRIO_REG(n) that gives the address of the nth register, and avoid the ifs completely. You do not need to manually call enable_irqdesc for the timer irq, it should be called automatically. Maybe your problem is that your "pic_muter_init" function is called too late, if that is the case, you should call it in the function which declares the Linux timer, this one should be called early enough. ipipe_ns_delay is ugly, you can probably get away much more simply with ipipe_tsc_get, or can not you simply wait for a PLL lock bit or somehting? If you want to maintain ipipe_ns_delay, plase call it ipipe_mach_something, and fix the coding style. Please avoid dead code, and C++ comments. And the cartouches. > > It implement priority interrupt masking. > > I check the priority masking with a preempt test which is derived > from the latency test: The real time task loop for 1/4 of its period > reading and rereading the clock, so i get the min, avg and worst case > that the task can be preempted while it is running. > > If you are interested in this test, i can post it when I have > modified the output messages. I do not really understand. Why would it be more preempted in the first 1/4 of its period? -- Gilles. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Linux port to ARM Allwinner A13 2013-03-11 7:47 ` Gilles Chanteperdrix @ 2013-03-11 8:15 ` Gilles Chanteperdrix 2013-03-11 22:29 ` Paul 2013-03-11 22:47 ` Paul 2 siblings, 0 replies; 11+ messages in thread From: Gilles Chanteperdrix @ 2013-03-11 8:15 UTC (permalink / raw) To: Paul; +Cc: xenomai On 03/11/2013 08:47 AM, Gilles Chanteperdrix wrote: > On 03/11/2013 10:15 AM, Paul wrote: > >> Hello, >> >> Here are pre and post patch for xenomai on sun5i (allwinner A13). It >> should work for sun4i (allwinner A10) too, but is not tested for this >> proc. Also, you seem to have duplicated the timer code, this should not be needed, right? -- Gilles. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Linux port to ARM Allwinner A13 2013-03-11 7:47 ` Gilles Chanteperdrix 2013-03-11 8:15 ` Gilles Chanteperdrix @ 2013-03-11 22:29 ` Paul 2013-04-09 22:05 ` Gilles Chanteperdrix 2013-03-11 22:47 ` Paul 2 siblings, 1 reply; 11+ messages in thread From: Paul @ 2013-03-11 22:29 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai Hello Gilles, On 11/03/2013 08:47, Gilles Chanteperdrix wrote: > On 03/11/2013 10:15 AM, Paul wrote: > >> Hello, >> >> Here are pre and post patch for xenomai on sun5i (allwinner A13). It >> should work for sun4i (allwinner A10) too, but is not tested for this >> proc. >> >> The tested kernels are >> >> wget >> https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r1.tar.gz >> >> > > and > >> wget >> https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r2.tar.gz > > > > Fine, > > > but the pre patch touches a lot of things which I believe it > should not be touching, like entry.S. > > Is it because your patch is based on 3.2.24 and not 3.2.21? If that is > the case, the post patch should undo the changes made by the pre patch. The patch is based on 3.4.24 and the ipipe patch is noted to be a 3.4.6, but there is no such kernel for the sunxi. So most of the patch fail are from the different linux version but curiously, vfp/entry.S are differents in the sunxi3.4.24 and in the vanill3.4.24.. > > The coding style you use is not really the kernel coding style, see: > Documentation/CodingStyle OK, I would do it. > > For sunxi_enable_irqdesc/sunxi_disable_irqdesc, you could use a switch > case, or even better, define a macro SW_INT_SRCPRIO_REG(n) that gives > the address of the nth register, and avoid the ifs completely. strange, but i copy/paste this part of code from the sunxi part (and found that bad): My first idea was to mask, shift and use the result as index in a register index. To stay close to the actual style, ok to use switch (it is not a so performance critical part). > > You do not need to manually call enable_irqdesc for the timer irq, it > should be called automatically. Maybe your problem is that your > "pic_muter_init" function is called too late, if that is the case, you > should call it in the function which declares the Linux timer, this one > should be called early enough. I add this in an attempt to solve a problem which have nothing to do with it, and it stay here. To be removed. > > ipipe_ns_delay is ugly, you can probably get away much more simply with > ipipe_tsc_get, or can not you simply wait for a PLL lock bit or > somehting? If you want to maintain ipipe_ns_delay, plase call it > ipipe_mach_something, and fix the coding style. I dont know about ipipe_tsc_get, so i will test with it. > > Please avoid dead code, and C++ comments. And the cartouches. FROM THE FOLLOWING MAIL: > Also, you seem to have duplicated the timer code, this should not be > needed, right? The initialisation is very close, but i think the linux-sunxi timer_set_mode is broken. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Linux port to ARM Allwinner A13 2013-03-11 22:29 ` Paul @ 2013-04-09 22:05 ` Gilles Chanteperdrix 0 siblings, 0 replies; 11+ messages in thread From: Gilles Chanteperdrix @ 2013-04-09 22:05 UTC (permalink / raw) To: Paul; +Cc: xenomai On 03/11/2013 11:29 PM, Paul wrote: > Hello Gilles, > > On 11/03/2013 08:47, Gilles Chanteperdrix wrote: >> On 03/11/2013 10:15 AM, Paul wrote: >> >>> Hello, >>> >>> Here are pre and post patch for xenomai on sun5i (allwinner A13). It >>> should work for sun4i (allwinner A10) too, but is not tested for this >>> proc. >>> >>> The tested kernels are >>> >>> wget >>> https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r1.tar.gz >>> >>> >> >> and >> >>> wget >>> https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r2.tar.gz >> >> >> >> Fine, >> >> >> but the pre patch touches a lot of things which I believe it >> should not be touching, like entry.S. >> >> Is it because your patch is based on 3.2.24 and not 3.2.21? If that is >> the case, the post patch should undo the changes made by the pre patch. > > The patch is based on 3.4.24 and the ipipe patch is noted to be a 3.4.6, > but there is no such kernel for the sunxi. > So most of the patch fail are from the different linux version but > curiously, vfp/entry.S are differents in the sunxi3.4.24 and in the > vanill3.4.24.. > >> >> The coding style you use is not really the kernel coding style, see: >> Documentation/CodingStyle > OK, I would do it. >> >> For sunxi_enable_irqdesc/sunxi_disable_irqdesc, you could use a switch >> case, or even better, define a macro SW_INT_SRCPRIO_REG(n) that gives >> the address of the nth register, and avoid the ifs completely. > strange, but i copy/paste this part of code from the sunxi part (and > found that bad): > My first idea was to mask, shift and use the result as index in a > register index. > To stay close to the actual style, ok to use switch (it is not a so > performance critical part). >> >> You do not need to manually call enable_irqdesc for the timer irq, it >> should be called automatically. Maybe your problem is that your >> "pic_muter_init" function is called too late, if that is the case, you >> should call it in the function which declares the Linux timer, this one >> should be called early enough. > I add this in an attempt to solve a problem which have nothing to do > with it, and it stay here. > To be removed. >> >> ipipe_ns_delay is ugly, you can probably get away much more simply with >> ipipe_tsc_get, or can not you simply wait for a PLL lock bit or >> somehting? If you want to maintain ipipe_ns_delay, plase call it >> ipipe_mach_something, and fix the coding style. > I dont know about ipipe_tsc_get, so i will test with it. >> >> Please avoid dead code, and C++ comments. And the cartouches. > > > FROM THE FOLLOWING MAIL: >> Also, you seem to have duplicated the timer code, this should not be >> needed, right? > The initialisation is very close, but i think the linux-sunxi > timer_set_mode is broken. Hi Paul, do you plan to send revised pre and post patches in say, the next few weeks? Regards. -- Gilles. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Linux port to ARM Allwinner A13 2013-03-11 7:47 ` Gilles Chanteperdrix 2013-03-11 8:15 ` Gilles Chanteperdrix 2013-03-11 22:29 ` Paul @ 2013-03-11 22:47 ` Paul 2013-03-12 4:56 ` Gilles Chanteperdrix 2 siblings, 1 reply; 11+ messages in thread From: Paul @ 2013-03-11 22:47 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai Some precision and 2 small examples about a preempt test: On 11/03/2013 08:47, Gilles Chanteperdrix wrote: > On 03/11/2013 10:15 AM, Paul wrote: > >> Hello, >> >> ... ... ... >> >> I check the priority masking with a preempt test which is derived >> from the latency test: The real time task loop for 1/4 of its period >> reading and rereading the clock, so i get the min, avg and worst case >> that the task can be preempted while it is running. > >> If you are interested in this test, i can post it when I have >> modified the output messages. > > > I do not really understand. Why would it be more preempted in the first > 1/4 of its period? > > No reason sure but - It can be preempted only while it is running, so between the time it is restarted after sleeping and before it go to sleep again. Let it running 1/4 of the period is enough to catch lots of events if there is lots of irqs but not too much so linux, dohell or even xenomai tasks can run just a bit slower. Here are some result i get (yes with the priority interrupt masking, and i am pretty sure it work - but the watchdog is on). There is a dohell at the same time in the whole experiment and i start X11, stop it , restart it ... root@debian:/usr/xenomai/bin# /usr/src/build_xenomai/src/testsuite/preempt/preempt -p 111 == Sampling period: 111 us == Test mode: periodic user-mode task == All results in microseconds warming up... RTT| 00:00:01 (periodic user-mode task, 111 us period, priority 99) RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre best|--pre worst RTD| 0.333| 0.374| 3.333| 0| 0| 0.333| 3.333 RTD| 0.333| 0.374| 15.666| 0| 0| 0.333| 15.666 ---|-----------|-----------|-----------|--------|------|------------------------- RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre best|--pre worst RTD| 0.333| 0.374| 3.708| 0| 0| 0.333| 23.333 RTD| 0.333| 0.374| 3.874| 0| 0| 0.333| 23.333 RTD| 0.333| 0.374| 3.541| 0| 0| 0.333| 23.333 RTD| 0.333| 0.374| 3.916| 0| 0| 0.333| 23.333 RTD| 0.333| 0.374| 3.541| 0| 0| 0.333| 23.333 RTD| 0.333| 0.374| 3.583| 0| 0| 0.333| 23.333 RTD| 0.333| 0.374| 3.499| 0| 0| 0.333| 23.333 RTD| 0.333| 0.374| 3.833| 0| 0| 0.333| 23.333 RTD| 0.333| 0.374| 3.791| 0| 0| 0.333| 23.333 RTD| 0.333| 0.374| 3.666| 0| 0| 0.333| 23.333 RTD| 0.333| 0.374| 3.833| 0| 0| 0.333| 23.333 RTD| 0.333| 0.374| 3.749| 0| 0| 0.333| 23.333 RTD| 0.333| 0.374| 3.749| 0| 0| 0.333| 23.333 RTD| 0.333| 0.374| 3.624| 0| 0| 0.333| 23.333 ^C---|-----------|-----------|-----------|--------|------|------------------------- RTS| 0.333| 0.374| 23.333| 0| 0| 00:13:33/00:13:33 A second experiment, just setting the period to 100 (and the period for the watchdog is a multiple so 3/4 it never preempt the task: /usr/src/build_xenomai/src/testsuite/preempt/preempt -p 100 -h == Sampling period: 100 us == Test mode: periodic user-mode task == All results in microseconds warming up... RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99) RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst RTD| 0.333| 0.374| 0.749| 0| 0| 0.333| 0.749 RTD| 0.333| 0.374| 2.749| 0| 0| 0.333| 2.749 RTD| 0.333| 0.374| 0.708| 0| 0| 0.333| 2.749 RTD| 0.333| 0.374| 0.833| 0| 0| 0.333| 2.749 RTD| 0.333| 0.374| 0.708| 0| 0| 0.333| 2.749 RTD| 0.333| 0.374| 0.833| 0| 0| 0.333| 2.749 ... ... ... RTD| 0.333| 0.374| 3.749| 0| 0| 0.333| 4.541 RTD| 0.333| 0.374| 4.166| 0| 0| 0.333| 4.541 RTD| 0.333| 0.374| 3.541| 0| 0| 0.333| 4.541 RTD| 0.333| 0.374| 3.791| 0| 0| 0.333| 4.541 RTD| 0.333| 0.374| 3.666| 0| 0| 0.333| 4.541 RTD| 0.333| 0.374| 4.416| 0| 0| 0.333| 4.541 RTD| 0.333| 0.374| 3.791| 0| 0| 0.333| 4.541 RTD| 0.333| 0.374| 3.874| 0| 0| 0.333| 4.541 RTD| 0.333| 0.374| 3.749| 0| 0| 0.333| 4.541 RTT| 00:04:13 (periodic user-mode task, 100 us period, priority 99) RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst RTD| 0.333| 0.374| 4.124| 0| 0| 0.333| 4.541 ^C---|--param|----range-|--samples HSD| min| 0 - 1 | 253 ---|--param|----range-|--samples HSD| avg| 0 - 1 | 2530149 ---|--param|----range-|--samples HSD| max| 0 - 1 | 3 HSD| max| 1 - 2 | 1 HSD| max| 2 - 3 | 3 HSD| max| 3 - 4 | 186 HSD| max| 4 - 5 | 60 HSH|--param|--samples-|--average--|---stddev-- HSS| min| 253| 0.000| 0.000 HSS| avg| 2530149| 0.000| 0.000 HSS| max| 253| 3.182| 0.583 ---|-----------|-----------|-----------|--------|------|------------------------- RTS| 0.333| 0.374| 4.541| 0| 0| 00:04:13/00:04:13 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Linux port to ARM Allwinner A13 2013-03-11 22:47 ` Paul @ 2013-03-12 4:56 ` Gilles Chanteperdrix 2013-03-12 5:06 ` Gilles Chanteperdrix 0 siblings, 1 reply; 11+ messages in thread From: Gilles Chanteperdrix @ 2013-03-12 4:56 UTC (permalink / raw) To: Paul; +Cc: xenomai On 03/11/2013 11:47 PM, Paul wrote: > Some precision and 2 small examples about a preempt test: > > On 11/03/2013 08:47, Gilles Chanteperdrix wrote: >> On 03/11/2013 10:15 AM, Paul wrote: >> >>> Hello, >>> >>> ... ... ... >>> >>> I check the priority masking with a preempt test which is derived >>> from the latency test: The real time task loop for 1/4 of its period >>> reading and rereading the clock, so i get the min, avg and worst case >>> that the task can be preempted while it is running. >> >>> If you are interested in this test, i can post it when I have >>> modified the output messages. >> >> >> I do not really understand. Why would it be more preempted in the first >> 1/4 of its period? >> >> > No reason sure but - > It can be preempted only while it is running, so between the time it > is restarted after sleeping and before it go to sleep again. > Let it running 1/4 of the period is enough to catch lots of events if > there is lots of irqs but not too much so linux, dohell or even xenomai > tasks can run just a bit slower. > > > Here are some result i get (yes with the priority interrupt masking, and > i am pretty sure it work - but the watchdog is on). > There is a dohell at the same time in the whole experiment and i start > X11, stop it , restart it ... > > > root@debian:/usr/xenomai/bin# > /usr/src/build_xenomai/src/testsuite/preempt/preempt -p 111 > == Sampling period: 111 us > == Test mode: periodic user-mode task > == All results in microseconds > warming up... > RTT| 00:00:01 (periodic user-mode task, 111 us period, priority 99) > RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre > best|--pre worst > RTD| 0.333| 0.374| 3.333| 0| 0| > 0.333| 3.333 > RTD| 0.333| 0.374| 15.666| 0| 0| 0.333| > 15.666 > ---|-----------|-----------|-----------|--------|------|------------------------- > > RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre > best|--pre worst > RTD| 0.333| 0.374| 3.708| 0| 0| 0.333| > 23.333 > RTD| 0.333| 0.374| 3.874| 0| 0| 0.333| > 23.333 > RTD| 0.333| 0.374| 3.541| 0| 0| 0.333| > 23.333 > RTD| 0.333| 0.374| 3.916| 0| 0| 0.333| > 23.333 > RTD| 0.333| 0.374| 3.541| 0| 0| 0.333| > 23.333 > RTD| 0.333| 0.374| 3.583| 0| 0| 0.333| > 23.333 > RTD| 0.333| 0.374| 3.499| 0| 0| 0.333| > 23.333 > RTD| 0.333| 0.374| 3.833| 0| 0| 0.333| > 23.333 > RTD| 0.333| 0.374| 3.791| 0| 0| 0.333| > 23.333 > RTD| 0.333| 0.374| 3.666| 0| 0| 0.333| > 23.333 > RTD| 0.333| 0.374| 3.833| 0| 0| 0.333| > 23.333 > RTD| 0.333| 0.374| 3.749| 0| 0| 0.333| > 23.333 > RTD| 0.333| 0.374| 3.749| 0| 0| 0.333| > 23.333 > RTD| 0.333| 0.374| 3.624| 0| 0| 0.333| > 23.333 > ^C---|-----------|-----------|-----------|--------|------|------------------------- > RTS| 0.333| 0.374| 23.333| 0| 0| > 00:13:33/00:13:33 > > > A second experiment, just setting the period to 100 (and the period for > the watchdog is a multiple so 3/4 it never preempt the task: Looks only like pure luck to me. As you may or may not know, Xenomai uses the timer in one-shot mode, so, the watchdog tick has no reason to be aligned with your application timer. I would say the chances for your task to be preempted by the watchdog tick while it is measuring is 1/4... -- Gilles. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Linux port to ARM Allwinner A13 2013-03-12 4:56 ` Gilles Chanteperdrix @ 2013-03-12 5:06 ` Gilles Chanteperdrix 0 siblings, 0 replies; 11+ messages in thread From: Gilles Chanteperdrix @ 2013-03-12 5:06 UTC (permalink / raw) To: Paul; +Cc: xenomai On 03/12/2013 05:56 AM, Gilles Chanteperdrix wrote: > On 03/11/2013 11:47 PM, Paul wrote: > >> Some precision and 2 small examples about a preempt test: >> >> On 11/03/2013 08:47, Gilles Chanteperdrix wrote: >>> On 03/11/2013 10:15 AM, Paul wrote: >>> >>>> Hello, >>>> >>>> ... ... ... >>>> >>>> I check the priority masking with a preempt test which is derived >>>> from the latency test: The real time task loop for 1/4 of its period >>>> reading and rereading the clock, so i get the min, avg and worst case >>>> that the task can be preempted while it is running. >>> >>>> If you are interested in this test, i can post it when I have >>>> modified the output messages. >>> >>> >>> I do not really understand. Why would it be more preempted in the first >>> 1/4 of its period? >>> >>> >> No reason sure but - >> It can be preempted only while it is running, so between the time it >> is restarted after sleeping and before it go to sleep again. >> Let it running 1/4 of the period is enough to catch lots of events if >> there is lots of irqs but not too much so linux, dohell or even xenomai >> tasks can run just a bit slower. >> >> >> Here are some result i get (yes with the priority interrupt masking, and >> i am pretty sure it work - but the watchdog is on). >> There is a dohell at the same time in the whole experiment and i start >> X11, stop it , restart it ... >> >> >> root@debian:/usr/xenomai/bin# >> /usr/src/build_xenomai/src/testsuite/preempt/preempt -p 111 >> == Sampling period: 111 us >> == Test mode: periodic user-mode task >> == All results in microseconds >> warming up... >> RTT| 00:00:01 (periodic user-mode task, 111 us period, priority 99) >> RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre >> best|--pre worst >> RTD| 0.333| 0.374| 3.333| 0| 0| >> 0.333| 3.333 >> RTD| 0.333| 0.374| 15.666| 0| 0| 0.333| >> 15.666 >> ---|-----------|-----------|-----------|--------|------|------------------------- >> >> RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre >> best|--pre worst >> RTD| 0.333| 0.374| 3.708| 0| 0| 0.333| >> 23.333 >> RTD| 0.333| 0.374| 3.874| 0| 0| 0.333| >> 23.333 >> RTD| 0.333| 0.374| 3.541| 0| 0| 0.333| >> 23.333 >> RTD| 0.333| 0.374| 3.916| 0| 0| 0.333| >> 23.333 >> RTD| 0.333| 0.374| 3.541| 0| 0| 0.333| >> 23.333 >> RTD| 0.333| 0.374| 3.583| 0| 0| 0.333| >> 23.333 >> RTD| 0.333| 0.374| 3.499| 0| 0| 0.333| >> 23.333 >> RTD| 0.333| 0.374| 3.833| 0| 0| 0.333| >> 23.333 >> RTD| 0.333| 0.374| 3.791| 0| 0| 0.333| >> 23.333 >> RTD| 0.333| 0.374| 3.666| 0| 0| 0.333| >> 23.333 >> RTD| 0.333| 0.374| 3.833| 0| 0| 0.333| >> 23.333 >> RTD| 0.333| 0.374| 3.749| 0| 0| 0.333| >> 23.333 >> RTD| 0.333| 0.374| 3.749| 0| 0| 0.333| >> 23.333 >> RTD| 0.333| 0.374| 3.624| 0| 0| 0.333| >> 23.333 >> ^C---|-----------|-----------|-----------|--------|------|------------------------- >> RTS| 0.333| 0.374| 23.333| 0| 0| >> 00:13:33/00:13:33 >> >> >> A second experiment, just setting the period to 100 (and the period for >> the watchdog is a multiple so 3/4 it never preempt the task: > > > Looks only like pure luck to me. As you may or may not know, Xenomai > uses the timer in one-shot mode, so, the watchdog tick has no reason to > be aligned with your application timer. I would say the chances for your > task to be preempted by the watchdog tick while it is measuring is 1/4... > > Of course the difference if your application timer is a sub-multiple of the watchdog timer is that the watchdog will always preempt your application at the same moment, so, if it did not preempt it during the first quarter of one period during the first second, it will never do. -- Gilles. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Linux port to ARM Allwinner A13 @ 2013-05-06 12:56 kunming yang 0 siblings, 0 replies; 11+ messages in thread From: kunming yang @ 2013-05-06 12:56 UTC (permalink / raw) To: xenomai Hi, I am now working on Cubieboard, which has the Soc A10. Can you send me the patch for it? Thanks a lot! Regards. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-05-06 12:56 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-02-26 0:11 [Xenomai] Linux port to ARM Allwinner A13 Paul 2013-02-25 22:28 ` Gilles Chanteperdrix 2013-03-11 9:15 ` Paul 2013-03-11 7:47 ` Gilles Chanteperdrix 2013-03-11 8:15 ` Gilles Chanteperdrix 2013-03-11 22:29 ` Paul 2013-04-09 22:05 ` Gilles Chanteperdrix 2013-03-11 22:47 ` Paul 2013-03-12 4:56 ` Gilles Chanteperdrix 2013-03-12 5:06 ` Gilles Chanteperdrix -- strict thread matches above, loose matches on Subject: below -- 2013-05-06 12:56 kunming yang
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.