Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I came across an application called LatencyMon, that apparently does latency monitoring.

I have always understood that the more of a load you put on the processor, the less responsive, or more latent, the system becomes. However, in the second section of the LatencyMon page, the first sentence says, "Windows is not a real-time operating system" (RTOS). That got me thinking. I mean, is this any different from any other operating system like Linux, Unix, or Mac OS X?

Are there any "real-time" operating systems? Or is it merely a marketing scheme to get you to buy their product?

EDIT:

Also, are there any examples of RTOS's out there?

share|improve this question
4  
QNX is real-time, for example. –  new123456 Mar 31 '12 at 1:54

3 Answers 3

up vote 17 down vote accepted

Wikipedia actually has a surprising wealth of info here.

A real-time operating system (RTOS) is an operating system (OS) intended to serve real-time application requests.

A key characteristic of an RTOS is the level of its consistency concerning the amount of time it takes to accept and complete an application's task; the variability is jitter. A hard real-time operating system has less jitter than a soft real-time operating system. The chief design goal is not high throughput, but rather a guarantee of a soft or hard performance category. An RTOS that can usually or generally meet a deadline is a soft real-time OS, but if it can meet a deadline deterministically it is a hard real-time OS.

An RTOS has an advanced algorithm for scheduling. Scheduler flexibility enables a wider, computer-system orchestration of process priorities, but a real-time OS is more frequently dedicated to a narrow set of applications. Key factors in a real-time OS are minimal interrupt latency and minimal thread switching latency; a real-time OS is valued more for how quickly or how predictably it can respond than for the amount of work it can perform in a given period of time.

This is something that very few operating systems actually do, because for a lot of workloads it's simply less efficient. None of the major consumer operating systems are now (or to my knowledge have ever been) real-time. Unfortunately, it does mean that sometimes things in a non-real-time environment do have to sit around waiting on other things. This only becomes a problem when something's not yielding in a reasonable amount of time, generally.

Currently the best known, most widely deployed, real-time operating systems are:

LynxOS
OSE
QNX
RTLinux
VxWorks
Windows CE

See the list of real-time operating systems for a comprehensive list.

share|improve this answer
5  
Real-time OSs are normally used in very dedicated roles such as extremely precise control systems where a decision/calculation/etc must be completed in a very exacting timeframe. –  Lamar B Mar 30 '12 at 21:04
    
Are there any examples of RTOS's? Updating the question to this respect. –  hydroparadise Mar 30 '12 at 21:11
    
    
What @ta.speot.is said - there's some in the article already linked. I'll edit some in, though. –  Shinrai Mar 30 '12 at 21:17
    
I didn't make to the bottom of the Wiki page... Sorry bout that :/ –  hydroparadise Mar 30 '12 at 21:26

Real Time operating systems are often used for embedded systems, where they might be responsible for something like guidance or system monitoring. The key thing to remember about a real time system (and what differentiates it from a non real-time system) is that in a real time system, if an answer is late, it's wrong. You can easily see how this works by thinking about adding up a series of figures in Excel (where if the operation is delayed, there's no real impact) versus applying a brake in a car (where a delay could be catastrophic).

share|improve this answer

Basically, a RTOS can guarantee it can service an IRQ (interrupt request) in a specific (usually low) timeframe. Standard operating systems do not have such a guarantee.

In most modern systems, most devices can generate an IRQ. This causes the CPU to stop (i.e. be interrupted of) what it's doing and run an interrupt service program. The idea is that this service program does whatever the device needs, i.e. gets data off of the device and into RAM, tells the device what to do next, etc.

On x86, since it has only 1 IRQ line on the CPU, when it receives an interrupt, further interrupts are automatically disabled (except for NMI, RESET, and SMI) until the CPU acknowledges the interrupt source and reenables them. So good device drivers under standard i386/amd64 Windows will do minimal processing in this state, just enough so that it's OK to reenable interrupts, and then defer complete processing of the interrupt until later (because the system can technically only service 1 interrupt per CPU core at a time). I'm not sure but I believe Linux does the same. Nonetheless, there is no hard guarantee made of the time that the interrupt will be serviced under.

For most PC devices, such as disks, keyboards, NICs, if there is a slight delay servicing their IRQ, nothing bad will happen other than a loss in performance. This can be more of a problem for devices such as audio and video input, where the device doesn't buffer anything and the PC really needs to keep up with the incoming stream of data.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.