RTOS vs OS

A

Armin Steinhoff

Hi All,

On April 27, 2007, Vladimir Zyubin wrote:
> On April 24, 2007, Michael Griffin wrote:
> > In reply to Vladimir: An RTOS does not have to use a micro-kernel
> > and a use of a micro-kernel does not make an OS an RTOS. Good
> > examples of these are respectively, the RT versions of Linux which
> > use a monolithic kernel, and Minix 3 or Hurd which have
> > micro-kernels but are not an RTOS. <
>
>It looks like the apophatic theology... definition by negations. :)
>
>What are the RTOS features? <

The most important feature of an RTOS is producing results in a timely manner (meeting deadlines). There is no warranty that a MS-Windows OS can do that (CE excluded).

> I see no difference between QNX and
> Windows. Microkernal architecture only. <

Windows drivers are part of the Microsoft OS kernel... QNX drivers are Resources Managers which are running in their own protected address space!
That's the most important architectural difference between MS-Windows and QNX6 (and QNX4).

There are also big differences in process/thread scheduling policies between MS-Windows and QNX4. (Partitioning of CPU time, for example...)

> > Many people consider a micro-kernel to be a good basis for an RTOS
> > because the small size of the kernel means it is easier to verify
> > the length of the "locked" (uninterruptable) code sections (because
> > there is less code to review and maintain). The rest of the OS
> > processes are pushed out to modules with lower privilege levels
> > which can be interrupted at any time just like a user program. <
>
>Microkernal architecture allows us to close the question about
>multitasking logical parallelism at all. We can easely share the
>kernal between any multicore architecture. And there is no scheduler
>problem: latencies, preemtive algorithms, timesharing, priorities,
>etc. in MCA. <

Separating drivers from the kernel is the biggest advantage of micro kernel systems.

> > Micro-kernels are also popular in RTOS designs because an RTOS is
> > often used in small embedded systems. The modularity of the
> > micro-kernel design makes it easier to strip it down to the bare
> > essentials for that particular application, thereby saving EPROM and
> > RAM. <
>
>And makes it easy to share the tasks between the cores, i.e. to transform
>logical parallelism to physical one.
>
> > The disadvantage of a micro-kernel is that it runs more slowly than
> > the alternative (monolithic kernel) on typical hardware, and is more
> > difficult to write and debug (and so tends to incorporate potential
> > improvements more slowly). Micro-kernels are popular with
> > theoretical computer scientists but all of the popular general
> > purpose operating systems today use monolithic kernels (specialised
> > ones like QNX are the exception). <
>
>Yes. Parallelism is more dificult to deal with. <

QNX shows that handling of parallelism must not slow down the operation of a micro kernel OS.
It's just a design issue...

> > The criteria for deterministic behaviour in an RTOS is that an
> > interrupt is always serviced within a specific period of time, or
> > that a process is always run at a specific interval. However, using
> > an RTOS does not automatically make a complete system
> > "deterministic". That requires proper design of the overall
> > application, hardware, and system. The RTOS is just a tool in the
> > toolbox of the application designer. <
>
>Any interrupt demands a non-zero time. In multicore parallel system
>with microkernal OS it demands minimal time interval for handling. And it
>is localised, i.e. it depends on the local task structure only.
>
>As to the word "deterministic":
>determinism - the philosophical doctrine that all
>events including human actions and choices are fully determined by
>preceding events and states of affairs, and so that freedom of choice
>is illusory.
>
>So, personally can make the following statement only: any digital system
>is deterministic by definition. <

Sorry... every MS-Windows system is a digital system. Are they working deterministic in a timely manner?

Best Regards,
Armin Steinhoff

www.steinhoff-automation.com
 
M

Michael Griffin

In reply to Vladimir E. Zyubin: While you could calculate the worst case latency for an OS that wasn't intended to be an RTOS, it wouldn't be "easy" for a large OS. A typical modern monolithic OS kernel is large, complex, has many possible execution paths, and is continuously evolving. By the time you finished your analysis the OS itself would have changed significantly due to the normal development process, rendering your calculations moot. A microkernel is attractive in these applications because the kernel itself is small enough to make this sort of analysis practical.

People who produce "RT" versions of Linux concentrate on removing OS features that cause latency rather than trying to deal with the complexity of calculating the effects. They have had some good fortune recently in that new features intended to make the OS perform better in multi-processor systems or save power also happen to be features that make the OS more suitable as an RTOS. This means that the remaining RT features are now being merged into the mainstream kernel as they no longer conflict with normal use. This in turn means the regular and RTOS versions of Linux will eventually be made from the same code base by just changing some compiler settings.

An alternative to analysing all the possible paths through the OS kernel is to run the OS through a series of simulated loads and measure the response times. In this case, you can only say that the OS will "probably" respond within a certain time under certain conditions. It happens that I ran some simple tests along these lines a while ago with both Linux and MS-Windows and reported the results here.

