Messages in this thread | | | Subject | Re: real-time threaded IO with low latency (audio) | Date | Fri, 23 Jul 1999 08:52:53 -0400 | From | Paul Barton-Davis <> |
| |
[ 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/
| |