SSD コンポーネントのレイテンシを診断する
ssd_mobilenet_boxdecode がコンポーネントのレイテンシ予算を超える場合に、この手順を使用します。FPS が合格しても、コンポーネントの p99 の失敗を覆すことはできません。
計測境界を明確にする
現在のグラフは、数値 BoxDecode とそのワイヤー形式公開アダプターを別々の A65 メンバーとして準備します。Core が出力ワイヤー形式を、Kernels が数値操作を所有します。Scheduler は検査済みメンバーを Runner 経由で投入します。
| コンポーネント | 開始 | 終了 | 含まれる処理 |
|---|---|---|---|
boxdecode_backend_wall_v2.execution_envelope_wall | 数値デコード呼び出し | 依存するワイヤー形式公開呼び出しの完了 | デコード、その間のスケジューリングとアクセス処理、ワイヤーエンコード |
boxdecode_stage_wall_v2 | 出力取得前の完全フレーム受け入れ | 終了確認、finish、入力解放の完了 | プール取得、バインド、全メンバー実行、最終処理 |
ステージ計測にもバックエンド計測にも、そのフレーム自身の下流への push は含まれません。バックエンド区間は先行する変換メンバーを除外し、ステージ区間はそれらを含みます。
これらは実経過時間の範囲であり、CPU 使用率や純粋なカーネル時間ではありません。旧 boxdecode_backend および boxdecode_plugin_exclusive 区間とは意図的に異なる識別名になっています。異なる区間を比較して数値カーネルの退行の証明としたり、合格させるためにキュー時間を除去したりしないでください。
リポジトリの週次ベースラインは 1,000 サンプルを要求し、p99 の絶対上限はバックエンドが 0.7 ms、ステージが 0.93 ms です。一般的なスループットの許容幅は、これらのコンポーネント上限を緩和しません。診断中も上限、フィクスチャ、ウォームアップ、反復回数、期限を変更しないでください。
既存の証拠を保持する
性能マトリクスは、成功、出力不正、スキップ、スーパーバイザー失敗を含む各シナリオ試行の stdout と stderr を完全に保存します。各結果の run_meta.artifacts は、次を含む一意の scenario-logs/ ディレクトリを指します。
stdout.logとstderr.log: 末尾だけでなく、取得したストリーム全体。invocation.json: コマンド、作業ディレクトリ、反復回数、期限、2 つのトレース制御環境値。環境全体は出力しません。outcome.json: 比較結果と、取得できたプロセス/スーパーバイザーの結果。
ログには実行ファイルが出力した内容がそのまま含まれるため、共有前に確認してください。スーパーバイザーが実行を拒否した場合、プロセス出力がないこともあります。空のログはプロセスの実行、終了、デバイスリソース解放の証拠にはなりません。失敗記録を保持し、通常の復旧手順に従ってください。
別の診断実行では、既存の制御を使用します。
SIMA_NEAT_METRICS_RETAIN_TRACE=1は LTTng Common Trace Format (CTF) ファイルを保持します。SIMA_NEAT_METRICS_TRACE_DIRはその親ディレクトリを選択します。コレクターはセッションごとに一意の子ディレクトリを作成します。
正しいプロバイダーとファームウェアがインストールされた、新たに許可されたハードウェアテストスコープ内で、DevKit 上でマトリクスを実 行します。これらの環境値は実行許可の前に設定し、有効な固定済み検証スコープを変更しないでください。この保護付き診断手順では、SIMA_HARDWARE_SUPERVISOR_SOCKET により常駐スーパーバイザーを明示的に選択します。標準 CI では不要です。マトリクス自体はボード所有権の取得やファームウェア変更の許可を行いません。
たとえば、インストール済みテストディレクトリを選択し、診断環境の実行許可を得た後、ターゲットの Core チェックアウトから次を実行します。
: "${CORE_ROOT:?set the target Core checkout path}"
: "${CORE_TESTS:?set the installed target test directory}"
: "${SIMA_HARDWARE_SUPERVISOR_SOCKET:?use an admitted hardware-test scope}"
cd "$CORE_ROOT"
export SIMA_NEAT_METRICS_RETAIN_TRACE=1
export SIMA_NEAT_METRICS_TRACE_DIR="$CORE_ROOT/ssd-diagnostic-traces"
python3 tests/perf/tools/run_perf_matrix.py \
--repo-root "$CORE_ROOT" \
--prebuilt-tests-dir "$CORE_TESTS" \
--include-long \
--results-dir "$CORE_ROOT/ssd-diagnostic-results"
これは SSD を含む週次性能マトリクス全体を実行します。プロバイダーの再ビルドはしません。ターゲットプログラムには SDK クロスコンパイルと DevKit ランチャーを使い、x86 ホストで AArch64 テストを直接実行しないでください。
トレース保持、空でないトレースディレクトリの上書き、反復回数の上書きがある場合、結果に run_meta.execution_purpose: diagnostic が記録されます。比較と失敗コードは変わりません。このラベルはゲートを緩和する許可ではありません。これらの上書きがなければ baseline_comparison が記録されますが、それだけで完全な標準 CI 実行の証明にはなりません。
要求したトレース親ディレクトリは、実際のセッション識別情報ではありません。run_meta.measure_report.plugin_latency.trace_dir と収集状態を確認し、その正確なディレクトリを結果およびシナリオログと一緒にアーカイブしてください。CTF レコードのプラグインインスタンス、実行、グラフ、フレーム、要求の識別情報を保持します。イベント欠落やトレース損失は、相関を捏造せず報告してください。結果ディレクトリを再利用すると最上位の結果 JSON は置き換わりますが、過去の試行ログディレクトリは保持されます 。別のキャンペーンには新しい結果/トレースルートを使ってください。
最適化の前にコストを特定する
保持された実経過時間区間の CTF は外れ値とイベント識別情報を示せますが、それだけでは数値処理時間とデコードから公開までのスケジューリング間隔を分離できません。独立に計算したパーセンタイル同士を差し引かないでください。同じフレームを関連付け、必要なら別途計測を追加したビルドで次の境界を収集します。
- 出力の取得と、バインド/アクセス準備。
- メンバーのエンキュー、ワーカー開始、実行開始、実行終了。
- 数値デコード終了から公開処理の実行開始まで。
- 公開処理、アクセス終了確認、finish、入力解放。
- ウォームアップ後の区間における割り当て、インポート、コピーバイト数、キュー/ウェイクアップ数。
Runner と Scheduler には非公開の SIMA_RUNTIME_TEST_TRACE テスト用機構がありますが、本番ビルドでは無効です。利用するには、別途ビルドした対応プロバイダーと、検証済みのスレッド/メンバー間相関が必要です。環境変数を有効にするだけでは、そのイベントは生成されません。計測用ビルドの測定値は、最終的な標準性能結果と分けて扱ってください。
ディスパッチが支配的な場合は、まず、許可済みの各ジョブとその現在 のメモリ貸与を保持する、汎用で容量制限のある ready-work 継続処理を評価します。既存の PreparedSequence は永続的な BoundOperation オブジェクトを受け付けますが、Scheduler の呼び出し限定 DMA 貸与をそのまま置き換えるものではありません。この貸与を永続的と見なしたり、完了コールバック内で依存処理を再帰的に実行したり、時間短縮のためにアクセスエポックを除去したりしてはいけません。
デコードが支配的な場合は、出力の同等性を確認しながら Kernels の数値実装を最適化します。取得や公開が支配的なら、隠れたペイロードコピーの追加や所有権の弱体化をせず、測定した経路を最適化します。スケジューリングを変更する場合は、公平性、スタック/容量の上限、失敗伝播、再バインド、終了確認、正確な計測境界のテストを必須としてください。
最後に、診断用の上書きなしで、変更していない標準マトリクスを再実行します。元の失敗結果は保持してください。診断の合格で置き換えることはできません。