Messages in this thread | | | Subject | Re: An important fact about real time computing | Date | Thu, 20 Jul 2000 13:01:18 +0200 (MEST) | From | (Rogier Wolff) |
| |
David Balazic wrote: [Charset iso-8859-2 unsupported, filtering to ASCII...] > yodaiken@fsmlabs.com wrote: > > > > On Wed, Jul 19, 2000 at 03:47:01PM -0400, David Mansfield wrote: > > > 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." > > > > This is the standard lecture, but don't take it too far. You can control > > a robot with deterministic latecnies under 50 usecs, but not with > > deterministic latencies of 10 minutes. > > Yes , but not every process has usec requirements. > Think house heating control etc ...
Yes. So what's all this about? The Linux kernel is not real-time. It cannot provide an upper limit on the time it will take to reschedule a process. However, controlling hte heat in a house, this is not a problem: the "cannot guarantee" happens on sub-second scale, and for the house-heating problem you don't need sub-second response. But the house is formally a real-time task. You cannot postpone all processing for a year, and do them all at once.
At the other end of the scale we have microsecond latencies that some control applications need. That is hard to achieve with a kernel that is not specifically engineered to have low latencies with the trade off that interactive and batch work is penalized.
However, in the middle we have the multimedia applications: playing audio and mpeg movies. That is something that performs best if there is a real-time rescheduling time on the order of 20ms. (i.e. it is acceptable if the mpeg movie playing thing misses one frame every now and then, but not more). Audio can be buffered, but more than 300ms of buffering becomes problematic (Audio feedback suffers if there is that large a queue).
We want to be reasonably good at playing audio and DVD movies, it is acceptable if the "deadline" is missed say once an hour (20ms, video) or once a day (100ms, audio). So it is not strictly real-time as no lives are lost when the deadline is missed, and it IS realtime as there are deadlines involved.
Wether or not it is called real-time is besides the point. It all depends on how you really define real-time.
The goal for Linux should be that Audio and Video playback works reasonably well.
It would be even better if Linux would "out of the box" support TIVO like applications: stream a few MB per second to the disk, stream a few MB per second FROM the disk, and maintain real-time sync.
I would find it highly acceptable if a general purpose OS like Linux would take a few seconds to note: "Hey this application is outputting xx MB per second, that's the disk-throughput that I'll have to achieve."
This would mean that a few "bumps and glitches" would happen the first few seconds, but that after that moment, Linux would be able to handle it without any glitches.
This last suggestions is however not quite 2.4 material...
(But hopefully, the standard multimedia performance thingies are... ;-)
Roger.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of * ****** prejudices acquired by age eighteen. -- Albert Einstein ********
- 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/
| |