こんにちは、チームの皆さん
gPTP の例でブリッジ デバイスの動作をテストしていました。私はGrayVIP_1_0_22_0を使用しています。
ユーザー マニュアルによると、ブリッジがStartupTimeoutS後に Sync メッセージを受信しない場合は、GM として動作を開始する必要があります。ただし、この状況では、同期フレームと同期フォローアップ フレームの両方のシーケンス ID が 1024 のまま増加しないことがわかりました。
関連コードを確認したところ、ブリッジが GM モードに移行すると、同期メッセージの生成に使用されるシーケンス ID が、スレーブ ポートのprSyncMachines [ prDomain -> u8SlaveMachineId ]. u16SequenceIdから取得されることがわかりました。
スレーブ ポートが Sync メッセージを受信していない場合、この値は更新されず、マスター ポートから送信された Sync メッセージ内のシーケンス ID は変更されません。
この動作は、このメカニズムではブリッジが GM として適切に機能できないことを示しています。
なぜこの橋がこのように動作するように設計されているのか、説明していただけますか?
BR、
ブリジット
こんにちは@Bridget 、
チームはケースを取り上げ、できるだけ早く回答を提供します。
よろしくお願いします、
ラドゥ
こんにちは@Bridget 、
私たちは問題を再現するために取り組んでおり、チーム内で今後の手順について話し合う予定です。折り返しご連絡いたします。
ありがとう、
ルーカス
実際のところ、gPTP ブリッジのこの動作は意図されたものであり、802.1as 標準に準拠しています。
ブリッジは、マスター ポートで受信したシーケンス ID を中継することになります。グランド マスターが失われた場合、シーケンス ID は実際に更新されなくなります。これは、ダウンストリーム デバイスが GM が失われたことを検出できる方法の 1 つです。
そもそも GM が存在しないブリッジの場合、シーケンス ID は標準ごとにランダムになります。ランダム性の解釈は、シーケンス ID については何も保証されない、または想定されるべきではないということです。ハードコードされた 1024 はこれに準拠していると見なされます (他の数値でもかまいません)。
シーケンス ID がアプリケーションで問題を引き起こしていますか?ご存知のとおり、エンドポイントはシーケンス ID に関係なく、ブリッジと完全に同期できます。
長くかかってしまい申し訳ありません。不明な点がございましたらお知らせください。
BR、ルーカス