Як перевірити, чи синхронізація PTP із двома-сенсорами є нормальною

Основою перевірки нормальної синхронізації PTP із подвійним-сенсором є перевірка того, чи зміщення часу є стабільним у діапазоні мікросекунд і чи відповідає статус головного-підпорядкованого очікуванням. Ось конкретні практичні кроки для перевірки:

I. Перегляд-зсуву синхронізації в реальному часі (найбільш інтуїтивно зрозумілий метод)

Запустіть службу PTP на датчику веденого годинника та спостерігайте за журналами. Це золотий стандарт для оцінки точності синхронізації.

Виконати команду:

bash sudo ptp4l -i eth0 -m -q

Примітка: eth0 потрібно замінити фактичною назвою мережевого інтерфейсу, підключеного до мережі PTP; -m вказує на друк детальних журналів, а -q зменшує надлишкову інформацію.

Критерії судження

Зверніть увагу на поле зміщення у вихідному журналі:

Нормальна синхронізація: значення зсуву стабільне в межах ±1~10 мікросекунд (мкс) з мінімальними коливаннями.

Аномалія синхронізації: значення зміщення знаходяться в діапазоні мілісекунд (мс) або різко коливаються (наприклад, раптово змінюються від +50 мкс до -200 мкс).

Несинхронізовано: у журналах часто з’являються статуси FAULTY або неможливо вибрати найкращий головний годинник.

II. Перевірте статус ролі Master-Slave

Переконайтеся, що два датчики правильно встановили зв’язок «головний-підлеглий», щоб уникнути конфліктів із «подвійним-головним» або частого перемикання.

Переглянути результати виборів BMCA

Шукайте в журналах фразу «вибрано кращий майстер-годинник».

Нормальний: Журнал підлеглого годинника показує, що він розпізнає головний годинник і перейшов у стан SLAVE.

Ненормальний: обидва датчики відображаються як MASTER, що вказує на неправильну конфігурацію пріоритету або переривання зв’язку.

Перевірте параметри пріоритету

Переконайтеся, що значення priority1 головного датчика менше, ніж значення підлеглого датчика (наприклад, для головного датчика встановлено значення 128, для підлеглого — 130), переконавшись, що роль фіксована та не перемикається довільно через тремтіння мережі.

III. Перевірте, чи діє мітка часу обладнання

Якщо зсув знаходиться в діапазоні мілісекунд, зазвичай це пов’язано з тим, що апаратні мітки часу не ввімкнено, що призводить до недостатньої точності.

Виконати команду:

`bash ethtool -T eth0`

Критерії оцінки: вихідні дані мають містити `SOF_TIMESTAMPING_TX_HARDWARE` і `SOF_TIMESTAMPING_RX_HARDWARE`.

Якщо наявне лише `ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ`, це вказує на те, що використовуються позначки часу програмного забезпечення, а точність не відповідає вимогам для високо-порівняння подвійних{1}}датчиків. Необхідно перевірити підтримку драйвера або обладнання.

IV. Довгостроковий-моніторинг стабільності

Короткострокова-нормальність не гарантує-довгострокової стабільності. Рекомендується короткочасне стрес-тестування.

Рекордна швидкість дрейфу

Запустіть `phc2sys`, щоб синхронізувати апаратний годинник PTP із системним і спостерігати за максимальним зсувом протягом 24 годин.

Нормальний: довгостроковий-дрейф контролюється протягом 1 мікросекунди, без сукупного відхилення.

Ненормальний: зсув лінійно збільшується з часом, що вказує на те, що компенсація частоти кварцевого генератора неефективна або існує асиметрична затримка мережі.

Спостерігайте за втратою пакетів. Перевірте журнали PTP на предмет часу очікування peer_delay або часу очікування синхронізації. Випадкові випадки допустимі, але часті випадки вимагають перевірки якості мережевого кабелю, навантаження комутатора або налаштувань брандмауера (переконайтеся, що UDP-порти 319/320 відкриті).

V. Загальна таблиця усунення несправностей