Another interesting point about microkernels while we are on the subject is the reason why there is a good deal of non-RTOS academic work being done on them. Many people are interested in designing an OS kernel that is "provably correct". That is, the OS kernel can be proven to be without error by means of formal mathematical proofs. This may be possible for a small microkernel, but not possible on a practical basis for a large monolithic kernel. The effort required for the proof grows exponentially with size, meaning that for a large enough OS the proof could take decades or centuries to calculate.
 
V

Vladimir Zyubin

Hello Armin, I'm glad to see you.

Armin Steinhoff: The most important feature of an RTOS is producing results in a timely manner (meeting deadlines). There is no warranty that a MS-Windows OS can do that (CE excluded).<

That is impossible. Only an insane vendor can clame that in the product warranty... but all of them make looked-like statements in an
irresponsible form.

Vladimir Zyubin, previously: I see no difference between QNX and Windows. Microkernal architecture only. <

Armin Steinhoff: Windows drivers are part of the Microsoft OS kernel... QNX drivers are Resources Managers which are running in their own protected address space! That's the most important architectural difference between MS-Windows and QNX6 (and QNX4).<

Armin Steinhoff: There are also big differences in process/thread scheduling policies between MS-Windows and QNX4. (Partitioning of CPU time, for example...)<

Yes. It is the microkernel architecture I speak about. For multicore architecture, organisation of multitasking physical parallelism is mostly the same in both cases: unique address spaces, and lack of any smart scheduler algorithm. There is no needs to share CPU time because of large amount of CPUs.

Michael Griffin: Many people consider a micro-kernel to be a good basis for an RTOS because the small size of the kernel means it is easier to verify the length of the "locked" (uninterruptable) code sections (because there is less code to review and maintain). The rest of the OS processes are pushed out to modules with lower privilege levels which can be interrupted at any time just like a user program. <

Vladimir Zyubin, previously: Microkernal architecture allows us to close the question about multitasking logical parallelism at all. We can easely share the kernal between any multicore architecture. And there is no scheduler problem: latencies, preemtive algorithms, timesharing, priorities, etc. in MCA. <

Armin Steinhoff: Separating drivers from the kernel is the biggest advantage of micro kernel systems. <

yes, It is a great approach from reliability point of view.

Michael Griffin: Micro-kernels are also popular in RTOS designs because an RTOS is often used in small embedded systems. The modularity of the micro-kernel design makes it easier to strip it down to the bare essentials for that particular application, thereby saving EPROM and RAM. And makes it easy to share the tasks between the cores, i.e. to transform logical parallelism to physical one.
The disadvantage of a micro-kernel is that it runs more slowly than the alternative (monolithic kernel) on typical hardware, and is more difficult to write and debug (and so tends to incorporate potential improvements more slowly). Micro-kernels are popular with theoretical computer scientists but all of the popular general purpose operating systems today use monolithic kernels (specialised ones like QNX are the exception). <

Vladimir Zyubin, previously: Yes. Parallelism is more dificult to deal with. <

Armin Steinhoff: QNX shows that handling of parallelism must not slow down the operation of a micro kernel OS. It's just a design issue...<

I spoke about complexity of applied programming. As far as microkernel OSes, I think they are more suitable for a multicore platform.

Michael Griffin: The criteria for deterministic behaviour in an RTOS is that an interrupt is always serviced within a specific period of time, or that a process is always run at a specific interval. However, using an RTOS does not automatically make a complete system "deterministic". That requires proper design of the overall application, hardware, and system. The RTOS is just a tool in the toolbox of the application designer.
Any interrupt demands a non-zero time. In multicore parallel systemwith microkernal OS it demands minimal time interval for handling. And it is localised, i.e. it depends on the local task structure only.
As to the word "deterministic": determinism - the philosophical doctrine that all events including human actions and choices are fully determined by preceding events and states of affairs, and so that freedom of choice is illusory.
So, personally can make the following statement only: any digital system is deterministic by definition. <

Armin Steinhoff: Sorry... every MS-Windows system is a digital system. Are they working deterministic in a timely manner?

Yes, they are. By definition. Any digital system is deterministic. And I think, nobody will seriously speak about freedom of choice in
Windows. And large amount of control algorithms are implemented as a Windows tasks. And I can not imagine more "real time" things than
control algorithms.

--
Best regards,
zyubin
 
R
Hi all.......

in linux device driver, who will schedule the tasklet or workqueue, which are used to implement bottom halves?????

is scheduler will schedule these tasklets at a safer time????
 
There is a book on-line at the following address which gives an explanation of writing Linux device drivers.

http://www.xml.com/ldd/chapter/book/index.html

Note that this book is not the current edition. For the newest edition, you will need to buy it at the book store. This is a long and complex subject, which isn't suited to discussion in a forum like this one.
 
G

Ghulam Murtaza

RTOS (1)

Used to run computers embedded in machinery, robots, scientific instruments and Industrial systems. Typically, it has little user interaction capability, and no end-user utilities, since the system will be a "sealed box" when delivered for use

Examples: Wind River, QNX, Real-time Linux, Real-time Windows NT

