asterisk.ru

Смена tsc на hpet/acpi_pm.
Ладно, буду курить дальше.

для начала попробовать в asterisk.conf после убедится в отсутствии в SDP части INVITE от астериска строки

internal_timing

Не нужно ставить, он включен по-умолчанию.

http://www.asteriskdocs.org/en/3rd_Edit ... -file.html

INVITE от астериска

Инвайт летит со стороны внешнего шлюза, а не Астериска. Звонок-то входящий.

Здесь вообще чушню пишут, скопипастченную непойми откуда: http://forum.asterisk.ru/viewtopic.php?f=5&t=4822

The only functionality that requires internal timing is IAX2 trunking.

Бред же.
Module Description Use Count
res_timing_dahdi.so DAHDI Timing Interface 13

Пускаем входящий звонок с SIP-транка, смотрим ещё раз:
Module Description Use Count
res_timing_dahdi.so DAHDI Timing Interface 14


Смотрим доку по ссылке выше:
"Uses a timing source to synchronize audio that will be sent out to a channel in cases such as file playback or music on hold."
Ну это так, к слову.

На сегодня пляски с таймингами закончены, все ушли домой, хосты разгрузились, проблема тоже ушла.
Как я уже писал ранее, смена clocksource "на лету" ничего не дала, перезагружать сервер с активными звонками нет возможности...

Тайминг используется при музыке в ожидании и воспроизведении любых голосовых сообщений Астериска, это верно, а также в конференциях. Чтобы синхронизировать несколько звуковых источников.
Отдельно - используется в протоколе IAX2 (опционально) между пирами - не ваш случай, у вас SIP invite, поэтому цитировать

The only functionality that requires internal timing is IAX2 trunking.

нет смысла. При отсутствии телефонных карт таким синхро таймером является модуль dahdi dummy.
Если нагрузка упала и проблема исчезла, то это может быть связано вообще с общей производительностью вашего виртуализатора со всеми виртуалками - CPU, memory - cache/swap, I/O disk subsystem, etc.

ded писал(а):Тем что -649 ms clock drift и потому звук "подлагивает".
http://forum.asterisk.ru/viewtopic.php? ... 92&p=49211

А битность-то здесь причём? Не уловил смысла ни разу.

ded писал(а): Если нагрузка упала и проблема исчезла, то это может быть связано вообще с общей производительностью вашего виртуализатора со всеми виртуалками - CPU, memory - cache/swap, I/O disk subsystem, etc.

Я тоже считаю что это наиболее вероятно, ибо на самом сервере с Астериском ничего постороннего не запущено и характер работы не сильно меняется.
Однако виртуализатором рулят отдельные люди и доказать им что где-то что-то не так и Астериск плохо работает - это ещё надо уметь

ded писал(а): При отсутствии телефонных карт таким синхро таймером является модуль dahdi dummy.

Вот им я и пользовался, запуская dahdi_test. Факт - при икающем IVR точность теста падала (см. worst). В данное время ничего не лагает, и:

--- Results after 115 passes ---
Best: 100.000% -- Worst: 99.582% -- Average: 99.892509%

В общем, буду ловить причину глюков.

Если что, проблема разрешилась убиранием лишних CPU с виртуалки. Остался только 1 проц. Все работает, как часы.

Bespaleva писал(а):убиранием лишних CPU с виртуалки. Остался только 1 проц.

Один проц или одно ядро?
А в VmWare например ставится сколько сокетов по сколько ядер.
Т.е. 2 х 2 - два двухядерных проца, итого 4 ядра линух видит.

Виртуальных сокетов. Еще хорошо помогает выставить CPU -> Resource Allocation: Shares - High и зарезервировать частоту.
За сутки всего 2-3 "проседания" в dahdi_test, для офисной АТС более чем нормально.

Bespaleva писал(а):Виртуальных сокетов.

Ясно.

Bespaleva писал(а):Еще хорошо помогает выставить CPU -> Resource Allocation: Shares - High и зарезервировать частоту.

Ну это я применяю, в зависимости от нагрузки на АТС обычно 1000 - 2000 МГц резерва хватает...