Интерпретация и использование Звездочки, “синхронизирующей тест” команда
Еще некоторая информация (как @Zoredache спрашивает) о том, что Вы на самом деле сделали, собирается помочь нам.
Нет никакой встроенной функциональности для удаления локальных групп и пользователей от клиентов. Если бы Вы говорите об удалении затем, необходимо было бы использовать сценарий, чтобы сделать это. Если Вы сделали, и Вы действительно удаляли записи из локального SAM на каждом ПК, то их не стало.
Я получаю больше чувства, что Вы использовали "Ограниченные Группы" на, по крайней мере, Вашу группу "Администраторов", и заставили "Администраторов DOMAIN\Domain" быть удаленными из локальной группы "Администраторов" на каждом из клиентов. К счастью, для Вас, можно использовать Групповую политику для "отменения" этого изменения, также. Найдите "Ограниченные Группы" политика, с которой Вы навредили локальной группе "Администраторов", и добавьте "Администраторов DOMAIN\Domain" назад к группе. Перезагрузите затронутый клиент, чтобы вынудить это повторно применить Групповую политику (так как Вы не можете только выполнить "gpupdate" удаленно, потому что Вы "заблокировали ключи в автомобиле"), и Вы будете видеть, что изменение происходит. Ваши другие клиенты возьмут изменение во время периодического обновления Групповой политики.
Если Вы повредили членства групп локальной защиты с "Ограниченными Группами" политика нет очень, я могу сказать, что Вы, кроме "получаете к нажатию" на. Removing the "Ограниченные Группы" политика, не заставит группы возвращаться к своему исходному содержанию. Это будет ручным процессом. Надо надеяться, Вы не навредили многим и, если Вы сделали, Вы смогли писать сценарий вторичного заселения.
Если вы ищете канонический источник информации обо всем, что связано с 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). Мы добились хороших результатов на нескольких АТС, некоторые из которых имели довольно высокую нагрузку (хотя и не такую высокую, как наш основной сервер - они обычно развертываются на сайтах клиентов).
Я понимаю, что это старый вопрос, но для всех, кто приходит из google: насколько я понимаю, если на материнской плате встроен высокочастотный источник синхронизации (многие так и делают), и до тех пор, пока он включен в настройках BIOS, ядро Linux будет знать об этом, и таймерfd должен работать так же хорошо, как и все остальное.
У меня отличная производительность с таймером, использующим Asterisk на CentOS 6.5, внутри VMware ESXi 5.5, на аппаратном обеспечении версии 10 (с настройкой чувствительности к задержкам на High в конфигурации виртуальной машины), и на vmware-tools-esx-nox установленных RPM. Таким образом, это без "реального", физического HF-источника синхронизации. Раньше звездочка была ужасной на старых версиях vmware, но виртуализация в целом прошла долгий путь
.