groovy wrote:Hmh, if a Bay Trail like Intel N2930 is "slow for integer work", why is there more integer work, when using the RT kernel than with the standard non-RT kernel?? Is the "task management" not the same, when the system environment just differs in the used kernel?
And what do you think is doing the "task management"? Exactly. In other words: the kernel is the most central part of a OS. It is the thing that makes multi-tasking possible, and it is actually the thing that implements it. The kernel decides when and if a task is run. It has the ultimate power. User-space processes can only ask nicely.
Realtime isn't about efficiency. It isn't even about lower latencies. It is about predictability. This means that in a realtime operating system an application gets the same slices of CPU time in a very regular spacing: you can therefore always calculate timing from CPU cycles of the program, at least up to a guaranteed precision. In other words: a realtime environment "promises" your program to run it very regularly and without waiting periods outside certain boundaries.
A modern multitasking operating system, like Linux, Windows or Mac OS, is no realtime system. That means that the kernel (sic!) can decide to make an application wait for a longer time when something 'more important' has come up, e.g. an IO operation. It also will usually lower an application's priority when it hogs much CPU time, so that background processes at least get a chance. If an application finds that it has nothing more to do, it can tell the kernel 'going to sleep now' and the kernel will immediately reschedule the allotted CPU cycles to other applications. This is called 'preemption'.
All these tricks improve efficiency and throughput. They come, however, at a price, and that is occasional latency. Usually things will be very snappy, but from time to time an application might even 'hang' for maybe 50 or 100ms. (Such long latencies are rather unusual, however.) The user will normally not notice this, so it is a good bargain. Now when you want to do audio processing with exceedingly low latencies, things get tricky. This is the reason you can configure buffer sizes in Pianoteq: there is a certain amount of 'jitter' in the scheduling, and the application has to compensate for it by buffering. This increases latency and decreases load. The smaller the buffer size is, the more often the application has to do IO and the more often the OS has to do switching, effectively increasing the load. And when buffers are too small, you get the telltale audio dropouts.
The Linux RT patches as found e.g. in Ubuntu first and foremost make the Linux kernel itself preemptible. That is, the kernel can actually decide to stop an operation and give control back to applications. This makes things more "even" in terms of timing, improving realtime behaviour (although the Linux kernel will probably never be able to fulfill 'hard' realtime constraints). Another part of the patch is called the low-latency patch which more or less chances the scheduling behaviour: it runs more often.
All the changes in RT kernels mean than the kernel switches more often between applications (and itself), and more evenly. This smoothes timing, making latency spikes rarer and smaller. However, it has a price: the efficiency of that kernel is... bad. Very bad. Which means: if you have lots of computing power to spare and are not IO-limited in what you want to do (and audio processing on a fast computer meets these criteria), you can drastically reduce the minimal latency, although you will pay the price in terms of decreased efficiency and thus increased CPU load.
On a slower system running only a single application however, the RT patch is therefore actually detrimental, as Mossy described. Your best bet in that scenario is: run a normal kernel. Maybe increase buffer size a bit. Live with slightly higher latency. Don't run anything in the background.
Last edited by kalessin (01-07-2014 15:18)
Pianoteq 6 Standard (Steinway D&B, Grotrian, Petrof, Steingraeber, Bechstein, Blüthner, K2, YC5, U4, Kremsegg 1&2, Karsten, Electric, Hohner)