Le 15/09/2010 00:09, Nivedita Singhvi a écrit :
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.
Hi Nivedita;
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.
I don't agree with that.
We are all OK to say that the application or the process to control
fixes the timing constraints to the overall HW/SW system.
If the application can NEVER miss an event or a deadline because it will
be catastrophic, we MUST use a hard RTOS.
If the application supports to miss (from time to time) an event or a
deadline without catastrophic consequence, we can use a soft RTOS (or a
hard RTOS if we want).
Not thinking hard nor soft realtime can have dramatic consequences.
Until now, PREEMPT-RT is a nice solution as soft RTOS and offers no
guaranty on an very big latency appeared in a particular case. Thinking
that PREEMPT-RT is a hard RTOS is false.
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.
You're right.
In case of possible HW failure, HW design has HW redundancies.
This discussion is very interesting but as I said in my first response,
it will be the troll for many years...
Cheers;
Patrice
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
--
Patrice Kadionik. F6KQH / F4CUQ
-----------
+----------------------------------------------------------------------+
+"Tout doit etre aussi simple que possible, pas seulement plus simple" +
+----------------------------------------------------------------------+
+ Patrice Kadionik http://www.enseirb-matmeca.fr/~kadionik +
+ IMS Laboratory http://www.ims-bordeaux.fr/ +
+ ENSEIRB-MATMECA http://www.enseirb-matmeca.fr +
+ PO BOX 99 fax : +33 5.56.37.20.23 +
+ 33402 TALENCE Cedex voice : +33 5.56.84.23.47 +
+ FRANCE mailto:patrice.kadionik@xxxxxxxxxxxxxxx +
+----------------------------------------------------------------------+
--
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
