On Wed, 21 Dec 2005 15:06:18 -0600 Josh Lawrence <hardbop200@xxxxxxxxx> wrote: > I see, this is exactly the kind of thing I was looking for, and now > that I think about it, it makes total sense. Let me see if I > understand it: rtlimits allows a normal user to preempt, but you must > enable the preemption option in the kernel config in the first place > for it to do any good. Is that it? rtlimits/realtime_lsm allows a normal user to run tasks with SCHED_FIFO scheduling. This is a scheduling class that gets the CPU before any normal SCHED_OTHER task and is statically prioritized (as opposed to SCHED_OTHER where you can set a "nice" value, but the real priority is determined based on some heuristics depending on resource usage of the task). See i.e. http://ccrma.stanford.edu/planetccrma/man/man2/sched_setscheduler.2.html for a more detailed description. > > It is quite ok for most uses, especially when not going for ultra low > > latencies (like 8 or 16 frames). Make sure you use the "(X) Preemptible > > Kernel (Low-Latency Desktop)" setting though when building a vanilla > > kernel (or make sure your distro builds it this way if you use a distro > > provided kernel; check i.e. /proc/config.gz and/or write a mail to the > > appropriate ML/maintainer). > > Again, this is apparently the part that must be "enabled" to see the > full benefits of using rtlimits, correct? Once I've enabled this > option (Preemptible Kernel), do I then have what you are referring to > as a -rt kernel? Not quite. In a vanilla 2.6.14 kernel you can select from the following preemption models: ( ) No Forced Preemption (Server) ( ) Voluntary Kernel Preemption (Desktop) (X) Preemptible Kernel (Low-Latency Desktop) So, if you use a vanilla kernel make sure the last entry is activated (i.e. via make menuconfig) In a kernel patched with the realtime preemption patches (-rt) you get an additional entry: (X) Complete Preemption (Real-Time) This also introduces the prioritization of irq handler threads i talked about. But before even considering using a -rt kernel, first test a normal 2.6.14 vanilla kernel with "Preemptible Kernel (Low-Latency Desktop)" enabled and of course, [*] Preempt The Big Kernel Lock too. > I don't think that I am the type of user that needs that kind of low > latency, I just need enough to do my basic home recordings. > > I think, in light of this, I might install DeMudi on my seperate > partition; it might avoid all of this kernel business very easily. I > still hate that I don't know how to do things myself, so any further > comment is welcome. Yeah, just for some hd recording and no i.e. using your computer as live effects rack, i.e. for guitar or for softsynths, large periodsizes are usually fine (large = around 1024 frames). For softsynths i'd recommend a periodsize smaller than or equal to 128 frames. Dunno how well that works on vanilla kernels. Especially if you need _rock solid_ performance (i.e. no dropouts at all). Flo -- Palimm Palimm! http://tapas.affenbande.org
