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