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/