GigEのパケット損失を層ごとに切り分ける

この試験で確認すること

不完全な画像転送、トリガ欠落、アプリのキュー損失を分けます。フレーム数だけでは原因を特定できません。

本稿はメーカーに依存しない立上げ試験の方法です。設定変更前に、使用するカメラ、レンズ、センサ、制御装置の型式別マニュアルを確認してください。計算表の数値は仮定例であり、Deyi Visionの実測結果や製品仕様ではありません。

適用条件

本番の画素形式、ROI、トリガ列を使います。パック形式と付加データは容量を変えるため、報告されたペイロードサイズを使用します。

最初に未入力トリガとネットワーク上の不完全画像を区別します。処理や保存の失敗も部品記録の欠落を起こします。型式別マニュアルで利用可能なカメラ・受信側カウンタの定義を確認し、単なるタイムアウトをパケット損失とみなさないでください。変更前の失敗設定を保存します。

試験機材と記録

専用NIC、正常なケーブル、転送・NIC・アプリのカウンタ記録を準備します。ドライバ、スイッチ、MTU、パケットサイズ、fps、CPU負荷を保存します。

カメラ、ケーブル、スイッチ、ホストまでの経路を図示し、各区間のMTU、リンク速度、アダプタ、転送設定、画像寸法、パッキング、処理を記録します。試験IDごとに予定トリガ、フレームID、不完全画像、取得できる再送統計、処理結果、保存ファイルを照合し、再起動やカウンタ初期化で試験を混ぜないようにします。

試験手順

1. カメラ1台を直結し、対応範囲内の保守的なパケットサイズで期待画像10000枚を記録する。
2. 区間ごとにトリガ数、画像ID、完全受信数、処理結果数を照合する。
3. ケーブル、サイズ、パケット間隔を一つずつ変え、経路全体のMTU対応を確認する。
4. スイッチと他のカメラを順に戻し、本番のディスク書込とCPU負荷で再試験する。

撮影条件を保ち、対応する保守的なパケットサイズで処理と保存を停止して受信します。開始前後のカウンタを残し、処理と保存を一つずつ戻します。各試験で転送設定は一項目だけ変更し、改善しない設定は戻します。短時間の無欠落より再現する改善を重視します。

仮定条件による計算表

仮定の2048 × 1536画素Mono8画像を30 fpsで取得すると、ペイロードは94.37 MB/sです。通信オーバーヘッドと再送は別途必要であり、十分な帯域余裕を証明する値ではありません。

payload_rate = payload_bytes * frames_per_second
2048 * 1536 * 1 * 30 = 94371840 B/s
= 94.37 MB/s = 754.97 Mbit/s (payload only)

計算は画像ペイロードだけです。ヘッダ、再送、競合機器の帯域も必要なのでリンク速度未満でも余裕は証明できません。画素バイト数の前提となるパッキングやパディングを確認します。予定数から各段階を照合し、最初に数が違う段階を調査しますが、その段階だけで原因と断定しません。

試験の流れ

結果の読み方

カメラIDが進んでも完全画像が届かなければ転送と受信を調べます。完全画像があるのに結果がなければキュー所有権や処理例外、結果があるのにファイルがなければ保存を調べます。対応するカウンタとログを残してください。別フレームの正常画像は欠落の説明になりません。

トラブルシューティング

• 再送とNICエラーが同時に増えるなら通信経路を調べる。
• 完全受信しても結果が欠落する場合はキューと処理能力を調べる。バッファ増加だけでは過負荷を先送りすることがある。

保存を有効にした時だけの失敗はホスト競合の可能性があるため、停止して再現確認します。大きなパケットで悪化したら全経路のMTUを調べます。パケット間隔を延ばすと瞬間負荷が減る一方で転送が長くなり得るため、実機のスループットと取得動作を確認します。

受入判定と引継ぎ

合意した運転時間とピーク負荷でカウンタが一致し、説明できない不完全画像がないことを確認します。運転時間と再送数を記録し、短時間の成功から無期限の安定性を主張しません。

生データ、設定、試料ID、判定限界を一式で保存してください。関連製品と事前準備のガイドを参照し、記録した要件をDeyi Visionに相談できます。

最終設定で処理、保存、予定ネットワーク負荷を含む本番条件を再試験し、合意した全期間で各段階を照合します。許容損失は明記します。安全が確保できる時だけ受信再起動やケーブル復旧を試し、不完全画像の除外を確認します。経路図、カウンタ定義、設定、持続可能な負荷の証拠を引継ぎます。