From: Daniel Nilsson <[email protected]> Reply-To: <[email protected]> Date: Sunday, February 23, 2014 at 1:19 PM To: <[email protected]> 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 Q&A 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 <[email protected]> wrote: >> >> From: "robert.berger" <[email protected]> >> Reply-To: <[email protected]> >> Date: Sunday, February 23, 2014 at 3:26 AM >> To: <[email protected]> >> Cc: <[email protected]> >> Subject: [beagleboard] Re: BBB + PREEMPT_RT >> >>> Hi, >>> >>> On Saturday, February 22, 2014 2:17:24 PM UTC+2, [email protected] 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 [email protected]. >>> 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 >> [email protected] >> <mailto:beagleboard%[email protected]> . >> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
