> You seem to think "realtime" computing has a wishy-washy definition.
> Not so.
>
> One of the key points of a realtime system is that any latencies be
> bounded. That's something you'd have one hell of job claiming for a lot
> of OS/app combinations. Don't mistake "usually adequately fast" for
> "realtime".
There is no "bounded". You can make a histogram that shows how often
you will have failure. Maybe "one failure every 6 years" is what you
are willing to pay for. How about "1/1000 chance of failure in my life"?
You can not ensure that failure will never happen.
On the practical level, normal hardware tends to break. Disasters happen.
On the theoretical level, I believe quantum theory says that any computer
can produce absurd results.
In case you want to hear from someone who does real-time for a living,
you might have missed this post from Jeff Millar:
: On the subject of real-time...It's amazing how much FUD there is on the
: subject, probably because not too many people have a lot of experience.
: It's useless to discuss hard vs soft real time because the terms have
: no standard definition. Plus, there's lots of factors to consider,
: each of which falls on a continuum, IRQ latency, scheduling latency,
: priority inversion, IRQ overhead, scheduling overhead, etc. etc.
Note: "each of which falls on a continuum".
-
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/