マスター、スレーブの役割のロックが成功したことを確認するには、構成パラメータの検証、リアルタイムのログ モニタリング、ストレス テストの 3 つの側面を組み合わせる必要があります。-これにより、正常なネットワーク条件と異常なネットワーク条件の両方で役割が切り替わらないことが保証されます。
I. 設定ファイルパラメータの検証
両方のセンサーの「/etc/linuxptp/ptp4l.conf」設定ファイルをチェックして、キー ロック パラメータが有効であることを確認します。
マスタークロック
「priority1」は低い値 (例: 128) にする必要があります。
`masterOnly 1`: これは役割をロックするためのコアパラメータであり、ノードが強制的にマスタークロックになり、スレーブクロックになるためのBMCA選択への参加を拒否することを示します。
スレーブクロック
「priority1」は高い値 (130 など) にする必要があり、その優先順位がマスター クロックよりも低いことが保証されます。
`masterOnly 0` (デフォルト): スレーブ クロックとして同期できるようにします。
II.リアルタイムのログステータス監視-
ptp4l サービスを再起動した後、「sudo ptp4l -i eth0 -m -q」を実行してリアルタイム ログを観察します。-
固定役割表示: マスターデバイスのログには、継続的に「ポート 1: MASTER」と表示される必要があります。
スレーブデバイスのログには、「port 1: SLAVE」と表示され続けるはずです。
選択アラームなし: ログには、「変更された最適なマスター クロック」や「選択された最適なマスター クロック」など、BMCA の再選択を示すレコードが含まれていてはなりません。{0}}
FAULTY 状態が表示されてすぐに元の役割に戻る場合は、ロック メカニズムが機能しています。回復後に役割が交換された場合、ロックは失敗しています。
Ⅲ．ネットワーク切断・再接続ストレステスト（究極検証）
ネットワーク停止シナリオをシミュレートして、ロール ロックの堅牢性を検証します。
操作: スレーブ クロック ネットワーク ケーブルを一時的に切断するか、ネットワーク カード インターフェイスを無効にし、約 10 ～ 20 秒待ってから接続を復元します。
判断基準：
ロックの成功: ネットワークの中断中、マスター クロックは MASTER 状態を維持します (または LISTENING に入りますが、SLAVE には低下しません)。ネットワークの回復後、スレーブ クロックはすぐに再同期し、ロールが切り替わることなく SLAVE 状態で安定します。
ロック失敗：ネットワーク中断時、パケット不足によりマスタークロックがネットワーク全体をマスターレスと誤判断し、自動的にSLAVEに切り替わるか不定状態になります。回復後、2 つのクロックが再選択され、役割が逆転したり、変動が長引いたりする可能性があります。{0}}
IV.システムクロックソースの検証
スレーブ デバイスで `chronycsources-v` または `phc2sys` を実行してステータスを確認します。
システム クロックが指定された PTP ハードウェア クロック (例: /dev/ptp0) のみに従っていること、およびオフセットが大幅な変動がなくマイクロ秒の範囲で安定していることを確認して、マスター-の関係の安定性を間接的に証明します。
