What is real-time?
Posted Dec 13, 2007 14:47 UTC (Thu) by
dmag (subscriber, #17775)
Parent article:
Enterprise realtime and cooperative development
"Real-time" is ambiguous. Either your task is HARD real-time or SOFT real-time. Everyone wants to think their task is hard real-time, but most likely they're wrong.
Hard Real-time
- Hard real-time means "Your task FAILs if you are even a tiny bit late". Very few systems have this property.
- The only way to implement hard real-time involves actively wasting resources (CPU time, etc.) For example, lets say you have an IRQ that will take 3 ms. You can't just turn it off while doing your real-time task. You must turn it off 3 ms before your realtime task is due to start. (Otherwise, it may not be able to start on time.) Usually, the CPU is idle just before the task starts because all critical resources must be free when the task starts.
- Therefore, you may need a faster processor to do the same work you were doing before you added a (hard)-RTOS. Thruput always suffers in hard real-time (on the order of 20-30%).
- Hard real-time is difficult. You have to prove that anything that holds a critical resource has bounded latency. Very few parts of the kernel have proven bounded latency.
- If you don't have actual proof of bounded latency for your code, for your RTOS, and all critical external resources, then you're doing soft real-time.
Soft Real-time
- Soft real-time means that "being a little late is slightly worse, but being a lot late is a lot worse". Audio/video encoding/decoding always falls in this category. Nobody will notice the handful of dropped frames in a 2 hour movie. Even if there are 100's of dropped frames (missing one second of a boring scene) the uses can still be happy, and might not even notice.
- Most of the "useful" work is done in the name of soft real-time. Everyone likes lower latency, lower observed worst-cases, etc., as long as it doesn't affect thruput much.
- Because soft real-time is 'fuzzy', there is no way to "prove" that it works. For example, maybe on a hot day your disk drive does a lot of thermal recalibration and drops so many frames that it ruins the movie for you. Hard real-timers must take all resources into account.
- Soft real-time is subjective. Some people are happy using Windows for soft real-time projects. If your OS doesn't usually go out to lunch for 100's of ms at a time (or some other arbitrary number), then you can claim "It's soft real-time".
A good analogy of hard vs soft is the use of "formal proofs" in software development. There are a few people who do formal proofs for their code. This slows them down a lot, but makes their code less buggy. On the other hand, the vast majority of people write useful software without proofs. Their software is more buggy, but the extra speed of development and extra features are worth it.
(
Log in to post comments)
