[lkml]   [2000]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: An important fact about real time computing
    David Balazic wrote:
    [Charset iso-8859-2 unsupported, filtering to ASCII...]
    > 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

    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... ;-)


    ** ** ** +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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.022 / U:230.876 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site