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" <[email protected] <javascript:>> > Reply-To: <[email protected] <javascript:>> > Date: Sunday, February 23, 2014 at 3:26 AM > To: <[email protected] <javascript:>> > Cc: <[email protected] <javascript:>> > 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] <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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
