yodaiken writes:
> The distinction that makes something hard RT is
> purely and simply the ability to promise worst case timing. There
> is no "full set of features" that makes any sense outside of that.
> If your application dies because a timing deadline is missed, then the
> application has a hard realtime constraint. If the application can
> survive a couple of missed deadlines over some defined time period,
> then the application is soft realtime.
The application will fail, but a low non-zero failure rate will
be tolerated. The hard/soft distinction is useless. We seek
perfection, but excellence will be tolerated.
The heart monitor can fail once in 100 thousand years.
The nuclear power shutdown sequence can fail at the same rate,
especially considering the passive backup systems in place.
Telescope motor controllers can miss a star once a month,
and can strip gears or burn out a motor once in 15 years.
Surface-to-air missles could detonate far beyond their targets
on 1 out of 500 flights or even worse.
For the audio apps that started this thread, one might ask for
a long-term average of less than one failure per month.
With one failure every few days, the apps are barely usable.
With one failure every hour, you end up with a toy.
RT-Linux provides far more assurance than needed. Plain Linux 2.4
can run these audio apps, but the reliability would be horrible.
What is asked for is currently beyond what plain Linux can deliver,
but not so difficult that a few patches wouldn't solve the problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:12 EST