lkml.org 
[lkml]   [2000]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: An important fact about real time computing
Date
> 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.057 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site