Messages in this thread | | | Subject | Definition of "realtime" | Date | Fri, 02 Oct 1998 11:22:34 +0200 | From | Olaf Titz <> |
| |
> >>> Are these tasks of yours really RT? Hard? Soft? Statistical? > >> They are fairly hard and are triggered from an interrupt. After > > "Fairly hard" means absolutely nothing at all. > You could say the same for "hard" and "soft", since I've seen several > different definitions. He could give a better answer if you asked a > better question.
A problem is "hard realtime" if time constraints are involved in the specification of the problem such that, when the time constraint is not met, the behaviour of the program is seen as _not correct_.
That's the definition I've learnt, or in other words, "A late answer is a wrong answer".
Note the last two words. The definition doesn't deal with possible consequences from wrong behaviour, it just states that the behaviour is wrong, just like a numerical bug in a number crunching program is a bug regardless of whether the result is off by 1 or 1E20. (Yes I'm aware that the specification of numerical problems includes a definition of "off".)
An example cited here is the Windoze printer which needs all of the data for one line of pixels coming in in exactly the speed with which the drum moves (or at least I think this is the way those devices work). When the CPU delivers the data late, the page has moved away and the result, i.e. printed page, is _not correct_, regardless of whether it comes out distorted, blank or the printer jams and needs the big switch.
CD-ROM burners are another obvious hard realtime problem. Like many hard realtime problems, it involves hardware which can itself have problematic realtime behaviour, an example being hard disks which need periodic recalibration. For CD burning or video recording, you need disks which don't do this, call them "realtime disks" if you want.
> It's all statistical. There is a cost of failure (annoyance, money > lost, billions die gruesome deaths, your mom dies a gruesome death...) > which determines the amount you are willing to pay for a solution. > Solutions vary in cost and in risk of failure.
The cost of a misprinted page is trivial, and yet this is clearly defined a failure of the system ("system" involving printing machinery, interfaces, drivers, operating system, application software,...). Whether you are willing to tolerate system failure at a given statistical rate is another problem. I suspect most people who buy that kind of printers don't care at all about occasional misprints, but people who write the drivers for the printers should care nonetheless.
olaf
- 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/
| |