SSD 구성 요소 지연 시간 진단

ssd_mobilenet_boxdecode가 구성 요소 지연 시간 예산을 충족하지 못할 때 이 절차를 사용하세요. FPS 결과가 통과해도 실패한 구성 요소 p99를 무효화하지 않습니다.

측정 경계를 명확하게 유지하기

현재 그래프는 수치 BoxDecode와 와이어 형식 게시 어댑터를 별도의 A65 구성원으로 준비합니다. 출력 와이어 형식은 Core가, 수치 연산은 Kernels가 담당합니다. Scheduler는 검증된 구성원을 Runner를 통해 제출합니다.

구성 요소	시작	끝	포함되는 작업
boxdecode_backend_wall_v2.execution_envelope_wall	수치 디코드 호출	종속된 와이어 게시 호출 완료	디코드, 중간 스케줄링 및 접근 작업, 와이어 인코딩
boxdecode_stage_wall_v2	출력 획득 전의 완전한 프레임 수락	작업 종료 확인, 마무리 및 입력 해제 완료	풀 획득, 바인딩, 모든 구성원 실행 및 최종 처리

단계 타이밍과 백엔드 타이밍 모두 해당 프레임 자체의 다운스트림 푸시를 포함하지 않습니다. 백엔드 구간은 앞선 변환 구성원을 제외하지만, 단계 구간은 이를 포함합니다.

이는 실제 경과 시간 구간이지 CPU 사용률이나 순수 커널 시간이 아닙니다. 기존 boxdecode_backend 및 boxdecode_plugin_exclusive 구간과 의도적으로 다른 측정 항목입니다. 서로 다른 구간을 비교하여 수치 커널 성능 저하의 증거로 삼거나, 결과를 통과시키기 위해 큐 시간을 제거하지 마세요.

저장소의 주간 기준은 샘플 1,000개와 백엔드 0.7ms, 단계 0.93ms의 절대 p99 제한을 요구합니다. 일반 처리량 허용 오차는 이러한 구성 요소 제한을 확대하지 않습니다. 진단하는 동안 제한, 픽스처, 워밍업, 반복 횟수 및 제한 시간을 그대로 유지하세요.

기존 증거 보존하기

성능 매트릭스는 이제 성공한 실행, 잘못된 출력, 건너뛰기 및 감독자 실패를 포함하여 모든 시나리오 시도의 stdout과 stderr를 완전히 저장합니다. 각 결과의 run_meta.artifacts는 다음을 포함하는 고유한 scenario-logs/ 디렉터리를 가리킵니다.

• stdout.log와 stderr.log: 마지막 부분만이 아닌 전체 캡처 스트림.
• invocation.json: 명령, 작업 디렉터리, 반복 횟수, 제한 시간 및 두 추적 제어 환경 값. 전체 환경을 덤프하지 않습니다.
• 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 실행기를 사용하세요. AArch64 테스트를 x86 호스트에서 실행하지 마세요.

추적 유지, 비어 있지 않은 추적 디렉터리 재정의 또는 반복 횟수 재정의를 사용하면 결과에 run_meta.execution_purpose: diagnostic이 기록됩니다. 비교 및 실패 코드는 변하지 않으며, 이 레이블이 통과 기준을 완화할 권한을 부여하지는 않습니다. 이러한 재정의가 없으면 baseline_comparison을 기록하지만, 이것만으로 완전한 표준 CI 실행이 입증되지는 않습니다.

요청한 추적 상위 디렉터리가 실제 세션 식별자는 아닙니다. run_meta.measure_report.plugin_latency.trace_dir와 수집 상태를 읽은 다음, 그 정확한 디렉터리를 결과 및 시나리오 로그와 함께 보관하세요. CTF 기록의 플러그인 인스턴스, 실행, 그래프, 프레임 및 요청 식별 정보를 유지하세요. 상관관계를 꾸며내지 말고 누락된 이벤트나 추적 손실을 보고하세요. 결과 디렉터리를 재사용하면 최상위 결과 JSON은 교체되지만 이전 시도 로그 디렉터리는 유지됩니다. 별도의 검증 작업에는 새로운 결과 및 추적 루트를 사용하세요.

최적화 전에 비용의 원인 구분하기

보존된 경과 시간 구간의 CTF는 이상치와 이벤트 식별 정보를 보여줄 수 있지만, 그 자체로 수치 연산 시간과 디코드에서 게시로 넘어가는 스케줄링 간격을 분리하지는 못합니다. 독립적으로 계산한 백분위수를 서로 빼지 마세요. 같은 프레임을 연결하고, 필요한 경우 별도로 계측한 빌드에서 다음 경계를 수집하세요.

1. 출력 획득 및 바인딩/접근 준비.
2. 구성원 큐 삽입, 작업자 시작, 실행 시작 및 실행 끝.
3. 수치 디코드 종료에서 게시 실행 시작까지.
4. 게시 실행, 접근 종료 확인, 마무리 및 입력 해제.
5. 워밍업 후 구간의 할당, 가져오기, 복사된 바이트 및 큐/깨우기 횟수.

Runner와 Scheduler에는 비공개 SIMA_RUNTIME_TEST_TRACE 테스트 연결 지점이 있지만, 프로덕션 빌드에서는 비활성화됩니다. 이를 사용하려면 별도로 빌드한 일치하는 공급자와 검증된 스레드/구성원 간 상관관계가 필요합니다. 환경 변수만 활성화해서는 해당 이벤트가 생성되지 않습니다. 계측 측정값은 최종 표준 성능 결과와 분리하세요.

디스패치가 대부분을 차지하면, 먼저 수락한 각 작업과 현재 메모리 대여를 유지하는 일반적이고 제한된 준비 작업 연속 실행을 평가하세요. 기존 PreparedSequence는 지속적인 BoundOperation 객체를 받으므로, Scheduler의 호출에 한정된 DMA 대여를 그대로 대체할 수 없습니다. 해당 대여가 지속적이라고 간주하거나, 완료 콜백 안에서 종속 작업을 재귀적으로 실행하거나, 시간을 줄이려고 접근 에포크를 제거하지 마세요.

디코드가 대부분을 차지하면 출력 동등성 검사를 통해 Kernels의 수치 구현을 최적화하세요. 획득 또는 게시가 대부분을 차지하면 숨겨진 페이로드 복사를 추가하거나 소유권을 약화하지 않고 측정된 해당 경로를 최적화하세요. 스케줄링을 변경할 때는 공정성, 제한된 스택/용량, 실패 전파, 재바인딩, 작업 종료 확인 및 정확한 측정 경계 테스트를 요구하세요.

마지막으로 진단 재정의 없이 변경되지 않은 표준 매트릭스를 다시 실행하세요. 원래 실패한 결과는 보존해야 하며, 진단 실행의 통과가 이를 대체하지는 않습니다.