David Balazic wrote:
>
> The first sentence my professor maid on the real time computing
> course was :
>
> "A common misconception : Real-time computing is fast computing."
>
...
> Processor speed (and the size/length of the deadline) is
> irrelevant. Even with a 10 GHz Pentium-X
> your audio will pop if the IDE driver disables interrupts
> long enough. Or if you are sorting a long list with an O(n^2)
> algorithm ( I don't know an actual example from kernel, but
> maybe some memory management code might do this ).
>
> ( and video _does_ have latency requirements, not microsecond
> but around 20 millisecond )
>
> Again , real time is making the dead-line, not
> making the deadline fast.
>
I agree totally, but what bugs me is that there already are assumptions
about makeable deadlines in the kernel. For example, we need to respond
to a SYN with a SYN-ACK within a certain period of time (2 minutes?) or
the network stack breaks. That means the network stack requires a
'real-time' operating system. Or how about responding to the change in
some device state. Some devices have requirements that the kernel must
be able to meet.
As one person pointed out a while back, the potential of hardware
failures make it impossible to *guarantee* making a deadline - ever. So
what we are talking about are probabilities. Thus, 'real-time' is some
arbitrary small probability of missing a deadline. (After all, a
nuclear bomb dropped on your computer will make it miss a 'real-time'
deadline :-).
Even ruling out the hardware failure, and moving into the theoretical
(provable???) world of the code itself, the kernel already has
'real-time' deadlines, that are acceptible because of the infinitessimal
probability of failure. (What is the probability of missing a 2 minute
deadline? About the probability of locking up the PC or causing a
Kernel Panic - very low).
These are the kind of deadlines the 'audio people' have, and they (we?)
are just trying to reduce that probability, *if possible*, of failure to
meet our deadlines. It just so happens that the probability function is
a function of the length of the deadline. The probability of missing a
2 minute deadline is *very* small, whereas the probability of missing a
1ms deadline is currently fairly large. We are simply trying to adjust
this 'probability function.' We are willing to accept a certain
probability of failure, just like the user of any real-time system, when
you factor in hardware failures.
To summarize, I agree that the 'audio people' have a real-time
requirement. I claim that the kernel already has real-time
requirements. I also claim that any real-time system is only a
probability curve of making the deadline, and that the 'audio people'
only want to shift this curve to make the deadlines they are looking for
fall into the probability of failure they find acceptible.
David Mansfield
david@ultramaster.com
-
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/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:12 EST