OSDev.org

From: https://rt.wiki.kernel.org/articles/f/r ... _7407.html

Real-time only has impact on the kernel; Userspace does not notice the difference except for better real time behavior.

Does it mean that if we write the applications in user space, they won't get the hard real time effect?

Hi,

AnishaKaul wrote:From: https://rt.wiki.kernel.org/articles/f/r ... _7407.html

Real-time only has impact on the kernel; Userspace does not notice the difference except for better real time behavior.

Does it mean that if we write the applications in user space, they won't get the hard real time effect?

If you actually need to sacrifice performance (average time taken) for guaranteed worst case time taken; then you probably should be using an embedded system with purpose designed software (e.g. no OS at all); and shouldn't be using normal computers (with things like SMM) and normal OSs that were designed for performance (and therefore not designed for hard real time).

My guess is that you have no reason to care about hard real time, and made the mistake of assuming that "hard real time" means "better performance" even though the opposite is true.

EDIT: Also note that as far as OSs go, stock Linux is probably the worst there is for "soft real time" because it was designed for throughput and not latency. As far as I can tell, the "CONFIG_PREEMPT_RT patch" is an attempt to make Linux slightly less unusable for soft real time; doesn't actually make Linux soft real time, and will never make Linux hard real time.


Cheers,

Brendan

Thanks, I'll consider your point for sure, but currently I need to understand the "meaning" of the above quote.

AnishaKaul wrote:From: https://rt.wiki.kernel.org/articles/f/r ... _7407.html

Real-time only has impact on the kernel; Userspace does not notice the difference except for better real time behavior.

Does it mean that if we write the applications in user space, they won't get the hard real time effect?

What CPU are you targeting? If it's x86, forget about hard real time completely. SMM makes it impossible to implement a hard real time system. Most modern general purpose CPU architectures are very ill suited for real time applications, especially if you're running Linux. The worst case execution time for a given function is almost impossible to generate for CPU's that implement caches, branch prediction, TLB's (so pretty much any CPU with virtual memory), write\store buffers, power saving, and other features that contribute to the non-determinism of execution time.

In reality, there are very few uses for hard real time systems, and using a CPU that is complex enough that it can run Linux (or any OS for that matter) is probably too risky anyways. Such systems are typically only present in systems like fly-by-wire aircraft, medical devices (e.g. radiation therapy), satellites, etc, where there is zero tolerance for failure.

Rudster816 wrote:What CPU are you targeting? If it's x86, forget about hard real time completely. SMM makes it impossible to implement a hard real time system.

Thanks very much for the enlightenment.
I'll discuss that in a new thread since this thread is only about
understanding the meaning of the quote from that FAQ.

Hi,

AnishaKaul wrote:Thanks, I'll consider your point for sure, but currently I need to understand the "meaning" of the above quote.

Essentially, the meaning of the above quote is:

Nobody has ever wasted their time caring about irrelevant real time stuff in Linux, the entire system (starting from the stock kernel and going all the way throughout all of user-space) was not designed for any kind of real time (not even soft real time, even though soft real time is a meaningless marketing joke). Normal/portable applications (e.g. those that try to use real time scheduling via. the pthreads API) can't even try to touch real-time (it requires root privileges and becomes a massive security nightmare).

Stock Linux was so badly designed (or, designed for throughput and not latency) that it sucked for simple stuff like boring old desktop software. The "real time" patch was needed to improve latency for desktop software that doesn't have any real time requirements at all; and (whether the authors like it or not) the "real time" patch is entirely useless for anything that does have any actual real time requirements.

I hope that clears things up...


Cheers,

Brendan