Among other considerations, when selecting the hardware for an Asterisk installation
you must bear in mind this critical question: how powerful must the system be? This
is not an easy question to answer, because the manner in which the system is to be used
will play a big role in the resources it will consume. There is no such thing as an Asterisk
performance-engineering matrix, so you will need to understand how Asterisk uses the
system in order to make intelligent decisions about what kinds of resources will be
required. You will need to consider several factors, including:
The maximum number of concurrent connections the system will be expected to support
Each connection will increase the workload on the system.
The percentage of traffic that will require processor-intensive DSP of compressed codecs
(such as G.729 and GSM)
The Digital Signal Processing (DSP) work that Asterisk performs in software can
have a staggering impact on the number of concurrent calls it will support. A system
that might happily handle 50 concurrent G.711 calls could be brought to its knees
by a request to conference together 10 G.729 compressed channels. We’ll talk more
about G.729, GSM, G.711, and many other codecs in
Whether conferencing will be provided, and what level of conferencing activity is expected
Will the system be used heavily? Conferencing requires the system to transcode
and mix each individual incoming audio stream into multiple outgoing streams.
Mixing multiple audio streams in near-real-time can place a significant load on the
CPU.
Echo cancellation
Echo cancellation may be required on any call where a Public Switched Telephone
Network (PSTN) interface is involved. Since echo cancellation is a mathematical
function, the more of it the system has to perform, the higher the load on the CPU
will be. † Do not fear. Echo cancellation is another topic for Chapter 8.
Dialplan scripting logic
Whenever Asterisk has to pass call control to an external program, there is a per-
formance penalty. As much logic as possible should be built into the dialplan. If
external scripts are used, they should be designed with performance and efficiency
as critical considerations.
As for the exact performance impact of these factors, it’s difficult to know for sure. The
effect of each is known in general terms, but an accurate performance calculator has
not yet been successfully defined. This is partly because the effect of each component
of the system is dependent on numerous variables, such as CPU power, motherboard
chipset and overall quality, total traffic load on the system, Linux kernel optimizations,
network traffic, number and type of PSTN interfaces, and PSTN traffic—not to mention
any non-Asterisk services the system is performing concurrently. Let’s take a look atthe effects of several key factors:
Codecs and transcoding
Simply put, a codec (short for coder/decoder, or compression/decompression) is a
set of mathematical rules that define how an analog waveform will be digitized.
The differences between the various codecs are due in large part to the levels of
compression and quality that they offer. Generally speaking, the more compression
that’s required, the more work the DSP must do to code or decode the signal.
Uncompressed codecs, therefore, put far less strain on the CPU (but require more
network bandwidth). Codec selection must strike a balance between bandwidth
and processor usage.
Central processing unit (and Floating Point Unit)
A CPU is comprised of several components, one of which is the floating point unit
(FPU). The speed of the CPU, coupled with the efficiency of its FPU, will play a
significant role in the number of concurrent connections a system can effectively
support. The next section (“Choosing a Processor) 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 optimizations. 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—a fresh copy
of the Linux kernel (available from http://www.kernel.org) should be downloaded
and compiled on your platform. You may also be able to acquire patches that will
yield performance improvements, but these are considered hacks to the officially
supported kernel.
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 Zaptel cards) are extremely intoler-
ant of IRQ latency. This is not due to any problem with the cards so much as partof 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 Zaptel, it was decided
that sending the data every 1 ms would create the best trade-off, but a side effect
of this is that any card in the system that uses the Zaptel 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.
Linux has historically had problems with its ability to service IRQs
quickly; this problem has caused enough trouble for audio devel-
opers that several patches have been created to address this short-
coming. So far, there has been some mild controversy over how to
incorporate these patches into the Linux kernel.
Kernel version
Asterisk is officially supported on Linux Version 2.6.
Linux distribution
Linux distributions are many and varied. In the next chapter, we will discuss the
challenge of selecting a Linux distribution, and how to obtain and install both
Linux and Asterisk.