On Sun, 2007-10-14 at 12:48 +1000, porl sheean wrote: > i have actually had no end of trouble with ubuntustudio's (and now > ubuntu's) rt kernel. on an amd 6000+ system with 1gig ram and a > rme9652 soundcard i can't get reliable performance under 40 or so ms. > i even tried a vanilla kernel with the rt patches and had the same > trouble. the 64studio kernel worked fine, however. i'm currently > running at 5ms with it and have had no problems. this is even with > compiz fusion running and spinning the cube whilst playing back audio > from an 18 channel ardour project. what patches would cause such a > difference in performance? it isn't any options selected in 'make > menuconfig' - i loaded the 64studio's ones in and used them. still no > luck. i can only assume they have added more patches to do with > realtime performance than just the -rt patchset. >From what I gather ubuntustudio does not have an rt patched kernel (ie: patched with Ingo Molnar's realtime preemption patch). See observations below: > On 05/10/2007, thomas fisher <studio1@xxxxxxxxxxxxx> wrote: > I can supply no quantifications for the 32 bit 2.6.20-16-realtime > kernel in ubuntustudio other than no xruns have been observed. So, Ubuntu Studio has a kernel named realtime and they have observed no xruns (which is not your case, and not the case of other posters). Obviously it depends on how they test (hardware used, size of buffers, load on the machine under test, etc, etc) and there's no info on that post about that. > With the low latency kernel, xruns were observed. This implies they don't have the low latency patches applied and that, in their experience, the low latency patch was worse than the mainline kernel. If you have access to that kernel and you can check its build configuration you could grep for "PREEMPT" there and post the results. That will definitely tell us which options were used for building it (I suspect you will find just "PREEMPT_VOLUNTARY" there). In my experience, a mainline kernel will lead to xruns at low latencies (there's always an exception, of course). > Jack is the only app that has a -20 priority assigned. This implies they are not using SCHED_FIFO for running Jack. Apparently they are boosting the normal scheduler ring priority of Jack to -20. I have not experimented with this so I can't comment, except to say that everyone else (that I know of) is using SCHED_FIFO for running Jack - SCHED_FIFO is a higher priority scheduling method that can't be preempted by regular linux tasks, and while it is more risky as a badly designed application can hang the machine, the tradeoff is of course much better realtime performance. > The general workstation has been running without fault. The general > Debian / Ubuntu philosophy tends towards system stability. The realtime preemption patch is certainly less stable than the mainline kernel. But if you hardware runs it fine then it is more effective than mainline for achieving low latencies. -- Fernando > Tom > On Wednesday 03 October 2007 14:54:32 Fernando Lopez-Lezcano > wrote: > > On Wed, 2007-10-03 at 18:39 +0200, Frank Barknecht wrote: > > > Hallo, > > > > > > Matthias Schönborn hat gesagt: // Matthias Schönborn > wrote: > > > > I've just read that there's a difference between a > realtime-kernel and > > > > the low-latency-kernel provided by ubuntustudio. The > text in the german > > > > wiki on ubuntuusers.de said, that a realtime-kernel is > slightly better > > > > than the lowlatencykernel > ( http://wiki.ubuntuusers.de/Echtzeitkernel) - > > > > then why isn't it used in ubuntustudio? Or do I just mix > something up? > > > > > > I think, this wiki and maybe Ubuntustudio as well are > using a very > > > confusing terminology. > > > > > > Generally we have two kinds of kernels: The "vanilla" > kernel as > > > downloadable on kernel.org and the same kernel, but > patched with Ingo > > > Molnars RT-patches. The vanilla kernel, if configured > properly with > > > CONFIG_PREEMPT etc., already gives very good performance > in the low > > > latency department, enough for many users, even audio > users. I run one > > > of these. > > > > > > If you want more, then you can install a RT-patched > kernel, as is > > > provided in the linux-rt or linux-realtime packages. I > would call the > > > Ingo-Molnar-patched kernels Realtime-Kernels or > Low-Latency-Kernels. > > > > To further clarify (or confuse?) the issue, how "low > latency" the kernel > > is also depends on how you configure the kernel build > options before or > > after patching the kernel with Ingo's patch. For Ingo's > patch > > CONFIG_PREEMPT_RT is the best option in terms of latency but > there are > > others (CONFIG_PREEMPT_DESKTOP) that have a more > conservative approach > > but have (relatively speaking) higher latencies. So from > worst to best > > it would be something like: > > > > vanilla linuz + CONFIG_PREEMPT_NONE > > vanilla + CONFIG_PREEMPT_VOLUNTARY (used by the stock > Fedora kernel) > > vanilla + Ingo + CONFIG_PREEMPT_DESKTOP > > vanilla + Ingo + CONFIG_PREEMPT_RT (the one I use for > Planet CCRMA) > > > > (there's more granularity and options in the CONFIG_PREEMPT* > world but > > those are the ones that have the biggest impact as far as I > can > > remember) > > > > -- Fernando > > > > > > _______________________________________________ > > Linux-audio-user mailing list > > Linux-audio-user@xxxxxxxxxxxxxxxxxxxx > > > http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user > > > _______________________________________________ > Linux-audio-user mailing list > Linux-audio-user@xxxxxxxxxxxxxxxxxxxx > http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user > > _______________________________________________ > Linux-audio-user mailing list > Linux-audio-user@xxxxxxxxxxxxxxxxxxxx > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
