# Realtime hardware/software versus PC software/hardware, how are these distinct and alike?

This question stems from a few answers and comments on a question I posted in signal processing found here.

I guess I am a little confused. Are there any concrete differences between realtime software/hardware and just a regular PC?

I would try to list what I think the differences are but the list I have come up with is ambiguous and short.

The only thing I think makes sense to separate the two ideas is that PC software can run part of its code part of the time, real-time runs all of its code each time. So a PC can load a program but not all programs and run just that program for however long it pleases, real-time is just a single program with a bunch of if-else, switch logic basically a huge abstract collection of relays (PLC) that gets ran through every time it is called.

Yes I realize this is a pretty poor description, so I ask is there any good concrete ways to separate these ideas?

• "Realtime" is about repeatable, predictable performance (timing, mostly). Some PC hardware is OK in this, other isn't. You can probably build something good enough with off-the-shelf parts selected with care, but it might not pass "certification" of any sort. Parts that are guaranteed to perform within certain parameters are sure to be quite a bit more expensive. – vonbrand May 16 '13 at 16:51

## 1 Answer

In general, the difference between "normal" and "real-time" is some sort of guarantee on the time it takes to complete job. In a normal system, usually you have no guarantees at all. Programs can get interrupted by other programs, the OS scheduler might not be completely fair, the processor does complicated things that alter the runtime between executions of the same code...

For most applications this does not matter.

Real-time systems are built such that one can guarantee that job X is always completed after at most Y seconds. This is important for example for the chip that decides when to deploy air bags--if that takes longer than expected, you're dead. To be able to give these guarantees you have to use special operating systems (or no operating system at all) that guarantees appropriate scheduling. It is also necessary to know a lot of details about the hardware you're using. Does your chip have a cache? What kind of replacement policy does it use? How many cycles does an addition take? Is that always the same number? What's the branch prediction algorithm? etc.

Many people confuse real-time systems with very powerful processors that can churn through data "in real time". But that's not (always) the case. The important thing is not how long it takes in absolute time, the important part is that it never takes longer than expected. There are trade-offs both in hard- and software between throughput (expected computation speed) and predictability (worst-case speed).

• Ok, so its not that they are distinct systems from each other. A real-time system could be loosely defined, say if I put read and write memory barriers in my code, run it all the smallest OS possible, no I/O interrupts, just gave it as much of the processor I can, then it could be considered real-time in the fact that I can specify execution sequence, and it can "churn" through the code/data? Moreover, real-time is just a specific set of specifications for a computer "machine" so that it can react to inputs and write outputs in "real-time"? – KDecker May 16 '13 at 16:37
• Let's not forget that the implemented algorithms are a factor, too. In "PC" practice, you aim for best average behaviour and don't care too much for precise bounds, whereas in real-time practice you want best worst-case behaviour, and you want to know upper bounds on it that are as precise as possible. In particular, it may be acceptable for an algorithm to be slower but know a sharp runtime bound (not in $O$-terms, mind, but in number of clock cycles). – Raphael May 17 '13 at 6:54