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 ?).
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 ?
Thank you very much,
Antoine
--
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
