Linux-kernel mailing list archive 2000-29,: Re: An important fact about real time computing

# Re: An important fact about real time computing

Rogier Wolff (R.E.Wolff@BitWizard.nl)
Thu, 20 Jul 2000 13:01:18 +0200 (MEST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Giuliano Pochini: "RE: DPT driver"
- Previous message: Manfred: "[PATCH] i386 tlb flush bug fix"

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/

- Next message: Giuliano Pochini: "RE: DPT driver"
- Previous message: Manfred: "[PATCH] i386 tlb flush bug fix"