asterisk.ru

Небольшой уход частоты есть, это показывает skew и clock drift. Причем в обоих направлениях.
Похоже виртуализация. Попробовать тестовый астер/freepbx поднять у себя в офисе и сделать звонок через него, а не через инфраструктуру в облаке. Сравнить статистику.

sasa писал(а):CLI>timing test

pbx*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

а должен быть dahdi timing

dahdi timing

Плохо знаете матчасть. Актуально ТОЛЬКО если есть реальное DAHDI HARDWARE.

this method of timing was previously the only means by which Asterisk could receive timing. It has the benefit of being efficient, and if a system is already going to use DAHDI hardware, then it makes good sense to use this timing source. If, however, there is no need for DAHDI other than as a timing source, this timing source may seem unattractive. For users who are upgrading from Asterisk 1.4 and are used to the ztdummy timing interface, res_timing_dahdi provides the interface to DAHDI via the dahdi kernel module.

https://wiki.asterisk.org/wiki/display/ ... Interfaces

Врятли это поможет ТС, точнее явно уведет в сторону. Вместо того, чтобы явно нагнуть хостера за хреновую VPS и экономию энергию в BIOS/гипервизоре (Power Options проца) и хреновый хостинг он будет подорожником лечить беременность..

форум мертвый
если даже синьеры не знают матчасти
изучите и потом приходите

Да ладно вам!

У нас на виртуалках
Using the 'pthread' timing module
и
Using the 'timerfd' timing module
все дают It has been 1000 milliseconds, and we got 50 timer ticks
без описываемых ТС проблем. При чём тут dahdi timing?

в варианте ТС когда других предположений нет, это вариант

на высоко нагруженных системах pthread/timerfd дают промашку с разбросом времени
что в итоге может сказываться на качестве

тайминг от dahdi всегда лучше чем они
даже если без железной платы

sasa, заканчиваем никчемный халивар не зная брода не суйся в воду.
DAHDI полезен только в одном - если есть реальное железо как внешний источник. Тогда будет отчетливо видно что система как то странно себя ведет иногда.
Всё остальное - бред чистой воды.

на высоко нагруженных системах pthread/timerfd дают промашку с разбросом времени

Опять не читали ничего, на сей раз RFC по RTP. Там же четко написано - асинхронная работа. В каждом соединении динамически выбирается мастер. В этом случае не может быть что оба и прямой и обратный канал имеют различия подобные как у ТС. Это не е1! Это просто практика..

ТС, кстити есть еще одно средство, в народе называется клин клином вышибают: если этот VPS не получает своего внимания хоста из-за протухания от бездействия интел-проца (и неверно рассчитанных гипервизором тиков от этого) можно идти от обратного:
попробуйте несколько ядер проца нагрузить под 100% чем-нибудь. Это разбудит проц от сохренения энергии и вырубит потуги этих придурков с хостинга.
Кстати это совет от самой VMWare на форуме HP..
У нас просто у клиента недавно такая хрень была, спасло только отрубание PowerSave в ESXi..

Если это как-то влияет то в статистике заметите именьшение дрифта частоты и skew.

Всем спасибо за советы, прошу прощения что резко отвалился от беседы:
В пятницу при попытке обновления вайршарка я обнаружил что дистриб потянул за собой афигалиард зависимостей т.к. ось старая. Сегодня переставил свежачок. Буду пробовать встроеный пакет свежей калюхи.

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

Косяк-то материализуется только у двух филиалов.

Возможно там накладывается еще и задержка или джиттер по трассе.
Тем не менее, источник основной проблемы не в этом - скорее всего именно в железе сервера виртуализации, точнее в его настройке и мозгах настройщиков..

Всех с Масленицей!!!