Realtime kernels can guarantee a certain response time to a process. For example the process has to read each 10ms the values from an control system. In realtime you can assure that no value is dropped.
If you don't operate some kind of manufactoring control system, you simple don't need it.
The overall system performance may be better if the kernel has not to guarantee every process a time slice in a period. (Better I/O utilization, lower process switch overhead etc etc)
To sum up: Realtime does not increase the throughput of a system.
Expanding on this answer, there's a general trade-off between throughput and latency (or responsiveness). Throughput is how much work you can do per unit time; latency is how long you wait before you can start new work.
Since there's overhead in switching from one task to another (you need to re-load the old task's state, flush caches, etc), throughput is maximised by switching task as infrequently as possible. On the other hand, latency is minimised by switching rapidly between tasks, so no individual task needs to wait a long time before it can run again. As such, the improved latency in the realtime kernel will come at the cost of decreased peak throughput.
Outside the throughput/latency trade-off there are others to consider; the realtime kernel isn't mainline (yet), so doesn't have as much testing, and the realtime kernel will consume more power (because it wakes the processor more aggressively).
The main issue with running a real-time kernel is that it poses a serious security issue. RT processes have the potential to completely take over a machine.
There are also other reasons not to run RT, among them:
Since Linux 2.6, the real-time stack has been part of the Linux kernel, having a kernel patched with a real-time stack is no longer necessary.
Preempt-RT is enabled in the default Ubuntu kernel configuration to achieve the lowest possible latency for audio and other applications, while keeping the user interface usable.
It may slow down your machine.
Further information and exploration of the issues here:
Realtime kernels can guarantee a certain response time to a process. For example the process has to read each 10ms the values from an control system. In realtime you can assure that no value is dropped.
If you don't operate some kind of manufactoring control system, you simple don't need it.
The overall system performance may be better if the kernel has not to guarantee every process a time slice in a period. (Better I/O utilization, lower process switch overhead etc etc)
To sum up: Realtime does not increase the throughput of a system.
Expanding on this answer, there's a general trade-off between throughput and latency (or responsiveness). Throughput is how much work you can do per unit time; latency is how long you wait before you can start new work.
Since there's overhead in switching from one task to another (you need to re-load the old task's state, flush caches, etc), throughput is maximised by switching task as infrequently as possible. On the other hand, latency is minimised by switching rapidly between tasks, so no individual task needs to wait a long time before it can run again. As such, the improved latency in the realtime kernel will come at the cost of decreased peak throughput.
Outside the throughput/latency trade-off there are others to consider; the realtime kernel isn't mainline (yet), so doesn't have as much testing, and the realtime kernel will consume more power (because it wakes the processor more aggressively).
The main issue with running a real-time kernel is that it poses a serious security issue. RT processes have the potential to completely take over a machine.
There are also other reasons not to run RT, among them:
Since Linux 2.6, the real-time stack has been part of the Linux kernel, having a kernel patched with a real-time stack is no longer necessary.
Preempt-RT is enabled in the default Ubuntu kernel configuration to achieve the lowest possible latency for audio and other applications, while keeping the user interface usable.
It may slow down your machine.
Further information and exploration of the issues here:
https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel
https://sevencapitalsins.wordpress.com/2007/08/10/low-latency-kernel-wtf