Для проверки успешной блокировки роли главного-подчиненного требуется сочетание трех аспектов: проверка параметров конфигурации, мониторинг журнала-в режиме реального времени и нагрузочное тестирование. Это гарантирует, что роль не будет переключаться как при нормальных, так и при аномальных условиях сети:
I. Проверка параметров файла конфигурации
Проверьте файл конфигурации `/etc/linuxptp/ptp4l.conf` на обоих датчиках, чтобы убедиться, что параметры блокировки клавиш действуют:
Мастер-часы
`priority1` должно иметь низкое значение (например, 128).
`masterOnly 1`: это основной параметр для блокировки роли, указывающий, что узел вынужден стать главным тактовым генератором и отказывается участвовать в выборах BMCA, чтобы стать ведомым тактовым генератором.
Рабские часы
`priority1` должно иметь высокое значение (например, 130), гарантируя, что его приоритет ниже, чем у главных часов.
`masterOnly 0` (по умолчанию): позволяет синхронизироваться как ведомые часы.
II. Мониторинг состояния журналов-в режиме реального времени
После перезапуска службы ptp4l запустите `sudo ptp4l -i eth0 -m -q`, чтобы просмотреть журналы-в реальном времени:
Отображение фиксированной роли: В журнале главного устройства должно постоянно отображаться сообщение «Порт 1: ГЛАВНЫЙ».
В журнале ведомого устройства должно постоянно отображаться сообщение «Порт 1: SLAVE».
Никаких сигналов о выборе: журналы не должны содержать записей, указывающих на перевыборы BMCA,-таких как «изменены лучшие основные часы» или «выбраны лучшие основные часы».
Если появляется состояние НЕИСПРАВНОСТЬ, а затем быстро возвращается к исходной роли, механизм блокировки работает; если роли поменялись местами после восстановления, блокировка не удалась.
III. Стресс-тест на отключение и повторное подключение к сети (полная проверка)
Смоделируйте сценарий сбоя в сети, чтобы проверить надежность блокировки ролей:
Операция: Временно отсоедините сетевой кабель ведомых часов или отключите интерфейс сетевой карты, подождите примерно 10–20 секунд, а затем восстановите соединение.
Критерии вынесения решения:
Успешная блокировка: главные часы остаются в состоянии MASTER во время сбоя в сети (или переходят в режим LISTENING, но не переходят в состояние SLAVE); после восстановления сети ведомые часы быстро повторно синхронизируются и стабилизируются в состоянии SLAVE без смены ролей.
Неудачная блокировка: во время прерывания работы сети главный тактовый генератор ошибочно определяет всю сеть как не имеющую хозяина из-за отсутствия пакетов и автоматически переключается на ПОДЧИНЕННЫЙ или переходит в неопределенное состояние; после восстановления двое часов-избираются, что может привести к смене ролей или длительным колебаниям.
IV. Проверка источника системных часов
Выполните `chronyc source -v` или `phc2sys` на ведомом устройстве, чтобы проверить статус:
Убедитесь, что системные часы соответствуют только указанным аппаратным часам PTP (например, /dev/ptp0), а смещение стабильно в микросекундном диапазоне без значительных скачков, что косвенно доказывает стабильность отношений «главный-подчиненный».
