On Sat, May 23, 2009 at 03:58:43PM +0200, Antoine Nourry wrote: >>> why can we read everywhere that Preempt_RT offers hard real time >>> capabilities while on another hand we can find in some papers that it is >>> not deterministic and only gives assurance to obtain low latencies ? >>> is it real >>> >> Can you give some links of one and the other? >> > For hard real time capabilities it is said (among numerous others) in > http://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#About_the_RT-Preempt_Patch > > /"The standard Linux kernel only meets soft real-time requirements: it > provides basic POSIX operations for userspace time handling but has no > guarantees for hard timing deadlines. With Ingo Molnar's Realtime > Preemption patch (referenced to as RT-Preempt in this document) and Thomas > Gleixner's generic clock event layer with high resolution support, the > kernel gains hard realtime capabilities."/ > > For lack of determinism : > > http://lwn.net/Articles/106010/ : > > /"NOTE: deterministic hard-rt is not about speed, it's about determinism. > While Ingo's work is great at reducing latency, it cannot *guarantee* > response times regardless of the load, kernel configuration, and driver > set. RTAI/fusion, and the Adeos interrupt pipeline on a smaller scale, can > provide such guarantees."/ > > Actually, as you guessed i'm a beginner in real time sphere. I used Xenomai > for a previous work : turn a native linux driver for an USB DAQ device into > a real time one to ensure acquisitions within a definite cycle. The problem > is that i had to use a real time USB stack and only found USB4RT which > works but with some bugs and limitations. I'm now interested with the > RT_Preempt patch that would make me able to use the native Linux USB stack > (i'm not sure of this point..., Is it only possible to obtain *constant > execution times* using USB with RT_Preempt ?). The USB hardware itself is non-deterministic, from what I hear from the USB guys. But it all depends on what you need. >>> time or not (deterministic) ? if yes, is it hard or soft RT ? Please >>> excuse me if i've missed something important. >> >> This is a simplistic summary as I learned it: >> >> It's hard real-time behaviour. >> >> However, as the kernel consist of a large amount of code, every piece >> of code must behave properly with regard to locking etc. so that the >> real-time scheduler is actually able to pre-empt with low latency >> intervals. >> >> The tracing code has been included to find those long no-pre-empt >> spots in the kernel code. >> > So, Is gaining total determinism under RT_Preempt just a matter of testing > that your particular code will not call "those long no-preempt spots" which > hadn't or couldn't been cut off from the kernel ? That is indeed one definition that real users actually use for "hard realtime". Such users will provide a test suite based on what their real-time application will be doing. Not particularly satisfying from a theoretical viewpoint, perhaps, but this is what really happens for some sorts of applications. There are a number of other definitions, see for example: http://www.linuxjournal.com/article/9361 In theory, one could analyze the Linux kernel to identify the longest section of code running with preemption disabled, but as far as I know this has not yet been done. So if you need a mathematical proof that your real-time OS will respond within a bounded time, then RT Linux might not be the right tool for your job. But a surprisingly large number of RT applications do not need that level of assurance. And I would not be surprised to hear that someone decided to bite the bullet and actually mechanically analyze the Linux source/binary for maximum latency. ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