RTOS (2)
An important part of an RTOS is managing the resources of the computer so that a particular operation executes in precisely the same amount of time every time it occurs In a complex machine, having a part move more quickly just because system resources are available may be just as catastrophic as having it not move at all because the system was busy
 
Could a standard OS be used as a "realtime system" ?

For example if you use a Linux without graphical user interface just as a server sitting in a rack with no direct user interaction.

If you would measure the CPU load when your complete automation is running + lets say you are doing a backup and a copy of a big file over ethernet at the same time. When you would find out that the CPU load is below 60% in that case wouldn't this mean "realtime" ?
 
There are different definitions for realtime. Most of the time when someone says RTOS they mean a system that has guaranteed preemption with known latencies. Normal linux doesn't have this. This is why RTLinux/RTAI/Xenomai are used in conjunction with the linux system to attain realtime performance.

There have been efforts to make native linux more RTOS capable such as the preempt_rt patches and Xenomai user space threads which can switch from Xenomai scheduler to linux scheduler (such as to write to disk) when you want to.

KEJR
 
> RTOS (1)
>
> Used to run computers embedded in machinery, robots, scientific instruments and Industrial systems. Typically, it has little user interaction capability, and no end-user utilities, since the system will be a "sealed box" when delivered for use. <

This is true for embedded real-time executives ... but not for complete real-time operating systems like e.g. QNX or PREEMPT_RT Linux

> Examples: Wind River, QNX , Real-time Linux, Real-time Windows NT

> RTOS (2)
> An important part of an RTOS is managing the resources of the computer <

This does every operating system.

> so that a particular operation executes in precisely the same amount of time every time it occurs. <

It must not execute in the same amount of time ... it must produce correct results at the right time ( the so called deadline)

> In a complex machine, having a part move more quickly just because system resources are available may be just as catastrophic as having it not move at all because the system was busy <

Not meeting a deadline is catastrophic for a real-time application.

Regards
Armin Steinhoff
 
> Could a standard OS be used as a "realtime system" ? <

That's not possible. A standard OS doesn't work event oriented with a short reaction time ... so it isn't useful for the most real-time applications. A RTOS provides only the base for real-time operation of a RT application.

> For example if you use a Linux without graphical user interface just as a server sitting in a rack with no direct user interaction. <

Use at best PREEMPT_RT Linux ...

> If you would measure the CPU load when your complete automation is running + lets say you are doing a backup and a copy of a big file over ethernet at the same time. When you would find out that the CPU load is below 60% in that case wouldn't this mean "realtime" ? <

A typical RTOS provides e.g. low latency for the processing of events and priority / deadline oriented scheduling of tasks.

Real-time operation means providing of correct computing results at the right time. That's all ... but in most cases hard to realize :)

Regards
Armin Steinhoff

http://www.steinhoff-automation.com
 
C

curt wuollet

Well, it depends on your definition of realtime. You can certainly use Linux with a few kernel options set for "soft" realtime and it's really quite good depending on the application. It will be "fast enough" for most applications. But with a standard OS, the CPU utilization doesn't really control whether your process could be swapped out, for example, if it's waiting on I/O. Or some other binding resource could slow you down. If you need hard realtime, you would use RTLinux and most of the issues go away. With a standard OS, you can be at 1% cpu utilization and some background process, garbage collection or cache operations will delay things. With the realtime options enabled in Linux these sorts of things get interrupted so your process can run and with RTLinux, your process is the highest priority and everything else runs when it can. But without any explicit realtime provisions, you can't really guarantee anything even if your process is the only user process running and the CPU utilization is low.

Regards
cww
 
> There are different definitions for realtime.

There is a different foggy understanding of real-time :)

> Most of the time when someone says RTOS they mean a system that has guaranteed preemption with known latencies. <

What also is needed is a real-time scheduler ... working event and/or deadline oriented. The CFS scheduler of standard Linux is able to do real-time scheduling!

A "RTOS" provides only important real-time features for an application which must operate in real-time.

That means a "RTOS" is an operation system which is able to support in most cases the real-time operation of such an application. A "RTOS" is only a part of a real-time system which consists out of hardware, application software and the operating system.

> Normal linux doesn't have this. <

Parts of the PREEMPT_RT patch are already in the meantime part of the standard Linux kernel ... and this is an ongoing process.

> This is why RTLinux/RTAI/Xenomai are used in conjunction with the linux system to attain realtime performance. <

Yes, these are the typical "two kernel" approaches. A better approach is the PREEMPT_RT patch with a single SMP ( multi core) kernel. The BKL (Big Kernel Lock) has been removed from the kernel version 2.6.37 ... this will lead to excellent real-time features with the PREEMPT_RT patch.

> There have been efforts to make native linux more RTOS capable such as the preempt_rt patches and Xenomai user space threads which can switch from Xenomai scheduler to linux scheduler (such as to write to disk) when you want to. <

Yes, and every "non real-time driver" of the standard Linux kernel is able to kill the real-time behavior of the second "real-time" kernel :)

Regards
Armin Steinhoff
 
Top