> From: yodaiken@fsmlabs.com [mailto:yodaiken@fsmlabs.com]
> On Thu, Jul 20, 2000 at 12:01:30PM +0200, David Balazic wrote:
> > Yes , but not every process has usec requirements.
> > Think house heating control etc ...
>
> So deterministic response is necessary for all hard RT, but the range
> of hard RT problems that can be solved is a function of worst case
> latencies.
I thought that I saved it, but I didn't. This came up a while ago
(I think under a subject of "definition of realtime") and a useful
distinction was made.
Soft real-time: If the deadline is missed, the value of the system
begins to decrease at some rate.
|
^ |
| ****************
v | *
a | *
l | *
u ----------------------------------*
e | time->
deadline
"Firm" real-time: If the deadline is missed, the value of the process
immediately becomes some finite value <= 0.
|
^ |
| ****************
v |
a |
l |
u ------------------------------------
e | time->
|
|**************
|
deadline
Hard real-time: If the deadline is missed, the systems' value becomes
negative infinity. In other words, the deadline *cannot* be missed.
|
^ |
| ****************
v |
a |
l |
u -------------------------------
e | time->
deadline
*
|
v
-Infinity
Example of soft real-time: streaming data to a CD-R buffer. It's not
ideal if the streaming interrupts, but not immediately catastrophic.
Eventually you're going to have a coaster if you don't catch up.
Example of "firm" real-time: Winprinters. The CPU more-or-less controls
the print head directly. If you can't get the data to the print
head fast enough, you might as well start over. You waste a sheet of
paper and some quantity of ink.
Example of hard real-time: Industrial robot safety system. If that
fails, you could kill someone.
Normal Linux is probably adequate for most soft real-time applications,
and probably a lot of firm real-time applications, and perhaps there's
room for some improvement here. I think I agree with Linus that if you
really have a hard real-time constraint, you're better off using a more
specialized system.
I'd say high-quality audio and video falls somewhere between soft and
firm, depending on application. Sometimes an occasional glitch in the
stream is acceptable, sometimes it isn't. However, I can't think of too
many cases where an audio skip would lead directly to someone's death.
Sincerely,
Ray Ingles (248) 377-7735 ray.ingles@fanucrobotics.com
"You are not entitled to an opinion. An opinion is what you have when
you don't have any facts. When you have the facts, you don't need an
opinion." - David Gerrold
-
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 : Sun Jul 23 2000 - 21:00:14 EST