lkml.org 
[lkml]   [1999]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: lantency scheduling benchmarks of audio playing tasks during high disk I/O
    Date
    On Mon, 21 Jun 1999, Prashant Shenoy wrote:
    > QLinux schedulers provide rate based guarantees (i.e., can allocate
    > a particular fraction of the CPU bandwdith). We haven't niether changed
    > the scheduling granularity nor any other part of the kernel (e.g., locks).
    > So any problems with the standard kernel with respect to these features
    > will persist in QLinux. By providing rate based guarantees, QLinux
    > can prevent processes from interfering with one anotehr (e.g., a
    > compute intensive compilation won't affect a audio/video playback).
    > If you only have one application running, you'll probably not see
    > much difference from vanilla Linux.
    >
    > Prashant.

    I think the QLinux addition are very useful for realtime-multimedia content,
    but actually Linux has some limitations regarding locking,
    which makes impossible for example to play real-time generated audio with
    20ms latency.

    So unfortunately Linux + QLinux additions can not be called media-OS.

    a typical software synthesizer performs

    while(1)
    {
    read() from MIDI port (or serial port)
    Do computations to generate audio data
    write() to audio card ( small buffer <20ms)
    }

    to ensure that is works ok,
    the read() path from the MIDI port and the write() path to the /dev/dsp must
    be completely independent from any I/O kernel locking due to disk I/O.

    Only these changes will allow *STABLE* working realtime software synthesizers
    to run on Linux.

    Do you think that we will archieve this goal in not so distant future on Linux ?



    Do you know if the filesystem changes in linux 2.3.7 give better results than
    previous kernels ?
    I don't benchmarked it already, because I must get a spare disk for testing,
    to avoid potential corruption.
    When I will get some numbers I will post the results.

    To note that I benchmarked RT processes wich do only
    while(1)
    {
    waste_cpu_time
    usleep(3000);
    }

    and ran the disk I/O stresstests in the background,

    the results are disappointing:

    scheduling latencies of up to 150ms !!
    :-(

    seems that we must decouple the usleep() path from disk I/O too.



    I tested the 2.2.10-andrea-VM6 patch:
    this guy amazes me every time, he archieved the BEST and WORST results together:
    :-)

    the numbers in the table are max latencies, and (num of buffer overruns)

    this is a snip of the results of 2.2.10-andrea-VM6 kernel

    --------------+-------------+---------------+-------------+--------------+
    buffer size |proc (top) | disk write | disk copy | disk read |
    --------------+-------------+---------------+-------------+--------------+
    2x1024(11.6ms)| 15.1ms (307)| 9610.0ms (221)| 20.5ms ( 2)| 867.3ms ( 10)|
    3x1024(17.4ms)| 14.7ms ( 0)| 545.7ms (141)| 23.1ms ( 2)|1298.1ms ( 6)|
    4x1024(23.2ms)| 14.7ms ( 0)| 8862.4ms ( 95)| 18.1ms ( 0)| 228.6ms ( 12)|
    2x2048(23.2ms)| 20.4ms ( 0)|10255.4ms (120)| 16.9ms ( 0)| 172.2ms ( 9)|

    a standard 2.2.9 kernel gives me:

    --------------+-------------+-------------+-------------+-------------+
    buffer size |proc (top) | disk write | disk copy | disk read |
    --------------+-------------+-------------+-------------+-------------+
    2x1024(11.6ms)| 22.8ms (313)| 57.4ms ( 7)| 31.5ms ( 16)| 94.8ms ( 17)|
    3x1024(17.4ms)| 32.5ms ( 1)| 57.3ms ( 4)| 36.3ms ( 8)| 98.1ms ( 8)|
    4x1024(23.2ms)| 27.5ms ( 1)| 59.8ms ( 3)| 36.3ms ( 5)| 92.2ms ( 4)|
    2x2048(23.2ms)| 21.4ms ( 0)| 57.8ms ( 3)| 42.2ms ( 8)|102.5ms ( 5)|

    the andrea patch behaves very well during disk copy (cp file1 file2) operations,
    but on write only , or read only operations , it gives extremely high
    latencies.



    Alan Cox said:
    ----
    One day in the future the audio layer has to run without the kernel lock.
    However by then its likely to be ALSA. Getting the SMP locking right will
    be fun, I dont think its worth repeating the effort for dead code (ie OSS),
    nor will it help you anyway as your lock understanding isnt quite right
    ----


    I heard of some tests that show that a SGI is capable of playing audio with 5ms
    latency during high system-load.
    SGI kernel is monolithic,so I think Linux should allow <20ms latencies, on
    modern PC hardware, because actually the hardware *IS CAPABLE* of this.




    regards,
    Benno.



    >
    >
    > >
    > > Playing audio at highest priority seems not to require a special
    > > CPU scheduling policy, I think SCHED_FIFO or SCHED_RR fit well
    > > in this scenario.
    > >
    > > >From what I heard on the linux-kernel mailinglist, since there seems
    > > present some locking issues, during disk writing,
    > > the write() to /dev/dsp blocks while there is heavy disk I/O access,
    > > because the disk I/O routines hold the lock for too much time.
    > >
    > > Alan Cox suggested that the problem will go away when the sounddrivers
    > > will bypass this VFS locking.
    > >
    > > Unfortunately , I think QLinux cannot actually help to lower latencies.
    > >
    > > comments ?
    > >
    > > regards,
    > > Benno.
    > >



    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:52    [W:6.054 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site