Время очень важен для определенных типов приложений в Asterisk. Если DAHDI является источником синхронизации, dahdi_test Команда может использоваться для проверки синхронизации, предоставляемой модулем ядра DAHDI. Если dahdi_test возвращает только измерения выше 99,975%, источник синхронизации DAHDI обычно считается хорошим.
Начиная с Asterisk 1.6, стали доступны новые источники времени, такие как pthread и timerfd, которые полезны в системах, которые не используют или не могут использовать оборудование DAHDI для синхронизации, поскольку они представляют собой улучшение по сравнению с dahdi_dummy модуль. Очевидно, что если время DAHDI не используется, dahdi_test не будет полезно тестировать источник синхронизации; но точность любого источника синхронизации кажется измеряемой с помощью интерфейса командной строки Asterisk. timing test команда:
localhost*CLI> timing test
Attempting to test a timer with 50 ticks per second.
Using the 'timerfd' timing module for this test.
It has been 1000 milliseconds, and we got 50 timer ticks
Меня беспокоит то, что расчет времени 50 тиков кажется значительно менее стрессовым тестом, чем dahdi_test8192 отсчета за 8000 мсособенно потому, что почти каждая система, на которой я пробовал ее, виртуальная или другая, может с этим справиться.
я могу спросить timing test довести это до того, что я считать являются dahdi_testстандарты:
localhost*CLI> timing test 1024
Attempting to test a timer with 1024 ticks per second.
Using the 'timerfd' timing module for this test.
It has been 1000 milliseconds, and we got 1024 timer ticks
Это действительно немного сломается в зависимости от системы, которую я использую, обычно с уменьшением тиков таймера. Но я не уверен, полезно ли подчеркивать это до такого уровня.
Есть ли авторитетное руководство по использованию и интерпретации timing test команда, чтобы гарантировать, что данная система Asterisk имеет источник синхронизации, который будет хорошо работать?
Я понимаю, что это старый вопрос, но для всех, кто пришел из Google: насколько я понимаю, если ваша материнская плата имеет встроенный высокочастотный источник синхронизации (многие делают), и если он включен в BIOS настройки, ядро Linux будет знать об этом, и timerfd должен работать так же хорошо, как и все остальное.
У меня отличная производительность с timerfd с использованием Asterisk на CentOS 6.5, внутри VMware ESXi 5.5, аппаратной версии 10 (с высокой чувствительностью к задержке в конфигурации виртуальной машины) и установленными RPM vmware-tools-esx-nox. Итак, это без "настоящего" физического источника синхронизации ВЧ. Asterisk был ужасен в старых версиях vmware, но виртуализация в целом прошла долгий путь.
Если вы ищете канонический источник информации обо всем, что связано с Asterisk, то вики по адресу http://www.voip-info.org/ примерно так же близко, как и кажется, по моему опыту. У Digium также есть свои форумы, но это не обязательно кладезь информации, которую вы можете найти на voip-info.org.
Что касается команды проверки времени в командной строке Asterisk, я бы не стал называть ее значимым тестом для чего-то большего, кроме проверки того, что ваше устройство DAHDI работает. Если на карте есть неисправность, она может что-то показать, но на нашем отлично работающем коммутаторе Asterisk, который маршрутизирует около 8000 вызовов в день, запуск «теста времени» с любым значением более 1000 возвращает не более 1001 такта таймера (даже запросив 2048 тиков, например). Прослушивание текущего вызова при этом не приводит к ухудшению качества голоса, поэтому я бы не стал называть это каким-либо стресс-тестом.
По нашему опыту, любая рабочая карта Digium с аппаратным эхоподавлением справится с нагрузкой, но где Asterisk падает, так это тогда, когда он нагружается SIP-вызовами и регистрациями. Мы обнаружили, что многие версии Asterisk просто недостаточно стабильны для производственного использования, даже предположительно «выпускных» версий. Один из способов проверить это условие - использовать тестер нагрузки SIPp, подробности по настройке и установке можно найти здесь: http://www.loho.co.uk/blog/2011/08/sip-load-testing-with-sipp/.
Однако мы настоятельно рекомендуем либо использовать Debian-Stable и его двоичный пакет Asterisk, либо ту же версию, которую они используют (можно найти здесь: http://packages.debian.org/wheezy/asterisk). Мы добились хороших результатов на нескольких АТС, некоторые из которых имели довольно высокую нагрузку (хотя и не такую высокую, как наш основной сервер - обычно они развертываются на сайтах клиентов).