Re: Real-Time & Determinism

[Antoine Nourry <nourry@free.fr>]

>> 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