Перейти до основного вмісту

Діагностика затримки компонентів 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 вимірів та абсолютних меж p99: 0,7 мс для бекенду й 0,93 мс для стадії. Загальний допуск пропускної здатності не розширює ці межі компонентів. Під час діагностики не змінюйте межі, тестові дані, прогрівання, кількість ітерацій та граничні строки.

Зберігайте наявні докази​

Матриця продуктивності тепер зберігає повністю захоплені 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; він не є безпосередньою заміною позик DMA Scheduler, обмежених одним викликом. Ніколи не вдавайте, що ці позики є постійними, не запускайте залежну роботу рекурсивно зі зворотних викликів завершення та не вилучайте епохи доступу заради економії часу.

Якщо переважає декодування, оптимізуйте числову реалізацію в Kernels із перевірками еквівалентності виходу. Якщо переважають отримання чи публікація, оптимізуйте виміряний шлях без прихованих копій даних і без послаблення володіння. Для будь-якої зміни планування вимагайте тести справедливості, обмеженості стека й місткості, поширення відмов, повторного прив’язування, завершення та точності меж метрик.

Насамкінець повторіть незмінену канонічну матрицю без діагностичних перевизначень. Збережіть початковий невдалий результат; діагностичний успіх не замінює його.