Explain Real Time OS's to me

[Shalmanese]

What makes them different to Windows or Linux?

 

[Nothinman]

There are real-time Linux patches in the form of RTLinux and low-latency/kernel preemption for "almost real-time" that can be applied to the mainstream kernel.

But the only real difference is process scheduling, a real-time process is guaranteed latency. Meaning there is no chance what so ever that it will be suspended for more than N ms.

 

[bsobel]

The last poster had it right. In Windows scheduling a high or system priority task still does not guarentee how long between time slices the scheduler will keep a specific thread frozen. To give an example, in the real time control world there are often situations where something needs to happen and something else needs to happen 10ms later. Not 9ms later or 11ms later, but 10ms EXACTLY later.

Windows/Linux are good at say normally being around 10ms (it's easy to make sure an event doesn't happen too soon, it's too late thats hard). So on those platforms if you sleep for 10ms you may wake up 10ms later, but it could be 11ms, 12ms, heck it could be 20ms. Realtime OS's offer the ability to do exactly what you need here, wake up 10ms later and perform an action.

Bill

 

[MustPost]

yup but its still good we have modern multi-tasking OSs.

 

[Nothinman]

yup but its still good we have modern multi-tasking OSs.

I'm not sure what you mean. An OS with a real-time scheduler is still multi-tasking, it's just that some of the tasks are guaranteed N amount of CPU time every M time interval, other "normal" tasks would be preempted to allow the real-time ones to get their guaranteed time.

 

[MustPost]

guess I had the wrong idea about Real Time OSs.

 

[kylef]

Real-time OS's have guaranteed execution time bounds on operations, with strict rules for interrupt handling and preemption that maintain those guarantees. I don't care what kind of hack you do to Linux to approximate this feat, you aren't going to succeed without some serious redesign of the kernel's process scheduler as well as most of the kernel's services.

There are in fact groups who research operating systems (normal as well as real-time) and actually perform measurements on the amount of time things like context switches take to complete. Linux used to have context switches in the 200 microsecond range, but I belive now it's up to 500 or 600 microseconds (depending heavily, of course, on the speed of the processor).

Berkeley's TinyOS, which is based on their "Mote" microcontroller boards, is a good example of a modern "microthreaded" real-time OS. Multiple different operations can be scheduled, but some tasks are GUARANTEED to be performed in a set amount of time. For example, servicing a radio transmitter or receiver one bit at a time without buffering requires that you examine the data pins at least once every certain amount of time or you risk losing bits, thereby corrupting the data flow.

 

[Nothinman]

I don't care what kind of hack you do to Linux to approximate this feat, you aren't going to succeed without some serious redesign of the kernel's process scheduler as well as most of the kernel's services.

That's what RTLinux is, it's not just a simple scheduler and locking patch like the preempt patch or low-latency ones being considered for the main kernel.

 

[heartsurgeon]

real time operating systems or programs must respond to inputs or system interrupts on the bus or cpu level in "real time" which implies that the processor speed and computational speed of the program used is sufficiently fast to respond to system interrupts as they occur. this typically means that inputs generate an system interrupt which triggers a branch or subroutine execution specific to that input, and a "response" is generated suficiently fast to in turn effect the process being monitored. examples would be fly-by-wire computer systems in aircraft, nuclear reactor control programs, etc.. the computer system must respond to a variety of data which typically comes in at random intervals from different input "devices" and computationally respond within a sufficiently short period of time, that the ongoing process (like flying the airplane) can be modified in a meaningful way.

 

[kylef]

<< That's what RTLinux is, it's not just a simple scheduler and locking patch >>



I haven't looked into it for a while... Maybe they've made significant progress since then. I'll take your word for it.

 

[0x7a69]

<< That's what RTLinux is, it's not just a simple scheduler and locking patch like the preempt patch or low-latency ones being considered for the main kernel. >>




and just to drag this out even farther, rtlinux simply runs linux as the idle process. in all other respects it is a completely separate (and true real time) os.