The main differences are:
1. the application of the relevant RT kernel patch
2. the configuration of RT specific kernel options
The latter step requires reading up on what an RT kernel does differently from a vanilla kernel, and the configuration will depend on your application.
The value of this guide is fairly small, since you wouldn't typically use an RT kernel on a desktop, but on a dedicate server or embedded system. I'm still working on a cross-compiling guide for non-x86 architectures.
In addition, having an RT kernel is only the first step -- it needs to be used in the correct way to allow for prioritising processes/pre-emptive execution in an efficient way. An overview for a particular application is given here: http://wiki.linuxmusicians.com/doku.php?id=system_configuration
Briefly,
sudo apt-get install kernel-package fakeroot
wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.9.tar.bz2
wget http://kernel.org/pub/linux/kernel/projects/rt/3.2/patches-3.2.9-rt17.tar.bz2
tar -xvf linux-3.2.9.tar.bz2
cd linux-3.2.9/
bzcat ../patches-3.2.9-rt17.tar.bz2 |patch -p1
cat /boot/config-`uname -r` .config
make oldconfig
You get to answer a number of questions relating to real-time OS execution
1. No Forced Preemption (Server) (PREEMPT_NONE)
> 2. Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY)
3. Preemptible Kernel (Low-Latency Desktop) (PREEMPT__LL) (NEW)
4. Preemptible Kernel (Basic RT) (PREEMPT_RTB) (NEW)
5. Fully Preemptible Kernel (RT) (PREEMPT_RT_FULL) (NEW)
choice[1-5]: 4
[..]
Testing module to detect hardware-induced latencies (HWLAT_DETECTOR) [M/n/y/?] (NEW)
[..]
Launch the build process
fakeroot make-kpkg -j7 --initrd --revision=3.2.9 --append-to-version=rt kernel_image kernel_headers
where 7 is the number of cpu cores+1.
The deb-packages will be found in the folder above linux-3.2.9/ and can be installed using sudo pkg -i
.
> I've installed and run the kernel on a desktop -- it works and seems stable. I haven't tested it in terms of visible improvements in latency etc.
ReplyDeleteI dunno where that misconception comes from that a realtime kernel offers you latency improvements.
Essentially a realtime kernel guarantees applications to have their work done in a specific time frame (deadline). If that deadline is missed the system reacts in two ways: hard realtime: It gives an error and stops, soft realtime: It gives an error and continues; but after a number of missed deadlines it turns into a hard realtime system.
As I don't want to propagate misconceptions and I really am no expert on this, I've removed the latency comment.
DeleteCheers for clarifying this.
The author of fluidsynth used to answer this. Using a non-RT kernel, audio output buffer less than 20ms time starts getting buffer underrun (sound choppy). That means you need to set at least 20ms buffer (delay) to make it works.
Delete20ms is not an issue for most purposes (e.g. watching movie), but critical for a live performer (e.g. playing a 1/16 note for 120bpm song means 125ms per note, 20ms means the note is delayed for 16%!) which will lead the performer lost the beat.
http://ck.kolivas.org/patches/bfs/
ReplyDelete^^ this on the other hand.... (I'm plagiarizing your instructions to build 3.6.7 with BFS as we speak)