Эхоподавление

Эхоподавление

Эхоподавление может потребоваться при любом вызове, в котором задействован интерфейс коммутируемой телефонной сети общего пользования (Public Switched Telephone Network, PSTN). Поскольку эхоподавление является математической функцией, чем больше системе приходится его выполнять, тем выше будет нагрузка на ЦП[13]. Не пугайтесь. Эхоподавление - это еще одна тема для главы 8. Логика разработки сценариев диалплана

Передача Asterisk управления вызовами внешней программе всегда ведет к снижению производительности. Логика максимально должна быть реализована внутри диалплана. Если используются внешние сценарии, основными критериями при их создании должны быть производительность и эффективность.

Как именно эти факторы влияют на производительность, сказать наверняка сложно. Эффект от каждого из них описан в общем, но точного количественного выражения еще нет. Отчасти это объясняется тем, что воздействие каждого компонента системы зависит от множества величин, таких как тактовая частота ЦП, набор микросхем системной платы и общее качество, общий информационный трафик системы, оптимизации ядра Linux, сетевой трафик, количество и тип интерфейсов PSTN и трафик PSTN, не говоря уже о сервисах, не относящихся к Asterisk, которые выполняются системой параллельно. Рассмотрим влияние некоторых ключевых факторов: Кодеки и перекодировка

Попросту говоря, кодек (сокращение от кодер/декодер, или алгоритм уплотнения/разуплотнения данных) - это набор математических правил, который определяет, как будет выполняться оцифровка аналогового сигнала. Кодеки различаются, главным образом, предлагаемыми ими уровнями сжатия и качеством воспроизведения звука. Вообще говоря, чем большая степень сжатия требуется, тем больше ЦОС должно быть выполнено при кодировании или декодировании сигнала. Следовательно, кодеки без сжатия являются менее тяжелыми для ЦП (но требуют более широкой полосы пропускания сети). Выбор кодека должен быть компромиссом между пропускной способностью и загруженностью процессора. Центральный процессор (и модуль обработки операций с плавающей точкой)

ЦП состоит из нескольких компонентов, один из них - модуль обработки операций с плавающей точкой (Floating Point Unit, FPU). От производительности ЦП в сочетании с эффективностью блока FPU во многом зависит, какое количество одновременных соединений сможет эффективно поддерживать система. В следующем разделе («Выбор процессора») даются некоторые общие рекомендации по выбору ЦП соответственно нуждам конкретной системы. Другие процессы, параллельно выполняющиеся в системе

Linux подобна операционной системе UNIX, то есть является многозадачной системой, которая может выполнять несколько разных процессов одновременно. Проблема возникает, когда один из этих процессов (такой, как Asterisk) требует от системы очень высокой быстроты реагирования. По умолчанию Linux распределяет все ресурсы между приложениями, запрашивающими их, поровну. Если установлена система, включающая множество разных серверных приложений, каждое из них получит свою равную долю времени ЦП. Поскольку системе Asterisk необходим частый высокоприоритетный доступ к ЦП, для обеспечения ее сосуществования с другими приложениями система требует специальной оптимизации. Главным образом, подразумевается назначение приоритетов различным приложениям в системе и внимательное отношение к тому, какие сервисы устанавливаются.

Оптимизации ядра

Очень немногие дистрибутивы Linux предлагают по умолчанию ядро, оптимизированное для выполнения одного конкретного приложения, поэтому здесь необходимо слегка потрудиться. Какой бы дистрибутив ни был выбран, как минимум, придется скачать и скомпилировать на своей платформе свежую версию ядра Linux (которую можно найти по адресу http://www.kernel.org). Также можно найти патчи, которые обеспечат повышение производительности, но считаются неофициальными дополнениями к официально поддерживаемому ядру.

Время ожидания запроса на прерывание

Время ожидания запроса на прерывание (Interrupt request, IRQ) - это, по сути, задержка между моментом, когда периферийная плата (такая, как интерфейсная плата для телефонии) запрашивает ЦП остановить выполняемый процесс, и моментом, когда ЦП фактически отреагирует и будет готов обрабатывать задачу. Периферийные устройства Asterisk (особенно платы Zaptel) чрезвычайно требовательны ко времени ожидания IRQ. Причиной этому является не столько несовершенство плат, сколько принцип работы программного механизма временного уплотнения (TDM). Если мы буферизируем данные мультиплексора с временным уплотнением (TDM) и посылаем их на шину большим пакетом, это может быть более эффективным для системы, но обусловит задержку между моментом поступления аудиоданных на плату и доставкой их в ЦП. Это делает обработку данных TDM в масштабе реального времени практически невозможной. При проектировании Zaptel было принято, что отправка данных каждую 1 мс будет наилучшим компромиссным решением. Но в результате этого возникает побочный эффект - любая плата в системе, использующая интерфейс Zaptel, будет посылать в систему запрос на обработку прерывания каждую миллисекунду. Это было характерно для старых системных плат, но на данный момент уже почти перестало быть причиной для беспокойства.

В Linux всегда существовала проблема недостаточно быстрого обслуживания IRQ; это доставляло немало неприятностей разработчикам приложений для работы с аудиоданными, поэтому было создано несколько патчей для устранения этого недостатка. До сих пор нет единого мнения по поводу того, как включать эти патчи в ядро Linux.

Версия ядра

Asterisk официально поддерживается Linux версии 2.6.

Дистрибутив Linux

Дистрибутивов Linux много, и они разнообразны. В следующей главе мы обсудим проблему выбора дистрибутива Linux и то, как получить и установить и Linux, и Asterisk.