Real-Time & Determinism

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

Hello,

Can you give some links of one and the other?

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

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

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

The USB hardware itself is non-deterministic, from what I hear from the USB guys. But it all depends on what you need.

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

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Selon Lee Revell <[email protected]>:

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

Antoine

On Thu, May 28, 2009 at 12:16:32PM +0200, [email protected] wrote:

| Selon Lee Revell <[email protected]>:
| 
| >
| > 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 ]