Re: Re: [beagleboard] Re: BBB + PREEMPT_RT
quikcjack！ Oh, thanks! I will try to get it later. I had allways use email to read this board, since I am form mainland China and can't access this board form web page. :-( Any way, thansk for your work and help. 2014-04-04 23:08:32 您在来信中写道： Sorry for my late answer. I have posted my kernel configuration on March 5. Please take a close look at my postings. You mave have to log in to google to see the attachments. Am Mittwoch, 19. März 2014 16:06:07 UTC+1 schrieb winglion: hi,quikcjack. I had been fallowing the topic for some dates. I plan to build a CNC controler with BBBlack. I want to get your kernel config to make a PREEMPT/PREEMPT_RT capable kernel too. whould you please seem me your kernel confiuration too? Thanks. 2014-03-19 16:47:58 ： It's really nice to see that there is some interest in having a PREEMPT/PREEMPT_RT capable kernel for the BBB. Well, it's relatively easy to compile a kernel. If you want to develop applications for the BBB you need a compiler/toolchain. So I guess you might have that already. The instructions to compile a kernel are explained at https://github.com/beagleboard/kernel/tree/3.8. I could send you my modified kernel configuration. You simply have the replace the original kernel configuration to create the PREEMPT capable kernel. Am Freitag, 14. März 2014 13:03:51 UTC+1 schrieb mhfar...@gmail.com: Hi thats great! Is that possible to have your compiled kernel for BBB? I would avoid the compiling process. Thanks a lot, Morteza Am Mittwoch, 26. Februar 2014 14:53:05 UTC+1 schrieb quik...@gmail.com: I have recently tested kernel 3.8.13-rt9 (https://github.com/beagleboard/kernel/tree/3.8-rt) using git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am using Ubuntu 12.04.4. The load was created using stress –cpu 1 which generates a cpu load of about 100%. I then used cyclictest: root@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l100 -m -n -t1 -p99 -i400 -q # /dev/cpu_dma_latency set to 0us T: 0 ( 770) P:99 I:400 C:100 Min: 14 Act: 19 Avg: 18 Max: 132 uname -a reports: root@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux I am absolutely surprised that the result is looking that good. Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...@gmail.com: I am trying to figure out how to create a kernel for the BBB that supports PREEMPT_RT. It's kind of strange that the BBB's default kernel does not even have PREEMPT activated. Such a board doesn't fit to many embedded applications where we need at least some kind of determinism. It is even worse, that nobody seems to care about this problem. Contrary to that, the Raspberry PI's standard kernel has PREEMPT activacted from the very beginning. I have tested Robert Nelsons kernel 3.8.13-r9 (https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have PREEMPT_RT activated by default. When doing so, it does not boot. But activating PREEMPT does work. However, development of this branch has stopped several months ago. The official source for RT Linux (3.8.13) has evolved since then. Meanwhile there's an rt17 patch set (https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody give this a try? Does it work with the BBB? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. 在此邮件中未发现病毒。 检查工具：AVG - www.avg.com 版本：2013.0.3462 / 病毒数据库：3722/7208 - 发布日期：03/17/14 = = = = = = = = = = = = = = = = = = = = = = 致 礼！ winglion wing...@163.com 2014-03-19 -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. = = = = = = = = = = = = = = = = = = = = = = 致 礼！ Yang wingli...@163.com 2014-07-01 -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: BBB + PREEMPT_RT
Sorry for my late answer. I have posted my kernel configuration on March 5. Please take a close look at my postings. You mave have to log in to google to see the attachments. Am Mittwoch, 19. März 2014 16:06:07 UTC+1 schrieb winglion: hi,quikcjack. I had been fallowing the topic for some dates. I plan to build a CNC controler with BBBlack. I want to get your kernel config to make a PREEMPT/PREEMPT_RT capable kernel too. whould you please seem me your kernel confiuration too? Thanks. 2014-03-19 16:47:58 ： It's really nice to see that there is some interest in having a PREEMPT/PREEMPT_RT capable kernel for the BBB. Well, it's relatively easy to compile a kernel. If you want to develop applications for the BBB you need a compiler/toolchain. So I guess you might have that already. The instructions to compile a kernel are explained at https://github.com/beagleboard/kernel/tree/3.8. I could send you my modified kernel configuration. You simply have the replace the original kernel configuration to create the PREEMPT capable kernel. Am Freitag, 14. März 2014 13:03:51 UTC+1 schrieb mhfar...@gmail.com: Hi thats great! Is that possible to have your compiled kernel for BBB? I would avoid the compiling process. Thanks a lot, Morteza Am Mittwoch, 26. Februar 2014 14:53:05 UTC+1 schrieb quik...@gmail.com: I have recently tested kernel 3.8.13-rt9 ( https://github.com/beagleboard/kernel/tree/3.8-rt) using git:// git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am using Ubuntu 12.04.4. The load was created using stress –cpu 1 which generates a cpu load of about 100%. I then used cyclictest: root@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l100 -m -n -t1 -p99 -i400 -q # /dev/cpu_dma_latency set to 0us T: 0 ( 770) P:99 I:400 C:100 Min: 14 Act: 19 Avg: 18 Max: 132 uname -a reports: root@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux I am absolutely surprised that the result is looking that good. Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...@gmail.com: I am trying to figure out how to create a kernel for the BBB that supports PREEMPT_RT. It's kind of strange that the BBB's default kernel does not even have PREEMPT activated. Such a board doesn't fit to many embedded applications where we need at least some kind of determinism. It is even worse, that nobody seems to care about this problem. Contrary to that, the Raspberry PI's standard kernel has PREEMPT activacted from the very beginning. I have tested Robert Nelsons kernel 3.8.13-r9 ( https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have PREEMPT_RT activated by default. When doing so, it does not boot. But activating PREEMPT does work. However, development of this branch has stopped several months ago. The official source for RT Linux (3.8.13) has evolved since then. Meanwhile there's an rt17 patch set ( https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody give this a try? Does it work with the BBB? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. 在此邮件中未发现病毒。 检查工具：AVG - www.avg.com 版本：2013.0.3462 / 病毒数据库：3722/7208 - 发布日期：03/17/14 = = = = = = = = = = = = = = = = = = = = = = 致 礼！ winglion wing...@163.com javascript: 2014-03-19 -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: BBB + PREEMPT_RT
It's really nice to see that there is some interest in having a PREEMPT/PREEMPT_RT capable kernel for the BBB. Well, it's relatively easy to compile a kernel. If you want to develop applications for the BBB you need a compiler/toolchain. So I guess you might have that already. The instructions to compile a kernel are explained at https://github.com/beagleboard/kernel/tree/3.8. I could send you my modified kernel configuration. You simply have the replace the original kernel configuration to create the PREEMPT capable kernel. Am Freitag, 14. März 2014 13:03:51 UTC+1 schrieb mhfar...@gmail.com: Hi thats great! Is that possible to have your compiled kernel for BBB? I would avoid the compiling process. Thanks a lot, Morteza Am Mittwoch, 26. Februar 2014 14:53:05 UTC+1 schrieb quik...@gmail.com: I have recently tested kernel 3.8.13-rt9 ( https://github.com/beagleboard/kernel/tree/3.8-rt) using git:// git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am using Ubuntu 12.04.4. The load was created using stress –cpu 1 which generates a cpu load of about 100%. I then used cyclictest: root@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l100 -m -n -t1 -p99 -i400 -q # /dev/cpu_dma_latency set to 0us T: 0 ( 770) P:99 I:400 C:100 Min: 14 Act: 19 Avg: 18 Max: 132 uname -a reports: root@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux I am absolutely surprised that the result is looking that good. Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...@gmail.com: I am trying to figure out how to create a kernel for the BBB that supports PREEMPT_RT. It's kind of strange that the BBB's default kernel does not even have PREEMPT activated. Such a board doesn't fit to many embedded applications where we need at least some kind of determinism. It is even worse, that nobody seems to care about this problem. Contrary to that, the Raspberry PI's standard kernel has PREEMPT activacted from the very beginning. I have tested Robert Nelsons kernel 3.8.13-r9 ( https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have PREEMPT_RT activated by default. When doing so, it does not boot. But activating PREEMPT does work. However, development of this branch has stopped several months ago. The official source for RT Linux (3.8.13) has evolved since then. Meanwhile there's an rt17 patch set ( https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody give this a try? Does it work with the BBB? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: BBB + PREEMPT_RT
hi,quikcjack. I had been fallowing the topic for some dates. I plan to build a CNC controler with BBBlack. I want to get your kernel config to make a PREEMPT/PREEMPT_RT capable kernel too. whould you please seem me your kernel confiuration too? Thanks. 2014-03-19 16:47:58 ： It's really nice to see that there is some interest in having a PREEMPT/PREEMPT_RT capable kernel for the BBB. Well, it's relatively easy to compile a kernel. If you want to develop applications for the BBB you need a compiler/toolchain. So I guess you might have that already. The instructions to compile a kernel are explained at https://github.com/beagleboard/kernel/tree/3.8. I could send you my modified kernel configuration. You simply have the replace the original kernel configuration to create the PREEMPT capable kernel. Am Freitag, 14. März 2014 13:03:51 UTC+1 schrieb mhfar...@gmail.com: Hi thats great! Is that possible to have your compiled kernel for BBB? I would avoid the compiling process. Thanks a lot, Morteza Am Mittwoch, 26. Februar 2014 14:53:05 UTC+1 schrieb quik...@gmail.com: I have recently tested kernel 3.8.13-rt9 (https://github.com/beagleboard/kernel/tree/3.8-rt) using git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am using Ubuntu 12.04.4. The load was created using stress –cpu 1 which generates a cpu load of about 100%. I then used cyclictest: root@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l100 -m -n -t1 -p99 -i400 -q # /dev/cpu_dma_latency set to 0us T: 0 ( 770) P:99 I:400 C:100 Min: 14 Act: 19 Avg: 18 Max: 132 uname -a reports: root@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux I am absolutely surprised that the result is looking that good. Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...@gmail.com: I am trying to figure out how to create a kernel for the BBB that supports PREEMPT_RT. It's kind of strange that the BBB's default kernel does not even have PREEMPT activated. Such a board doesn't fit to many embedded applications where we need at least some kind of determinism. It is even worse, that nobody seems to care about this problem. Contrary to that, the Raspberry PI's standard kernel has PREEMPT activacted from the very beginning. I have tested Robert Nelsons kernel 3.8.13-r9 (https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have PREEMPT_RT activated by default. When doing so, it does not boot. But activating PREEMPT does work. However, development of this branch has stopped several months ago. The official source for RT Linux (3.8.13) has evolved since then. Meanwhile there's an rt17 patch set (https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody give this a try? Does it work with the BBB? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. 在此邮件中未发现病毒。 检查工具：AVG - www.avg.com 版本：2013.0.3462 / 病毒数据库：3722/7208 - 发布日期：03/17/14 = = = = = = = = = = = = = = = = = = = = = = 致 礼！ winglion wingli...@163.com 2014-03-19 -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: BBB + PREEMPT_RT
Hi thats great! Is that possible to have your compiled kernel for BBB? I would avoid the compiling process. Thanks a lot, Morteza Am Mittwoch, 26. Februar 2014 14:53:05 UTC+1 schrieb quik...@gmail.com: I have recently tested kernel 3.8.13-rt9 ( https://github.com/beagleboard/kernel/tree/3.8-rt) using git:// git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am using Ubuntu 12.04.4. The load was created using stress –cpu 1 which generates a cpu load of about 100%. I then used cyclictest: root@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l100 -m -n -t1 -p99 -i400 -q # /dev/cpu_dma_latency set to 0us T: 0 ( 770) P:99 I:400 C:100 Min: 14 Act: 19 Avg: 18 Max: 132 uname -a reports: root@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux I am absolutely surprised that the result is looking that good. Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...@gmail.com: I am trying to figure out how to create a kernel for the BBB that supports PREEMPT_RT. It's kind of strange that the BBB's default kernel does not even have PREEMPT activated. Such a board doesn't fit to many embedded applications where we need at least some kind of determinism. It is even worse, that nobody seems to care about this problem. Contrary to that, the Raspberry PI's standard kernel has PREEMPT activacted from the very beginning. I have tested Robert Nelsons kernel 3.8.13-r9 ( https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have PREEMPT_RT activated by default. When doing so, it does not boot. But activating PREEMPT does work. However, development of this branch has stopped several months ago. The official source for RT Linux (3.8.13) has evolved since then. Meanwhile there's an rt17 patch set ( https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody give this a try? Does it work with the BBB? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: BBB + PREEMPT_RT
I have never heard of a PREEMPT_RT capable kernel for the BBB besides that from OSADL. I have recently had a conversation with Robert C. Nelson. He told me, that kernel 3.8 has problems and did never support PREEMPT_RT. The 3.8-rt branch is no longer in development. Officially, the BBB does not even support simple PREEMPT. So I guess your only chance is the OSADL kernel. The current version is 3.12.13-rt21. It seems to work. But there are issues with GPMC. I have created a new thread on this topic here: https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/uac_Zh41LYo. Am Samstag, 8. März 2014 22:15:04 UTC+1 schrieb fj.r...@openmailbox.org: I have lately also unsuccessfully tried to install RT_PREEMPT on BBB. What I have done until now (and failed) is: A. 1. Get the sources from here: https://github.com/beagleboard/kernel/tree/3.8-rt 2. Before make command, enable Full Preemption under kernel features options. 3. Compile. When testing on BBB, the kernel doesn't boot. B. 1. Get the sources from here: https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8 2. ./build_kernel.sh 3. Download the rt patch from here: https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.8.13.14-rt27.patch.bz2into KERNEL folder 4. patch p1 patch-3.8.13.14-rt27.patch 5. From here, it turned a little bit weird since approximately 21 HUNKS failed. Reading this post: https://groups.google.com/forum/#!topic/beagleboard/aAufDe13SeQ then I re-edited the .patch file taking away the modifications in cpsw.h and cpsw.c (lines 5825 to 7346 from .patch file). 6. Then repeated steps 1 through 4 again, but using the edited patch. 7. Use menuconfig to activate Full-Preemption. 8. ./tools/rebuild.sh 9. ./tools/install_kernel.sh (with the modifications in the system.sh file) 10. Plug the SD card in the BBB. and it never booted. I have seen the osadl 3.8.12 kernel, but I'm more interested in using the 3.8.13 kernel. If anyone could give away any ideas, I would be really grateful. Thank you for your time. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: BBB + PREEMPT_RT
I tried PREEMPT yesterday on 3.12.9 and the ethernet seemed to work. The only thing I had a problem with was USB host. It failed the probe(). So I reverted. Years ago I filed a bug report with TI regarding the ethernet driver not working with PREEMPT in kernel 3.2. Some progress has been made, ethernet seemed to work now on 3.12.9. Dick -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: BBB + PREEMPT_RT
I have lately also unsuccessfully tried to install RT_PREEMPT on BBB. What I have done until now (and failed) is: A. 1. Get the sources from here: https://github.com/beagleboard/kernel/tree/3.8-rt 2. Before make command, enable Full Preemption under kernel features options. 3. Compile. When testing on BBB, the kernel doesn't boot. B. 1. Get the sources from here: https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8 2. ./build_kernel.sh 3. Download the rt patch from here: https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.8.13.14-rt27.patch.bz2into KERNEL folder 4. patch p1 patch-3.8.13.14-rt27.patch 5. From here, it turned a little bit weird since approximately 21 HUNKS failed. Reading this post: https://groups.google.com/forum/#!topic/beagleboard/aAufDe13SeQ then I re-edited the .patch file taking away the modifications in cpsw.h and cpsw.c (lines 5825 to 7346 from .patch file). 6. Then repeated steps 1 through 4 again, but using the edited patch. 7. Use menuconfig to activate Full-Preemption. 8. ./tools/rebuild.sh 9. ./tools/install_kernel.sh (with the modifications in the system.sh file) 10. Plug the SD card in the BBB. and it never booted. I have seen the osadl 3.8.12 kernel, but I'm more interested in using the 3.8.13 kernel. If anyone could give away any ideas, I would be really grateful. Thank you for your time. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re: [beagleboard] Re: BBB + PREEMPT_RT
Hi ,all. I had been reading this thread of PREEMPT_RT for a few days. (I miss the starting mails since I can't get to the web page of google groups) For my situation, I just need my userspace program run once every 1ms sys tick. The result will be writed to a fifo in FPGA to achive realtime IO control. Can this be achive by eanbling PREEMPT ? any other works need? 2014-02-28 16:53:26 您在来信中写道： Thanks for you tips. I am using a minimal Ubuntu system without a full desktop that is based on http://www.armhf.com/index.php/boards/beaglebone-black/#precise. I used apt-get to update the system. The integrated eMMC and HDMI are deactivated. To create a network stress I used Ubuntu's iperf in server mode from another ssh shell while running stress and cyclictest at the same time. The transfer rate to another Ubuntu box reached 94.7 MBit/s and 100MB were copied. The latency numbers did not change. Am Mittwoch, 26. Februar 2014 16:58:31 UTC+1 schrieb Charles Steinkuehler: Xenomai includes a dohell script that can generate disk and network load. You can always just dd to a file for a while. If you're running a Debian/Ubuntu based system, I've found that running aptitude upgrade if you have a few dated packages can be a major stress to the system. That gets you both network and disk load, and not so long ago had a decent chance of wedging the eMMC kernel driver (even without the Xenomai patches that 'tickled' the eMMC driver bug and made it more likely to happen). Opening GUI programs and moving windows around is another good stress. On 2/26/2014 9:48 AM, quik...@gmail.com wrote: The stress tool generates cpu load only. But it is a good idea to consider other load scenarios, too. The current test was done using ssh so there was at least some network activity. Do you know of a good test tool which allows to generate disk and network load? Am Mittwoch, 26. Februar 2014 15:58:55 UTC+1 schrieb Charles Steinkuehler: Those are pretty good numbers. Did you have heavy network and disk (uSD/eMMC) load going as well? IIRC, the uSD/eMMC driver was responsible for the worst of the latency spikes I saw, but that's been some time ago and based on the OMAP kernel list traffic, it appears there have been lots of improvements to that code. On 2/26/2014 7:53 AM, quik...@gmail.com javascript: wrote: I have recently tested kernel 3.8.13-rt9 ( https://github.com/beagleboard/kernel/tree/3.8-rt) using git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am using Ubuntu 12.04.4. The load was created using stress �Ccpu 1 which generates a cpu load of about 100%. I then used cyclictest: root@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l100 -m -n -t1 -p99 -i400 -q # /dev/cpu_dma_latency set to 0us T: 0 ( 770) P:99 I:400 C:100 Min: 14 Act: 19 Avg: 18 Max: 132 uname -a reports: root@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux I am absolutely surprised that the result is looking that good. Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...@gmail.com: I am trying to figure out how to create a kernel for the BBB that supports PREEMPT_RT. It's kind of strange that the BBB's default kernel does not even have PREEMPT activated. Such a board doesn't fit to many embedded applications where we need at least some kind of determinism. It is even worse, that nobody seems to care about this problem. Contrary to that, the Raspberry PI's standard kernel has PREEMPT activacted from the very beginning. I have tested Robert Nelsons kernel 3.8.13-r9 ( https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have PREEMPT_RT activated by default. When doing so, it does not boot. But activating PREEMPT does work. However, development of this branch has stopped several months ago. The official source for RT Linux (3.8.13) has evolved since then. Meanwhile there's an rt17 patch set ( https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody give this a try? Does it work with the BBB? -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- Charles Steinkuehler cha...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. 在此邮件中未发现病毒。 检查工具：AVG - www.avg.com 版本：2014.0.4259 / 病毒数据库：3705/7143 - 发布日期：03/02/14 = = = = = = = = = = = = = = = = = = = = = = 致 礼！ Yang wingli...@163.com 2014-03-04 -- For
Re: [beagleboard] Re: BBB + PREEMPT_RT
Thanks for you tips. I am using a minimal Ubuntu system without a full desktop that is based on http://www.armhf.com/index.php/boards/beaglebone-black/#precise. I used apt-get to update the system. The integrated eMMC and HDMI are deactivated. To create a network stress I used Ubuntu's iperf in server mode from another ssh shell while running stress and cyclictest at the same time. The transfer rate to another Ubuntu box reached 94.7 MBit/s and 100MB were copied. The latency numbers did not change. Am Mittwoch, 26. Februar 2014 16:58:31 UTC+1 schrieb Charles Steinkuehler: Xenomai includes a dohell script that can generate disk and network load. You can always just dd to a file for a while. If you're running a Debian/Ubuntu based system, I've found that running aptitude upgrade if you have a few dated packages can be a major stress to the system. That gets you both network and disk load, and not so long ago had a decent chance of wedging the eMMC kernel driver (even without the Xenomai patches that 'tickled' the eMMC driver bug and made it more likely to happen). Opening GUI programs and moving windows around is another good stress. On 2/26/2014 9:48 AM, quik...@gmail.com javascript: wrote: The stress tool generates cpu load only. But it is a good idea to consider other load scenarios, too. The current test was done using ssh so there was at least some network activity. Do you know of a good test tool which allows to generate disk and network load? Am Mittwoch, 26. Februar 2014 15:58:55 UTC+1 schrieb Charles Steinkuehler: Those are pretty good numbers. Did you have heavy network and disk (uSD/eMMC) load going as well? IIRC, the uSD/eMMC driver was responsible for the worst of the latency spikes I saw, but that's been some time ago and based on the OMAP kernel list traffic, it appears there have been lots of improvements to that code. On 2/26/2014 7:53 AM, quik...@gmail.com javascript: wrote: I have recently tested kernel 3.8.13-rt9 ( https://github.com/beagleboard/kernel/tree/3.8-rt) using git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am using Ubuntu 12.04.4. The load was created using stress –cpu 1 which generates a cpu load of about 100%. I then used cyclictest: root@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l100 -m -n -t1 -p99 -i400 -q # /dev/cpu_dma_latency set to 0us T: 0 ( 770) P:99 I:400 C:100 Min: 14 Act: 19 Avg: 18 Max: 132 uname -a reports: root@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux I am absolutely surprised that the result is looking that good. Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...@gmail.com: I am trying to figure out how to create a kernel for the BBB that supports PREEMPT_RT. It's kind of strange that the BBB's default kernel does not even have PREEMPT activated. Such a board doesn't fit to many embedded applications where we need at least some kind of determinism. It is even worse, that nobody seems to care about this problem. Contrary to that, the Raspberry PI's standard kernel has PREEMPT activacted from the very beginning. I have tested Robert Nelsons kernel 3.8.13-r9 ( https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have PREEMPT_RT activated by default. When doing so, it does not boot. But activating PREEMPT does work. However, development of this branch has stopped several months ago. The official source for RT Linux (3.8.13) has evolved since then. Meanwhile there's an rt17 patch set ( https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody give this a try? Does it work with the BBB? -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[beagleboard] Re: BBB + PREEMPT_RT
Interesting result. Would be nice to see a histogram. I will try and duplicate this measurement. Also doing the some measure with the standard kernel would be informative. That upper tail of 132 is a big problem for me. On Thursday, February 27, 2014 12:53:05 AM UTC+11, quik...@gmail.com wrote: I have recently tested kernel 3.8.13-rt9 ( https://github.com/beagleboard/kernel/tree/3.8-rt) using git:// git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am using Ubuntu 12.04.4. The load was created using stress –cpu 1 which generates a cpu load of about 100%. I then used cyclictest: root@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l100 -m -n -t1 -p99 -i400 -q # /dev/cpu_dma_latency set to 0us T: 0 ( 770) P:99 I:400 C:100 Min: 14 Act: 19 Avg: 18 Max: 132 uname -a reports: root@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux I am absolutely surprised that the result is looking that good. Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...@gmail.com: I am trying to figure out how to create a kernel for the BBB that supports PREEMPT_RT. It's kind of strange that the BBB's default kernel does not even have PREEMPT activated. Such a board doesn't fit to many embedded applications where we need at least some kind of determinism. It is even worse, that nobody seems to care about this problem. Contrary to that, the Raspberry PI's standard kernel has PREEMPT activacted from the very beginning. I have tested Robert Nelsons kernel 3.8.13-r9 ( https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have PREEMPT_RT activated by default. When doing so, it does not boot. But activating PREEMPT does work. However, development of this branch has stopped several months ago. The official source for RT Linux (3.8.13) has evolved since then. Meanwhile there's an rt17 patch set ( https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody give this a try? Does it work with the BBB? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[beagleboard] Re: BBB + PREEMPT_RT
I have recently tested kernel 3.8.13-rt9 ( https://github.com/beagleboard/kernel/tree/3.8-rt) using git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am using Ubuntu 12.04.4. The load was created using stress –cpu 1 which generates a cpu load of about 100%. I then used cyclictest: root@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l100 -m -n -t1 -p99 -i400 -q # /dev/cpu_dma_latency set to 0us T: 0 ( 770) P:99 I:400 C:100 Min: 14 Act: 19 Avg: 18 Max: 132 uname -a reports: root@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux I am absolutely surprised that the result is looking that good. Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...@gmail.com: I am trying to figure out how to create a kernel for the BBB that supports PREEMPT_RT. It's kind of strange that the BBB's default kernel does not even have PREEMPT activated. Such a board doesn't fit to many embedded applications where we need at least some kind of determinism. It is even worse, that nobody seems to care about this problem. Contrary to that, the Raspberry PI's standard kernel has PREEMPT activacted from the very beginning. I have tested Robert Nelsons kernel 3.8.13-r9 ( https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have PREEMPT_RT activated by default. When doing so, it does not boot. But activating PREEMPT does work. However, development of this branch has stopped several months ago. The official source for RT Linux (3.8.13) has evolved since then. Meanwhile there's an rt17 patch set ( https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody give this a try? Does it work with the BBB? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [beagleboard] Re: BBB + PREEMPT_RT
Those are pretty good numbers. Did you have heavy network and disk (uSD/eMMC) load going as well? IIRC, the uSD/eMMC driver was responsible for the worst of the latency spikes I saw, but that's been some time ago and based on the OMAP kernel list traffic, it appears there have been lots of improvements to that code. On 2/26/2014 7:53 AM, quikcj...@gmail.com wrote: I have recently tested kernel 3.8.13-rt9 ( https://github.com/beagleboard/kernel/tree/3.8-rt) using git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am using Ubuntu 12.04.4. The load was created using stress –cpu 1 which generates a cpu load of about 100%. I then used cyclictest: root@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l100 -m -n -t1 -p99 -i400 -q # /dev/cpu_dma_latency set to 0us T: 0 ( 770) P:99 I:400 C:100 Min: 14 Act: 19 Avg: 18 Max: 132 uname -a reports: root@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux I am absolutely surprised that the result is looking that good. Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...@gmail.com: I am trying to figure out how to create a kernel for the BBB that supports PREEMPT_RT. It's kind of strange that the BBB's default kernel does not even have PREEMPT activated. Such a board doesn't fit to many embedded applications where we need at least some kind of determinism. It is even worse, that nobody seems to care about this problem. Contrary to that, the Raspberry PI's standard kernel has PREEMPT activacted from the very beginning. I have tested Robert Nelsons kernel 3.8.13-r9 ( https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have PREEMPT_RT activated by default. When doing so, it does not boot. But activating PREEMPT does work. However, development of this branch has stopped several months ago. The official source for RT Linux (3.8.13) has evolved since then. Meanwhile there's an rt17 patch set ( https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody give this a try? Does it work with the BBB? -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [beagleboard] Re: BBB + PREEMPT_RT
The stress tool generates cpu load only. But it is a good idea to consider other load scenarios, too. The current test was done using ssh so there was at least some network activity. Do you know of a good test tool which allows to generate disk and network load? Am Mittwoch, 26. Februar 2014 15:58:55 UTC+1 schrieb Charles Steinkuehler: Those are pretty good numbers. Did you have heavy network and disk (uSD/eMMC) load going as well? IIRC, the uSD/eMMC driver was responsible for the worst of the latency spikes I saw, but that's been some time ago and based on the OMAP kernel list traffic, it appears there have been lots of improvements to that code. On 2/26/2014 7:53 AM, quik...@gmail.com javascript: wrote: I have recently tested kernel 3.8.13-rt9 ( https://github.com/beagleboard/kernel/tree/3.8-rt) using git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am using Ubuntu 12.04.4. The load was created using stress –cpu 1 which generates a cpu load of about 100%. I then used cyclictest: root@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l100 -m -n -t1 -p99 -i400 -q # /dev/cpu_dma_latency set to 0us T: 0 ( 770) P:99 I:400 C:100 Min: 14 Act: 19 Avg: 18 Max: 132 uname -a reports: root@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux I am absolutely surprised that the result is looking that good. Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...@gmail.com: I am trying to figure out how to create a kernel for the BBB that supports PREEMPT_RT. It's kind of strange that the BBB's default kernel does not even have PREEMPT activated. Such a board doesn't fit to many embedded applications where we need at least some kind of determinism. It is even worse, that nobody seems to care about this problem. Contrary to that, the Raspberry PI's standard kernel has PREEMPT activacted from the very beginning. I have tested Robert Nelsons kernel 3.8.13-r9 ( https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have PREEMPT_RT activated by default. When doing so, it does not boot. But activating PREEMPT does work. However, development of this branch has stopped several months ago. The official source for RT Linux (3.8.13) has evolved since then. Meanwhile there's an rt17 patch set ( https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody give this a try? Does it work with the BBB? -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [beagleboard] Re: BBB + PREEMPT_RT
Xenomai includes a dohell script that can generate disk and network load. You can always just dd to a file for a while. If you're running a Debian/Ubuntu based system, I've found that running aptitude upgrade if you have a few dated packages can be a major stress to the system. That gets you both network and disk load, and not so long ago had a decent chance of wedging the eMMC kernel driver (even without the Xenomai patches that 'tickled' the eMMC driver bug and made it more likely to happen). Opening GUI programs and moving windows around is another good stress. On 2/26/2014 9:48 AM, quikcj...@gmail.com wrote: The stress tool generates cpu load only. But it is a good idea to consider other load scenarios, too. The current test was done using ssh so there was at least some network activity. Do you know of a good test tool which allows to generate disk and network load? Am Mittwoch, 26. Februar 2014 15:58:55 UTC+1 schrieb Charles Steinkuehler: Those are pretty good numbers. Did you have heavy network and disk (uSD/eMMC) load going as well? IIRC, the uSD/eMMC driver was responsible for the worst of the latency spikes I saw, but that's been some time ago and based on the OMAP kernel list traffic, it appears there have been lots of improvements to that code. On 2/26/2014 7:53 AM, quik...@gmail.com javascript: wrote: I have recently tested kernel 3.8.13-rt9 ( https://github.com/beagleboard/kernel/tree/3.8-rt) using git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am using Ubuntu 12.04.4. The load was created using stress –cpu 1 which generates a cpu load of about 100%. I then used cyclictest: root@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l100 -m -n -t1 -p99 -i400 -q # /dev/cpu_dma_latency set to 0us T: 0 ( 770) P:99 I:400 C:100 Min: 14 Act: 19 Avg: 18 Max: 132 uname -a reports: root@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux I am absolutely surprised that the result is looking that good. Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...@gmail.com: I am trying to figure out how to create a kernel for the BBB that supports PREEMPT_RT. It's kind of strange that the BBB's default kernel does not even have PREEMPT activated. Such a board doesn't fit to many embedded applications where we need at least some kind of determinism. It is even worse, that nobody seems to care about this problem. Contrary to that, the Raspberry PI's standard kernel has PREEMPT activacted from the very beginning. I have tested Robert Nelsons kernel 3.8.13-r9 ( https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have PREEMPT_RT activated by default. When doing so, it does not boot. But activating PREEMPT does work. However, development of this branch has stopped several months ago. The official source for RT Linux (3.8.13) has evolved since then. Meanwhile there's an rt17 patch set ( https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody give this a try? Does it work with the BBB? -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [beagleboard] Re: BBB + PREEMPT_RT
While I agree with your definition I'd like to know where you have got this results as mine in worst case conditions have been somewhat different, and worst includes load+running in SD card the latency test average have been more around 40 µS: http://flic.kr/ps/2LwUC9 Therefore, I'm confident in the new latency measurements that I'm going to do with the Charles' Xenomaibone39 from the emmC, as it will those in SD. Le dimanche 23 février 2014 22:06:05 UTC+1, john3909 a écrit : From: robert.berger robert.ka...@gmail.com javascript: Reply-To: beagl...@googlegroups.com javascript: Date: Sunday, February 23, 2014 at 3:26 AM To: beagl...@googlegroups.com javascript: Cc: rchrd...@gmail.com javascript: Subject: [beagleboard] Re: BBB + PREEMPT_RT Hi, On Saturday, February 22, 2014 2:17:24 PM UTC+2, rchrd...@gmail.com wrote: Just a few thoughts ... It is not possible to have a fully deterministic real-time operating system on a processor that uses instruction/data caches. ie you have to turn off the cacheing to achieve determinism and eliminate performance jitter (which then degrades the average performance). Yep, but, that's the easy part. How about pipelines and instructions reordering done by the compiler and the processor? How about interrupts? How about multi-cores? How about the drift of the crystal you use as the clock source of your CPU? You might be shocked now, but as you can see it's impossible to have a hard real-time system with state of the art (multi-core) processors. Is it? I think that you need to come up with a realistic test suite to see if preempt-rt (with or without CPU isolation) is good enough, or if you need Xenomai (still you will see issues if Xenomai and Linux use the same caches), or some dedicated hardware like PRU. There is also some interesting work by Jan Kiszka - not yet on ARM.[1] I think there is some confusion about what real-time really means. It doesn’t mean fast or even consistent, it just means that it will respond to some event in a required time. If your requirement is that something respond in 1 second, then Linux kernel is good for real-time. If you want a response of less than 1ms, then the Linux interrupt latency may not meet this requirement. Remember, latency tests are conducted when the processor is under load. Xenomai running on the BBB can achieve 50uS interrupt latency whereas preempt-rt is more like 200uS. Regards, John Regards, Robert [1] http://lwn.net/Articles/574273/ Shameless self promotion: [2] http://www.reliableembeddedsystems.com/pdfs/2010_03_04_rt_linux.pdf [3] http://www.embedded.com/design/operating-systems/4204740/Getting-real--time--about-embedded-GNU-Linux -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[beagleboard] Re: BBB + PREEMPT_RT
Hi, On Saturday, February 22, 2014 2:17:24 PM UTC+2, rchrd...@gmail.com wrote: Just a few thoughts ... It is not possible to have a fully deterministic real-time operating system on a processor that uses instruction/data caches. ie you have to turn off the cacheing to achieve determinism and eliminate performance jitter (which then degrades the average performance). Yep, but, that's the easy part. How about pipelines and instructions reordering done by the compiler and the processor? How about interrupts? How about multi-cores? How about the drift of the crystal you use as the clock source of your CPU? You might be shocked now, but as you can see it's impossible to have a hard real-time system with state of the art (multi-core) processors. Is it? I think that you need to come up with a realistic test suite to see if preempt-rt (with or without CPU isolation) is good enough, or if you need Xenomai (still you will see issues if Xenomai and Linux use the same caches), or some dedicated hardware like PRU. There is also some interesting work by Jan Kiszka - not yet on ARM.[1] Regards, Robert [1] http://lwn.net/Articles/574273/ Shameless self promotion: [2] http://www.reliableembeddedsystems.com/pdfs/2010_03_04_rt_linux.pdf [3] http://www.embedded.com/design/operating-systems/4204740/Getting-real--time--about-embedded-GNU-Linux -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[beagleboard] Re: BBB + PREEMPT_RT
Hi, On Saturday, February 22, 2014 1:17:24 PM UTC+1, rchrd...@gmail.com wrote: It is not possible to have a fully deterministic real-time operating system on a processor that uses instruction/data caches. ie you have to turn off the cacheing to achieve determinism and eliminate performance jitter (which then degrades the average performance). That is correct (in theory), but you need to figure out what kind of real-time requirements you have on your system first to understand if that is important or not. You typically divide real-time operating systems in these 3 categories; - *Hard:* Missing a deadline is a total system failure. - *Firm:* Infrequent deadline misses are tolerable, but may degrade the systems quality of service. The usefulness of a result is zero after its deadline. - *Soft:* The usefulness of a result degrades after its deadline, thereby degrading the system's quality of service Above defintions from http://en.wikipedia.org/wiki/Real-time_computing If you have Hard real-time requirements you typically do not try to run that application in Linux user-space, not even with PREEMPT-RT. That is the task for dedicated real-time solutions such as the PRU co-processor or dedicated real-time OSes. Firm real-time can be solved using Linux PREEMPT-RT though, and also soft of course. I did a quick benchmark on the BBone some time ago on the 3.4.39-rt54 kernel and found bounded latencies in the 60us range. So if you have firm real-time requirements and can accept latencies in that range PREEMPT-RT can be a solution. From what I understand PREEMPT_RT does not really improve the real-time performance of linux if you stick to user level applications. You have to start doing things at kernel level, which can get difficult and break many of the existing device drivers. Anyway, who said all embedded applications require a deterministic real-time performance? Soft real-time performance is generally good enough for a lot of applications. The point of PREEMPT-RT is to provide bounded latencies for user-space applications (SCHED_FIFO tasks), without PREEMPT-RT can can't count on bounded latencies in Linux (even for SCHED_FIFO tasks). For real-time, the PRU co-processors are the way to go. Agreed, but that is for hard real-time. And programming the PRU is not at all as convenient as programming user-space applications in Linux on the posix interface. Posix on top of Linux with PREEMPT-RT provides you with a preemptive programming model (if needed) and bounded latencies, though you need to be careful with which system calls you are using. Regards Daniel -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [beagleboard] Re: BBB + PREEMPT_RT
From: robert.berger robert.karl.ber...@gmail.com Reply-To: beagleboard@googlegroups.com Date: Sunday, February 23, 2014 at 3:26 AM To: beagleboard@googlegroups.com Cc: rchrdly...@gmail.com Subject: [beagleboard] Re: BBB + PREEMPT_RT Hi, On Saturday, February 22, 2014 2:17:24 PM UTC+2, rchrd...@gmail.com wrote: Just a few thoughts ... It is not possible to have a fully deterministic real-time operating system on a processor that uses instruction/data caches. ie you have to turn off the cacheing to achieve determinism and eliminate performance jitter (which then degrades the average performance). Yep, but, that's the easy part. How about pipelines and instructions reordering done by the compiler and the processor? How about interrupts? How about multi-cores? How about the drift of the crystal you use as the clock source of your CPU? You might be shocked now, but as you can see it's impossible to have a hard real-time system with state of the art (multi-core) processors. Is it? I think that you need to come up with a realistic test suite to see if preempt-rt (with or without CPU isolation) is good enough, or if you need Xenomai (still you will see issues if Xenomai and Linux use the same caches), or some dedicated hardware like PRU. There is also some interesting work by Jan Kiszka - not yet on ARM.[1] I think there is some confusion about what real-time really means. It doesn¹t mean fast or even consistent, it just means that it will respond to some event in a required time. If your requirement is that something respond in 1 second, then Linux kernel is good for real-time. If you want a response of less than 1ms, then the Linux interrupt latency may not meet this requirement. Remember, latency tests are conducted when the processor is under load. Xenomai running on the BBB can achieve 50uS interrupt latency whereas preempt-rt is more like 200uS. Regards, John Regards, Robert [1] http://lwn.net/Articles/574273/ Shameless self promotion: [2] http://www.reliableembeddedsystems.com/pdfs/2010_03_04_rt_linux.pdf [3] http://www.embedded.com/design/operating-systems/4204740/Getting-real--time--a bout-embedded-GNU-Linux -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [beagleboard] Re: BBB + PREEMPT_RT
Hi, For those interested in what the BBB can do in terms of interrupt latencies with PREEMPT-RT applied, OSADL actually has one in their QA racks; https://www.osadl.org/Profile-of-system-in-rack-7-slot-8.qa-profile-r7s8.0.html Most recent latency plot (under load) is here: https://www.osadl.org/Latency-plot-of-system-in-rack-7-slot.qa-latencyplot-r7s8.0.html Regards Daniel On Sun, Feb 23, 2014 at 10:06 PM, John Syn john3...@gmail.com wrote: From: robert.berger robert.karl.ber...@gmail.com Reply-To: beagleboard@googlegroups.com Date: Sunday, February 23, 2014 at 3:26 AM To: beagleboard@googlegroups.com Cc: rchrdly...@gmail.com Subject: [beagleboard] Re: BBB + PREEMPT_RT Hi, On Saturday, February 22, 2014 2:17:24 PM UTC+2, rchrd...@gmail.com wrote: Just a few thoughts ... It is not possible to have a fully deterministic real-time operating system on a processor that uses instruction/data caches. ie you have to turn off the cacheing to achieve determinism and eliminate performance jitter (which then degrades the average performance). Yep, but, that's the easy part. How about pipelines and instructions reordering done by the compiler and the processor? How about interrupts? How about multi-cores? How about the drift of the crystal you use as the clock source of your CPU? You might be shocked now, but as you can see it's impossible to have a hard real-time system with state of the art (multi-core) processors. Is it? I think that you need to come up with a realistic test suite to see if preempt-rt (with or without CPU isolation) is good enough, or if you need Xenomai (still you will see issues if Xenomai and Linux use the same caches), or some dedicated hardware like PRU. There is also some interesting work by Jan Kiszka - not yet on ARM.[1] I think there is some confusion about what real-time really means. It doesn't mean fast or even consistent, it just means that it will respond to some event in a required time. If your requirement is that something respond in 1 second, then Linux kernel is good for real-time. If you want a response of less than 1ms, then the Linux interrupt latency may not meet this requirement. Remember, latency tests are conducted when the processor is under load. Xenomai running on the BBB can achieve 50uS interrupt latency whereas preempt-rt is more like 200uS. Regards, John Regards, Robert [1] http://lwn.net/Articles/574273/ Shameless self promotion: [2] http://www.reliableembeddedsystems.com/pdfs/2010_03_04_rt_linux.pdf [3] http://www.embedded.com/design/operating-systems/4204740/Getting-real--time--about-embedded-GNU-Linux -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/gJ_iFT2IwEQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [beagleboard] Re: BBB + PREEMPT_RT
From: Daniel Nilsson dan...@dnil.se Reply-To: beagleboard@googlegroups.com Date: Sunday, February 23, 2014 at 1:19 PM To: beagleboard@googlegroups.com Subject: Re: [beagleboard] Re: BBB + PREEMPT_RT Hi, For those interested in what the BBB can do in terms of interrupt latencies with PREEMPT-RT applied, OSADL actually has one in their QA racks; https://www.osadl.org/Profile-of-system-in-rack-7-slot-8.qa-profile-r7s8.0.htm l Most recent latency plot (under load) is here: https://www.osadl.org/Latency-plot-of-system-in-rack-7-slot.qa-latencyplot-r7s 8.0.html Very interesting. Looks like preempt-rt is getting better all the time. At 110uS, it is only double that of Xenomai and for most applications that won¹t matter. Regards, John Regards Daniel On Sun, Feb 23, 2014 at 10:06 PM, John Syn john3...@gmail.com wrote: From: robert.berger robert.karl.ber...@gmail.com Reply-To: beagleboard@googlegroups.com Date: Sunday, February 23, 2014 at 3:26 AM To: beagleboard@googlegroups.com Cc: rchrdly...@gmail.com Subject: [beagleboard] Re: BBB + PREEMPT_RT Hi, On Saturday, February 22, 2014 2:17:24 PM UTC+2, rchrd...@gmail.com wrote: Just a few thoughts ... It is not possible to have a fully deterministic real-time operating system on a processor that uses instruction/data caches. ie you have to turn off the cacheing to achieve determinism and eliminate performance jitter (which then degrades the average performance). Yep, but, that's the easy part. How about pipelines and instructions reordering done by the compiler and the processor? How about interrupts? How about multi-cores? How about the drift of the crystal you use as the clock source of your CPU? You might be shocked now, but as you can see it's impossible to have a hard real-time system with state of the art (multi-core) processors. Is it? I think that you need to come up with a realistic test suite to see if preempt-rt (with or without CPU isolation) is good enough, or if you need Xenomai (still you will see issues if Xenomai and Linux use the same caches), or some dedicated hardware like PRU. There is also some interesting work by Jan Kiszka - not yet on ARM.[1] I think there is some confusion about what real-time really means. It doesn¹t mean fast or even consistent, it just means that it will respond to some event in a required time. If your requirement is that something respond in 1 second, then Linux kernel is good for real-time. If you want a response of less than 1ms, then the Linux interrupt latency may not meet this requirement. Remember, latency tests are conducted when the processor is under load. Xenomai running on the BBB can achieve 50uS interrupt latency whereas preempt-rt is more like 200uS. Regards, John Regards, Robert [1] http://lwn.net/Articles/574273/ Shameless self promotion: [2] http://www.reliableembeddedsystems.com/pdfs/2010_03_04_rt_linux.pdf [3] http://www.embedded.com/design/operating-systems/4204740/Getting-real--time- -about-embedded-GNU-Linux -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/gJ_iFT2IwEQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com mailto:beagleboard%2bunsubscr...@googlegroups.com . For more options, visit https://groups.google.com/groups/opt_out. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[beagleboard] Re: BBB + PREEMPT_RT
Just a few thoughts ... It is not possible to have a fully deterministic real-time operating system on a processor that uses instruction/data caches. ie you have to turn off the cacheing to achieve determinism and eliminate performance jitter (which then degrades the average performance). From what I understand PREEMPT_RT does not really improve the real-time performance of linux if you stick to user level applications. You have to start doing things at kernel level, which can get difficult and break many of the existing device drivers. Anyway, who said all embedded applications require a deterministic real-time performance? Soft real-time performance is generally good enough for a lot of applications. For real-time, the PRU co-processors are the way to go. There are a number of papers around on the web comparing the performance of normal linux, PREEMPT_RT and Xemonai in real-world situations (use google to find them). They make for interesting reading and caused me to re-access my approach to embedded linux systems. Regards ... On Friday, February 21, 2014 7:20:39 PM UTC+11, quik...@gmail.com wrote: I am trying to figure out how to create a kernel for the BBB that supports PREEMPT_RT. It's kind of strange that the BBB's default kernel does not even have PREEMPT activated. Such a board doesn't fit to many embedded applications where we need at least some kind of determinism. It is even worse, that nobody seems to care about this problem. Contrary to that, the Raspberry PI's standard kernel has PREEMPT activacted from the very beginning. I have tested Robert Nelsons kernel 3.8.13-r9 ( https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have PREEMPT_RT activated by default. When doing so, it does not boot. But activating PREEMPT does work. However, development of this branch has stopped several months ago. The official source for RT Linux (3.8.13) has evolved since then. Meanwhile there's an rt17 patch set ( https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody give this a try? Does it work with the BBB? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
