> Stephen Williams writes:
> > acahalan@cs.uml.edu said:
>
> >> Does "hard" mean human life is involved? What about large sums of
> >> money? (and define "large" too if that is the case)
> >
> > 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.) Under Soft RT, the program's
value decreases the longer it takes after its deadline, eventually
assuming negative values; this is _precisely_ the category the banking
example above falls under. Under Firm RT, if the deadline is missed, the
program's value goes to zero (or some negative constant), but once that
deadline is missed the work slated for that deadline can be skipped. This
is the perfect example for the Win-printer software.
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.
> Better questions might be:
>
> 1. What is the desired response time?
> 2. What level of reliability will you pay for?
Slightly tangential: does anyone know anything about the design of
Cygnus's new embedded real-time kernel, eCos?
http://sourceware.cygnus.com/ecos/
Adam
-- You crucify all honesty \\Adam D. Bradley artdodge@cs.bu.edu No signs you see do you believe \\Boston University Computer Science And all your words just twist and turn\\ Grad Student and Linux Hacker Reviving just to crash and burn \\ <>< ---------> Why can't you listen as love screams everywhere? <--------
- 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/