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