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.
