Messages in this thread | | | From | "Ingles, Raymond" <> | Subject | RE: An important fact about real time computing | Date | Thu, 20 Jul 2000 13:22:23 -0400 |
| |
> 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/
| |