lkml.org 
[lkml]   [2001]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-audio-dev] low-latency scheduling patch for 2.4.0
    Jay Ts wrote:
    >
    > > A patch against kernel 2.4.0 final which provides low-latency
    > > scheduling is at
    > >
    > > http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads
    > >
    > > Some notes:
    > >
    > > - Worst-case scheduling latency with *very* intense workloads is now
    > > 0.8 milliseconds on a 500MHz uniprocessor.
    >
    > Wow! That's super. Now about the only thing left is to get it included
    > in the standard kernel. Do you think Linus Torvalds is more likely
    > to accept these patches than Ingo's? I sure hope this one works out.

    Neither, I think.

    We can't apply some patch and say "there; it's low-latency".

    We (or "he") need to decide up-front that Linux is to become
    a low latency kernel. Then we need to decide the best way of
    doing that.

    Making the kernel internally preemptive is probably the best way of
    doing this. But it's a *big* task to which must beard-scratching must
    be put. It goes way beyond the preemptive-kernel patches which have
    thus far been proposed.

    I could propose a simple patch for 2.4 (say, the ten most-needed
    scheduling points). This would get us down to maybe 5-10 milliesconds
    under heavy load (10-20x improvement).

    That would probably be a great and sufficient improvement for
    the HA heartbeat monitoring apps, the database TP monitors,
    the QuakeIII players and, of course, people who are only
    interested in audio record and playback - I'd need advice
    from the audio experts for that.

    I hope that one or more of the desktop-oriented Linux distributors
    discover that hosing HTML out of gigE ports is not really the
    One True Appplication of Linux, and that they decide to offer
    a low-latency kernel for the other 99.99% of Linux users.

    > > This is one to
    > > three orders of magnitude better than BeOS, MacOS and the Windowses.
    >
    > ** salivates **
    >
    > > - Low latency will probably only be achieved when using the ext2 and
    > > NFS filesystems.
    >
    > Well it's extremely nice to see NFS included at least. I was really
    > worried about that one. What about Samba? (Keeping in mind that
    > serious "professional" musicians will likely have their Linux systems
    > networked to a Windows box, at least until they have all the necessary
    > tools on Linux.

    I would expect the smbfs client code to be OK. Will test - thanks.

    > > - If you care about latency, be *very* cautious about upgrading to
    > > XFree86 4.x. I'll cover this issue in a separate email, copied
    > > to the XFree team.
    >
    > Did that email pass by me unnoticed? What's the prob with XF86 4.0?

    I haven't gathered the energy to send it.

    The basic problem with many video cards is this:

    Video adapters have on-board command FIFOs. They also
    have a "FIFO has spare room" control bit.

    If you write to the FIFO when there is no spare room,
    the damned thing busies the PCI bus until there *is*
    room. This can be up to twenty *milliseconds*.

    This will screw up realtime operating systems,
    will cause network receive overruns, will screw
    up isochronous protocols such as USB and 1394
    and will of course screw up scheduling latency.

    In xfree3 it was OK - the drivers polled the "spare room"
    bit before writing. But in xfree4 the drivers are starting
    to take advantage of this misfeature. I am told that
    a significant number of people are backing out xfree4
    upgrades because of this. For audio.

    The manufacturers got caught out by the trade press
    in '98 and '99 and they added registry flags to their
    drivers to turn off this obnoxious behaviour.

    What needs to happen is for the xfree guys to add a
    control flag to XF86Config for this. I believe they
    have - it's called `PCIRetry'.

    I believe PCIRetry defaults to `off'. This is bad.
    It should default to `on'.

    You can read about this minor scandal at the following
    URLs:

    http://www.zefiro.com/vgakills.txt
    http://www.zdnet.com/pcmag/news/trends/t980619a.htm
    http://www.research.microsoft.com/~mbj/papers/tr-98-29.html

    So, we need to talk to the xfree team.

    Whoops! I accidentally Cc'ed them :-)

    -
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

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