Ingo Molnar <[EMAIL PROTECTED]> writes: > * Jack O'Quin <[EMAIL PROTECTED]> wrote: > >> First, only SCHED_FIFO worked reliably in my tests. In Con's tests >> even that did not work. My system is probably better tuned for low >> latency than his. Until we can determine why there were so many >> xruns, it is premature to declare victory for either scheduler. >> Preferably, we should compare them on a well-tuned low-latency >> system running your Realtime Preemption kernel. > > i didnt declare victory - the full range of latency fixes is in the -RT > tree. Merging of relevant bits is an ongoing process - in 2.6.10 you've > already seen some early results, but it's by no means complete.
I didn't mean to insult you, Ingo. I have nothing but praise for what you've accomplished with 2.6.10. My tests yesterday demonstrated slightly better SCHED_FIFO performance with 2.6.10 than 2.4.19 with Andrew's low-latency patches. For a mainstream kernel that is a huge accomplishment, never before achieved. We should celebrate. I was just pointing out that saying nice(-20) works as well as SCHED_ISO, though true, doesn't mean much since neither of them (currently) work well enough to be useful. >> Second, the nice(-20) scheduler provides no clear way to support >> multiple realtime priorities. [...] > > why? You could use e.g. nice -20, -19 and -18. (see the patch below that > implements this.) Which of the the POSIX 1-99 range do you map into those three priorities? (I can't figure it out from the patch.) How does one go about deciding which priority differences "matter" and which do not? Why not honor the realtime programmer's choice of priorities? For good reasons, most audio developers prefer the POSIX realtime interfaces. They are far from perfect, but remain the only workable, portable solution available. That is why I like your rt_cpu_limit proposal so much better that this one. -- joq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
