Real-Time & Determinism

Real-Time & Determinism

[Antoine Nourry]

Hi to all,
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 time or not (deterministic) ? if yes, is it hard or soft RT ? 
Please excuse me if i've missed something important.

Thanks for your work,
Antoine

Re: Real-Time & Determinism

[Leon Woestenberg]

Hello,

On Sat, May 23, 2009 at 3:04 PM, Antoine Nourry <nourry@free.fr> 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?

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

Regards,
-- 
Leon

Re: Real-Time & Determinism

[Antoine Nourry]

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

Re: Real-Time & Determinism

[Paul E. McKenney]

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

Re: Real-Time & Determinism

[Lee Revell]

On Tue, May 26, 2009 at 7:22 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> 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.  ;-)

Hi Antoine,

Keep in mind also that in -rt the non-preemptible sections are a very
small subset of the kernel code - last time I checked it was just the
timer ISR, the scheduler's SCHED_FIFO code, and the stub ISRs for the
other interrupts.  The rest does not need to be audited for
determinism.

Of course, for "total determinism" you also have to mathematically
prove the hardware behaves as expected...

Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Real-Time & Determinism

[nourry]

Selon Lee Revell <rlrevell@joe-job.com>:

>
> Hi Antoine,
>
> Keep in mind also that in -rt the non-preemptible sections are a very
> small subset of the kernel code - last time I checked it was just the
> timer ISR, the scheduler's SCHED_FIFO code, and the stub ISRs for the
> other interrupts.  The rest does not need to be audited for
> determinism.
>
> Of course, for "total determinism" you also have to mathematically
> prove the hardware behaves as expected...
>
> Lee
>

Thank you very much to all for your enlightments. Now it's time for me to test
this patch.

Antoine

Re: Real-Time & Determinism

[Luis Claudio R. Goncalves]

On Thu, May 28, 2009 at 12:16:32PM +0200, nourry@free.fr wrote:
| Selon Lee Revell <rlrevell@joe-job.com>:
| 
| >
| > Hi Antoine,
| >
| > Keep in mind also that in -rt the non-preemptible sections are a very
| > small subset of the kernel code - last time I checked it was just the
| > timer ISR, the scheduler's SCHED_FIFO code, and the stub ISRs for the
| > other interrupts.  The rest does not need to be audited for
| > determinism.
| >
| > Of course, for "total determinism" you also have to mathematically
| > prove the hardware behaves as expected...

That's a good point :)

I have been running tests in a fine piece of hardware that due to SMI
spikes (above 450us) may not be suitable for all the RT applications. That
must surely be taken in account and can be inspected using Jon Masters'
smi_detector kernel module.

| Thank you very much to all for your enlightments. Now it's time for me to test
| this patch.

Luis 
-- 
[ Luis Claudio R. Goncalves                    Bass - Gospel - RT ]
[ Fingerprint: 4FDD B8C4 3C59 34BD 8BE9  2696 7203 D980 A448 C8F8 ]