> Thank you very much for the lecture, I'd want more and more :-) I am pleased you enjoyed it. Most people find my diatribes rather dry reading. > I'm happy to see, almost all of the mentioned (except for bdflush) > settings are more or less optimum. Excellent. I have another idea too. Since in a DAW scenario, it's STUPID to write-buffer really [you're spooling out lots of data which you're not going to need again anytime soon], I'd inspect the source to see if they open the file in O_DIRECT mode. This removes the buffer cache entirely from the equation and does not induce memory pressures upon the kernel. All "large spooling" I/Os (read or writes) should use O_DIRECT for realtime operations where the likelihood of re-reading the file is zero. When you're EDITING the file, fine. But when you're capturing, I suspect you will see more wins if you're using O_DIRECT. You can get big wins if you use O_DIRECT and use multiples of the physical memory pagesize. (Zero-copy write path - super-dee-duper efficient!) With O_DIRECT you will eliminate the CPU waste (and locking!!) of wasteful double-buffering, and reduce memory copying. If you set up the I/Os properly, you will in fact have a direct-to-disk DMA channel from the audio buffer. This is Perfection. > Let me recall my question: I think, there are more than one (lck1) > possible kernel patches with the aim of solving lowlat/preempt/... > issues. Which of them is the most appropriate for using with jack? All of them, though strictly speaking, the 64-bit jiffies patch does not boost performance. > I still use 2.4.26. Sounds fine. I'm assuming you're using the patches at: <http://www.plumlocosoft.com/kernel/> (Con Kolivas's patches now maintained by E Hustvedt). Apply all of the patches, and enable lowlatency. I use all of them except for 012-rl2dt.diff.bz2 on my main servers [non-audio/realtime oriented] to excellent effect. If you're really hardcore, you can live without 64-bit jiffies, however when HZ=1000 you'll wrap your jiffy counter in under 40 days. I think HZ=1000 will get you some gains in responsiveness for applications which do ANY select() multiplexing. Ignore the rants about "wastes due to more interrupts" - that's under 1% on modern CPUs. The AXP (Alpha) platform has been using HZ=1000 for years, and even a $50 Athlon XP 2000 leaves that for dead. On pre-Pentia CPUs, there's a reasonable argument to be made for HZ=100. Lord Sauron could have won, if only he had Quality, =MB= -- A focus on Quality.
