>>> A hard real time constraint is one that must be met or the
>>> program fails. It is hard as in solid and inflexible.
>>
>> Oh, like user-space Win-printer software. If the deadline is
>> not met, the printer will eject the paper with garbage on it.
>>
>>> A soft realtime constraint is one that the operating environment
>>> must make a best effort to meet.
>>>
>>>> You could lose money at an exponential rate, 2**n $ for every
>>>> microsecond past your deadline.
>>>
>>> A soft real time constraint, in spite of the high motivation.
>>
>> Ouch. By your definition, the distinction is worthless. I'd much
>> rather have a Win-printer fail than lose money at an exponential rate.
>
> I think the Win-printer software would more acurately fall into
> the third category, "Firm Real-Time".
>
> Under Hard RT, the program's value goes to negative infinity if a
> deadline is missed. (The cost of paper and ink is hardly negative
> infinity, so this definition doesn't quite seem apropriate.)
Then hard real-time does not exist, since "negative infinity"
would mean the destruction of Earth and an afterlife consisting of
eternal torment. You just classified _everything_ as "Firm Real-Time".
I'll accept "value function with discontinuity" though, or perhaps
"binary value function". (and forget about the "firm" catagory)
As far as the kernel goes, that distinction is totally useless.
(gee, it is OK to send signal 9 to a failed hard real-time task)
> These definitions imply NOTHING about the SCALE of the values,
> which is the problem you address by your preference; they only
> describe the SHAPE of the value function in time.
Fine, but then don't ask Mr. Gooch if he has hard or soft real-time
requirements. Instead ask him how much money (sleep, lost face...)
he would lose if Linux ever failed and compare that to how much money
(hacking time, another OS) he would pay to avoid the problem. This not
being a perfect world, there is no guarantee. Reliability has a cost,
often including extra hardware to allow for stuff that breaks.
The scale matters. The scale determines what level of reliability you
are willing to pay for. The reliability you demand is what matters
as far as the kernel goes. Being "soft" only makes it more difficult
to evaluate the cost tradeoffs.
-
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/