On 09/14/2010 10:38 AM, Gregory Haskins wrote:
No. Preempt rt it's not hard realtime.
This is not technically correct, but a common misconception. "Hard" vs "Soft" is a property of the _application_, not the os/platform itself, and it's based on how tolerant a given application is to missed deadlines.
"Hard" might be something like professional lossless audio, nuclear fuel-rod control, bomb-squad robotics, tele-medicine, etc, where the result of a missed deadline can have a serious/unacceptable negative impact (death, injury, SLA failure, etc). "Soft" might be telecom audio, high-frequency financial trading, etc, where misses (crappy audio quality, missed market opportunity, etc) are certainly not desired, but can technically be gracefully recovered from.
Any given platform (os and hardware combo) will have quantifiable performance/latency characteristics. If those characteristics exceed the requirements of your application, they it would generally work to run a "hard rt" application on that platform. If those characteristics<= your app, it probably will not meet your deadlines and therefore, a hard-rt app will fail.
Consider a fictious nuclear fuel rod control applications with requirements for a period of 20s, 500ms dutycycle, and with +- 1s jitter tolerance. Failure means reactor meltdown (this is hard-realtime) yet preempt-rt could certainly handle this. Heck, mainline linux could probably handle this. On the other hand, if anyone out there plans on doing fuel-rod control with software, please tell me so I can leave the continent. ;) But the point is, it's a hard-realtime application and it can be done even with preempt-rt. As you scale the applicaiton's requirements tighter and tighter, you will eventually find the limits of the platform to which it is no longer acceptable to run the application. On modern x86 desktops, these limits are in the order of 10us-150us.
The biggest challenge is _proving_ that a given platform actually possesses the desired performance characteristics. This is especially difficult with preempt-rt given that its based on a general purpose OS (linux) and a large one that that. Smaller, more RT specific os designs may be easier to prove every path has a maximum latency of "X". That said, there are very few products out there that could probably fit that description and most will have trouble proving beyond a shadow of doubt. In addition, the preempt-rt community is very responsive and treats every latency source as a "bug" to be fixed/improved.
So bottom line, if in doubt, I suggest you give preempt-rt a try. Linux in general boasts probably the broadest support profile of any platform out there. In addition, it's configuration is so finely grained that you can probably scale it back to a lean, mean, low-latency environment that will do what you need for perhaps all but the most stringent requirements. Where it wouldn't work, perhaps only dedicated hardware may help anyway.
I would go further and say people need to stop using the terms
"hard" and "soft". There isn't a binary yes/no answer to the real-time
requirements spectrum.
Applications can have varying response time requirements, from
microseconds to milliseconds to seconds to minutes as Greg says above.
Applications might have differing penalties for missed deadlines:
* nuclear reactor explodes
* I lose a trade and it costs me money
* I get a slightly different stock price quoted to me
* Justin Bieber sounds a little hoarse
If you're discussing Linux real-time, chances are your application
does not fall in the first one. Typically a very custom engineered
solution (hardware and software) is used for those who have rather
severe constraints.
The concept of "hard" as being mathematically/logically provable
in terms of specs and code examination is nice, but not very practical.
As other people have pointed out frequently, given any system, it's
possible to break its guaranteed deadlines (catastrophic hw failure,
etc.
The real-time Linux patchset (CONFIG_PREEMPT_RT) provides real-time
support in Linux. As you might expect from a general-purpose OS
providing real-time, it's providing increased determinism and better
control over your system (most significantly, your kernel tasks).
A more preemptive kernel and system with better time granularity
provides better real-time response compared to a standard kernel.
It's important to note that we're not providing guarantees. Latency
response time expectations are really based on empirical evidence,
testing with common hw/sw/configurations and debugging issues when
an issue is reported.
Seriously, the terms "hard" and "soft" really only serve to either
confuse or have little value (other than "custom" and "non-custom").
thanks,
Nivedita
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
