lkml.org 
[lkml]   [1999]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: real-time threaded IO with low latency (audio)
    Date
    From
    [ all readers: please note trimmed Cc: lines ]

    In message <19990723055852.B8616@chelm.cs.nmt.edu>you write:
    >Try running
    > while(1){ write(1,buf,1024*1024*8); }
    >
    >while a SCHED_FIFO task is scheduled and see response time.
    >Linux is designed to optimize average case response time. And it should be.

    Sure, but that is not the point. The point is that if you have two
    processes, the first doing:

    while(1){ write(diskfile,buf,1024*1024*8); }

    and the second doing:

    while(1){ write(soundcard,buf,1024*1024*8); }

    then there is no reason for either of them to interfere with the other
    in any way other than needing a certain number of CPU cycles. We could
    add

    while(1){ write(serialport,buf,1024*1024*8); }

    and

    while(1){ write(framebuffer,buf,1024*1024*8); }

    and

    while(1){ write(parallelport,buf,1024*1024*8); }


    and this would remain true. As long as the write()'s typically cause a
    task to block, no write() to another i/o subsystem should be held up
    during the block. This is not currently true. I don't know enough
    about it to know how hard it would be to change, but anything that
    assumes that a-file-is-a-file-is-a-file below the write() system call
    interface is extremely unfriendly.

    >Everything is easy when the system is not doing anything.

    Actually, not *everything*. Try a <1ms audio latency. Even on a
    quiescent system, it won't work reliably.

    >Linux is not losing time locking/unlocking,

    Sorry Victor, but it *is*. There are well documented pathways through
    the disk subsystem alone that cause other tasks to have to wait
    because of lock acquisition/release. Even if we did preemption, it
    wouldn't help (unless someone has a way to do wait-free
    synchronization for real hardware devices :) The current internal
    kernel semantics require I/O completion notification at certain
    points.

    >BTW: I have never seen any serious performance numbers on BEOS. Do you have a
    >source?

    Only their own claims, which are too good to be made up :)

    --p

    -
    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:53    [W:4.101 / U:0.072 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site