>This is something I've been complaining about for a long time and since >given up because kernel developers seem to be only interested about
kernel developers like ingo molnar? like andrew morton? like richard love? yes, the majority are focused on throughput, but you know what - that will actually help us too when it comes to streaming huge amounts of media data around. and besides, why shouldn't they be - they are working on their own problems and domains. in the meantime, a small but focused group has provided ways to avoid the behaviour that Kai reported. linus has indicated that he's happy with the goal of low latency, but he doesn't want "hacks" to fix it. despite the fact that it was "hacks" that created it (code that steals the CPU for too long), one can understand his point. there's no point fixing a mistake with another mistake. the preemptive kernel patch seems to have generated a great deal of interest in this area, and mr. love has been a very effective spokesperson for the work. its hard to tell right now which is better, andrew's lowish patches or the PE patch. also, AFAIK, the BSD family generally has much worse average latency characteristics than Linux does, even though its worst case scenarios are not quite as bad as the regular linux kernel. >No one has been willing to add device specific bandwidth limits / >requirements... I hate when some non-critical device causes dropouts. any device driver will always be able to create dropouts if its badly written. all it has to is to block interrupts for too long, and boom! there is absolutely *nothing* the kernel can do about it. this is true on every operating system, including RTLinux, QNX and other similar systems. you have to be able to trust device drivers, and in general, you can, but alas, there are some that are not worthy of it. --p
