System information

support. The next section (“Choosing a Processor” on page 644) offers some
general guidelines for choosing a CPU that will meet the needs of your system.
Other processes running concurrently on the system
Being Unix-like, Linux is designed to be able to multitask several different pro-
cesses. A problem arises when one of those processes (such as Asterisk) demands
a very high level of responsiveness from the system. By default, Linux will distribute
resources fairly among every application that requests them. If you install a system
with many different server applications, those applications will each be allowed
their fair use of the CPU. Since Asterisk requires frequent high-priority access to
the CPU, it does not get along well with other applications, and if Asterisk must
coexist with other apps, the system may require special optimization. This pri-
marily involves the assignment of priorities to various applications in the system
and, during installation, careful attention to which applications are installed as
services.
Kernel optimizations
A kernel optimized for the performance of one specific application is something
that very few Linux distributions offer by default, and thus it requires some
thought. At the very minimum—whichever distribution you choose—you should
download and compile on your platform a fresh copy of the Linux kernel (available
from http://www.kernel.org). You may also be able to acquire patches that will yield
performance improvements, but these are considered hacks to the officially sup-
ported kernels.
IRQ latency
Interrupt request (IRQ) latency is basically the delay between the moment a pe-
ripheral card (such as a telephone interface card) requests the CPU to stop what
it’s doing and the moment when the CPU actually responds and is ready to handle
the task. Asterisk’s peripherals (especially the DAHDI cards) have historically been
intolerant of IRQ latency, though there have been extensive improvements in
DAHDI to help improve these issues. This is not due to any problem with the cards,
but rather is part of the nature of how a software-based TDM engine has to work.
If we buffer the TDM data and send it on the bus as a larger packet, that may be
more efficient from a system perspective, but it will create a delay between the time
the audio is received on the card, and when it is delivered to the CPU. This makes
real-time processing of TDM data next to impossible. In the design of DAHDI, it
was decided that sending the data every 1 ms would create the best tradeoff, but a
side effect of this is that any card in the system that uses the DAHDI interface is
going to ask the system to process an interrupt every millisecond. This used to be
a factor on older motherboards, but it has largely ceased to be a cause for concern.
Server Hardware Selection | 643