Гальмування гри на швидкому ПК: основи DPC-латентності (і шлях виправлення)

Що таке DPC-латентність (простими термінами ядра)

Windows обробляє події апаратури через переривання. Коли ваш NIC отримує пакети, контролер USB фіксує подію пристрою або сховище завершує I/O, пристрій піднімає переривання. CPU припиняє поточну роботу, виконує ISR (Interrupt Service Routine — обробник переривання), і зазвичай планує DPC (Deferred Procedure Call), щоб виконати більшу частину роботи пізніше на нижчому пріоритеті переривань.

DPC існують тому, що ISR мають бути швидкими. ISR працюють на високому IRQL (рівні запиту переривання), де система не може виконувати багато звичайних операцій. Тому ISR робить мінімум (підтверджує апарат, фіксує стан) і ставить у чергу DPC, який запускається пізніше на DISPATCH_LEVEL. Все ще підвищено. Все ще чутливо до часу. Все ще може позбавити інших задач CPU, якщо виконується занадто довго або занадто часто.

DPC-латентність у щоденній мові налаштування ПК означає: «Як довго важлива робота мала чекати, бо щось інше тримало CPU на підвищеному пріоритеті?» Ігри дбають про це, бо потребують стабільного часу кадрів. Аудіо — бо буфери треба заповнювати вчасно. VR — бо пропущені дедлайни викликають нудоту, а не лише роздратування.

Один нюанс: «DPC-латентність» — це не одне число. Інструменти відображають кілька пов’язаних речей:

• Найдовший час виконання ISR: драйвер занадто довго працював всередині ISR.
• Найдовший час виконання DPC: DPC драйвера працював занадто довго.
• Затримка від переривання до процесу: час від виникнення переривання до отримання CPU потокою в режимі користувача.

Якщо взяти одне: мікрозатримка часто — це провал вирівнювання кадрів, і піки DPC/ISR є одним із найпоширеніших «вбивць» вирівнювання на потужних машинах.

Чому швидкий ПК все одно гальмує

Ваш GPU може нудьгувати, CPU бути на 20% завантаження, а ви все одно можете мати затримки. Бо проблема не в пропускній здатності; вона в латентності. Пропускна здатність — це «скільки роботи за секунду». Латентність — це «як довго чекати на обслуговування конкретної одиниці роботи». Ігри — це системи, схожі на реальний час, які вдають, що вони пакетні завдання. Вони працюють добре доти, доки не перестають, а режим помилки — ривкові часи кадрів.

Сучасні ПК насичені перериваннями. Опитування USB, контролери RGB, енергозбереження Wi‑Fi, стек Bluetooth, аудіо-розширення, телеметрія ядра, переривання завершення сховища і планування драйвера GPU — все хоче шматок CPU. Більшість часу Windows арбітрує нормально. Але один погано поводжений драйвер може привласнити підвищений пріоритет настільки надовго, що бюджет кадру 16.6 мс виросте до 40 мс, а потім «відновиться», ніби нічого не сталося.

Інша річ, що дивує: енергоменеджмент — це компроміс. Глибокі C-states, агресивне збереження пакета та відключення пристроїв можуть додавати час пробудження. Така латентність проявляється як джиттер. Система не «повільна», вона «спить у невідповідний момент».

Суха реальність: ринок винагороджує знімки пікових FPS більше, ніж нудну послідовну подачу кадрів. Проблеми DPC живуть у «нудній» зоні. Тому треба робити власну операційну роботу.

Факти та історичний контекст, які можна повторювати на роботі

1. DPC створювали, щоб ISR були короткими. Ось чому «високий час DPC» часто означає, що драйвер робить забагато відкладеної роботи замість того, щоб блокуватися всередині ISR.
2. Аудіо зробило DPC-латентність відомою. Перші хвилі скарг «у ноутбука тріскає звук» виникали через те, що реальні аудіо-навантаження конфліктували з поганими Wi‑Fi та ACPI драйверами.
3. Мультимедійний планувальник Windows (MMCSS) існує не просто так. Він намагається пріоритезувати часовочутливі аудіо/відео потоки, але не може випередити ISR/DPC, що займає підвищений IRQL.
4. Переривання завершення сховища «дешеві», поки раптом не стають такими. Пристрої з високим IOPS можуть генерувати багато переривань; якщо шлях налаштовано погано, ви отримуєте джиттер замість швидкості.
5. HPET став народним засобом. Люди вмикають/вимикають HPET, бо іноді це змінює поведінку таймерів, але це не універсальне рішення і може бути плацебо.
6. MSI (Message Signaled Interrupts) допоміг масштабувати переривання. MSI/MSI-X уникає спільних ліній переривань і може зменшити конфлікти — якщо драйвер або прошивка не багована.
7. Якість прошивки ACPI варіюється вкрай сильно. «Невелика» помилка BIOS у методі управління енергоспоживання може створити періодичні DPC-штормы. Так, ваша материнська плата може так робити.
8. Мережеві драйвери мають довгу історію руйнування латентності. Offload, coalescing і енергозбереження — виграші по пропускній здатності, що можуть стати втратою латентності в інтерективних навантаженнях.
9. Драйвери GPU великі й складні. Вони також працюють у режимі ядра, і складність — не стратегія оптимізації латентності.

Симптоми й сигнали: як виглядає «проблема DPC»

У іграх

• «Кожні 10–60 секунд гра замикає на частку секунди.»
• Лічильник FPS виглядає високим, але графік часу кадру показує сплески.
• Затримки погіршуються при підключенні/відключенні USB-пристроїв, відкритті оверлею, приєднанні голосового чату або при alt-tab.
• Затримок немає в синтетичному бенчмарку, але вони з’являються в реальній грі (бо переривання й фонові I/O різняться).

В аудіо та трансляціях

• Тріск/попи у звуці, особливо коли Wi‑Fi активний.
• Десинхрон звуку під час запису геймплею; потік запису пропускає дедлайни.
• «Роботоподібний» голос у голосовому чаті під навантаженням системи.

У загальній поведінці системи

• Мікрозатримки курсора миші, що збігаються з подіями USB або активністю сховища.
• Перiодичні піки в процесі «System» без очевидного користувацького процесу.
• Попередження у Event Viewer про скидання драйверів (графіка, сховище, мережа).

Жарт #1: DPC-латентність — це як нарада, що затягнулася — всі можуть бути талановитими, але графік усе одно ламається.

Швидкий план діагностики (перший/другий/третій)

Це «в вас є година, поки ви не звинуватите гру» шлях. Мета — не досконалити систему; мета — ізолювати домен, що створює вузьке місце.

Перше: підтвердити, що це проблема латентності/вирівнювання, а не сирий перформанс

• Використовуйте внутрішній графік часу кадру або оверлей, що показує часи кадрів, а не лише FPS.
• Якщо ви бачите сплески з ~8–16 мс до 30–100+ мс — ви в зоні проблем вирівнювання.
• Якщо час кадру постійно зростає з температурою — це тротлінг. Інша проблема.

Друге: знайти найбільшого порушника ISR/DPC

• Запустіть LatencyMon на 5–10 хвилин під час відтворення затримки.
• Відсортуйте драйвери за найвищим часом ISR і DPC.
• Шукайте знайомі «підозри»: мережеві драйвери, стек GPU, ACPI, контролер сховища, шина аудіо, контролер USB.

Третє: ізолюйте шляхом вимкнення/видалення цілих класів пристроїв

• Тестуйте з Ethernet проти Wi‑Fi (або повністю вимкніть Wi‑Fi).
• Відключіть несерйозні USB-пристрої (особливо аудіоінтерфейси, пристрої захоплення, хаби, контролери RGB).
• Тимчасово відключіть оверлеї, аудіо «покращення» та утиліти сторонніх розробників.
• Перемкніть план живлення на High performance (або еквівалент) і повторіть тест.

Якщо вам вдасться зупинити затримку, видаливши пристрій або відключивши драйвер, ви вже перемогли. Тепер залишилось лише прибрати наслідки.

Інструменти та методи: що використовувати і чому не довіряти

LatencyMon: добре для «хто», не для «чому»

LatencyMon — швидкий спосіб відповісти на питання: який драйвер зараз показує найгірші ISR/DPC часи? Це не судово-адвокатський профайлер. Він вибірково аналізує та робить висновки. Але для триажу він відмінний.

Windows Event Viewer: добре для «щось скинулося»

Скидання драйверів (наприклад GPU TDR) і тайм‑аути сховища лишають журнали. Логи не пояснять кожну мікрозатримку, але можуть роз’яснити великі події.

ETW/WPR/WPA: найкраще для «чому», але важче в освоєнні

Event Tracing for Windows (ETW) — це реальна підстава інструментування. Windows Performance Recorder (WPR) збирає трасування; Windows Performance Analyzer (WPA) візуалізує їх. Якщо треба довести корінь проблеми, ETW — це інструмент для дорослих.

«Одна правка, що все вирішить» відео: розвага, не операції

Більшість масових гайдів — купа реєстрових правок, що пересувають проблеми. В термінах SRE це нерев’ювальний дрейф конфігурації. Уникайте їх. Вам потрібні цілеспрямовані зміни, прив’язані до вимірювань.

Одна цитата, парафраз: підхід Gene Kranz «суворий і компетентний» тут працює: тримайте дисципліну, залишайтеся спокійними і виправляйте те, що можете довести. (парафразована ідея)

Практичні завдання (з командами, виводами та рішеннями)

Це реальні завдання, які можна виконати на Windows. Більшість використовує вбудовані інструменти. Для сторонніх утиліт, як LatencyMon, «команда» фактично «запустити програму», але ви все одно можете автоматизувати збір супутніх доказів.

Завдання 1: Визначте збірку Windows і час роботи без перезавантаження (stale reboots важливі)

cr0x@server:~$ systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"System Boot Time"
OS Name:                   Microsoft Windows 11 Pro
OS Version:                10.0.22631 N/A Build 22631
System Boot Time:          2/5/2026, 8:14:22 AM

Що це значить: Якщо ви не перезавантажувалися тижнями, можете тягнути стан драйверів, проблеми з живленням пристроїв або залишки оновлень.

Рішення: Якщо аптайм великий, а проблема нова — перезавантажте перед глибшою діагностикою. Так, серйозно.

Завдання 2: Перевірка очевидного тротлінгу/теплового режиму (усуньте неправдиву війну)

cr0x@server:~$ powercfg /energy /duration 10
Enabling tracing for 10 seconds...
Analyzing trace data...
Energy efficiency problems were found.
See C:\Windows\system32\energy-report.html for more details.

Що це значить: Звіт часто виявляє пристрої, що відмовляються спати, неправильні налаштування живлення та запити платформного таймера.

Рішення: Якщо бачите повторювані «Platform Timer Resolution» запити і ви шукаєте затримку, зафіксуйте підозрілий додаток/драйвер для пізнішої кореляції — не прибирайте одразу.

Завдання 3: Підтвердіть активний план живлення (і не прикидайтеся, що Balanced завжди ок)

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c  (High performance)

Що це значить: Balanced може бути прийнятним, але агресивні ідл-стани можуть додавати джиттер на деяких системах.

Рішення: Для діагностики перемкніться на High performance (або «Ultimate Performance» на робочих станціях), щоб зменшити змінні.

Завдання 4: Перелічіть драйвери з недавніми датами встановлення (список «що змінилося?»)

cr0x@server:~$ driverquery /v /fo table | findstr /I "Running"
nvlddmkm             Display                 Running   5/10/2025  NVIDIA Windows Kernel Mode Driver
rt640x64              Network                 Running   11/3/2025  Realtek PCIe GbE Family Controller
USBXHCI               USB                     Running   10/1/2025  USB xHCI Compliant Host Controller

Що це значить: Це не вимір латентності. Це інвентар. Мета — виявити кандидатні стеки (GPU, NIC, USB, аудіо, сховище).

Рішення: Якщо проблема почалася після оновлення драйвера — перше тестове відкатування, особливо GPU і NIC.

Завдання 5: Перевірка WHEA апаратних помилок (тиха нестабільність викликає «дивну» латентність)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=17 or EventID=18 or EventID=19) and Provider[@Name='Microsoft-Windows-WHEA-Logger']]]" /c:5 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-WHEA-Logger
  Event ID: 17
  Level: Warning
  Description:
  A corrected hardware error has occurred.

Що це значить: Виправлені помилки (часто PCIe) можуть створювати повторні спроби, затримки та впливати на драйвери. Не завжди, але достатньо часто, щоб звернути увагу.

Рішення: Якщо WHEA попередження з’являються під час гри — вимкніть розгін CPU/RAM/GPU і оновіть BIOS/chipset перед тим, як ганятися за екзотичними DPC-правками.

Завдання 6: Збір скидань драйвера GPU і помилок графіки

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=4101) and Provider[@Name='Display']]]" /c:3 /f:text
Event[0]:
  Provider Name: Display
  Event ID: 4101
  Level: Warning
  Description:
  Display driver nvlddmkm stopped responding and has successfully recovered.

Що це значить: Це серйозна подія. Якщо вона відбувається, у вас не «таємна» затримка, а проблема стабільності драйвера/розгону/живлення.

Рішення: Виправляйте стабільність спочатку: відкотіть GPU OC/undervolt, підтвердіть PSU/кабелі, чиста інсталяція драйвера GPU, а потім повторіть вимір латентності.

Завдання 7: Швидка перевірка стану сховища (тайм‑аут відчувається як затримка)

cr0x@server:~$ wmic diskdrive get model,status
Model                               Status
Samsung SSD 990 PRO 2TB              OK
WDC WD10EZEX-08WN4A0                 OK

Що це значить: «OK» — поверхнево. Це не покаже граничні проблеми прошивки NVMe або проблеми з кабелем, але виявляє очевидні відмови.

Рішення: Якщо диск не OK — зупиніться. Виправте здоров’я сховища перед тим, як шукати латентність. Якщо всі OK — продовжуйте, але тримайте сховище в підозрі.

Завдання 8: Пошук storport/disk тайм‑аутів у логах (класичний генератор підвисань)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=129) and Provider[@Name='storahci']]]" /c:3 /f:text
Event[0]:
  Provider Name: storahci
  Event ID: 129
  Level: Warning
  Description:
  Reset to device, \Device\RaidPort0, was issued.

Що це значить: Скидання сховища викликає паузи. Навіть якщо гра встановлена на іншому диску, ОС може затримуватися на системних I/O.

Рішення: Оновіть драйвери чипсета/сховища, перевірте SATA-кабелі, оновіть прошивку SSD і розгляньте можливість переміщення проблемних дисків з системного масиву.

Завдання 9: Перевірка додаткових налаштувань мережевого адаптера (interrupt moderation може бути вашим ворогом)

cr0x@server:~$ netsh interface show interface
Admin State    State          Type             Interface Name
Enabled        Connected      Dedicated        Ethernet
Enabled        Disconnected   Dedicated        Wi-Fi

Що це значить: Показує, які інтерфейси підключені. Wi‑Fi драйвери часто є джерелом DPC-проблем, коли вони підключені.

Рішення: Для діагностики вимкніть Wi‑Fi, якщо ви на Ethernet, або навпаки. Зменшіть активний стек.

Завдання 10: Тимчасово вимкніть Wi‑Fi (жорсткий тест ізоляції)

cr0x@server:~$ netsh interface set interface name="Wi-Fi" admin=disabled
Ok.

Що це значить: Ви прибрали весь стек драйвера з шляху переривань.

Рішення: Якщо затримки зникають, ви не «оптимізуєте Windows». Ви виправляєте або замінюєте Wi‑Fi драйвер/залізо або налаштовуєте його.

Завдання 11: Перевірте, чи увімкнено Game Mode (не чарівний, але прибирає деякий фоновий хаос)

cr0x@server:~$ reg query "HKCU\Software\Microsoft\GameBar" /v AllowAutoGameMode
HKEY_CURRENT_USER\Software\Microsoft\GameBar
    AllowAutoGameMode    REG_DWORD    0x1

Що це значить: Game Mode може зменшити частину фонового навантаження і покращити рішення планувальника для ігор.

Рішення: Якщо він вимкнений — увімкніть для тестів стабільності. Якщо увімкнений і у вас є проблеми — не звинувачуйте його відразу, спочатку виміряйте.

Завдання 12: Перевірте HAGS (Hardware-accelerated GPU scheduling)

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" /v HwSchMode
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers
    HwSchMode    REG_DWORD    0x2

Що це значить: Значення варіюються за версіями; загалом можна підтвердити стан. Важливо лише знати, чи ввімкнено.

Рішення: Якщо ви бачите піки DPC пов’язані з GPU, A/B тестуйте HAGS (переключення, перезавантаження, повторне вимірювання). Залишайте те, що дає менші пики і краще вирівнювання кадрів.

Завдання 13: Перевірте core isolation / memory integrity (може впливати на поведінку драйверів)

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity
    Enabled    REG_DWORD    0x1

Що це значить: Memory integrity (HVCI) підвищує безпеку, але може змінити характеристики виконання драйверів і сумісність.

Рішення: Не вимикайте це як перший крок. Тестуйте A/B тільки якщо є докази, що саме драйвер поводиться проблемно, і ви готові прийняти ризик безпеки.

Завдання 14: Швидкий інвентар USB-пристроїв (прибрати шумних сусідів)

cr0x@server:~$ pnputil /enum-devices /class USB | findstr /I "Device Description"
Device Description: USB Composite Device
Device Description: USB Root Hub (USB 3.0)
Device Description: USB Input Device

Що це значить: USB — це джунглі. Це допомагає згадати, що підключено і що може генерувати переривання.

Рішення: Якщо у вас ланцюг хабів з аудіо + захоплення + RGB, спростіть. Підключайте критичні пристрої безпосередньо до портів материнської плати і тестуйте.

Завдання 15: Перевірте, чи «System» процес раптово злітає (ядрова робота помітна в інструментах користувача)

cr0x@server:~$ typeperf "\Process(System)\% Processor Time" -sc 5
"(PDH-CSV 4.0)","\\DESKTOP\Process(System)\\% Processor Time"
"02/05/2026 09:12:01.123","0.000000"
"02/05/2026 09:12:02.125","3.000000"
"02/05/2026 09:12:03.126","28.000000"
"02/05/2026 09:12:04.128","4.000000"
"02/05/2026 09:12:05.129","2.000000"

Що це значить: Сплески CPU у System можуть корелювати з ISR/DPC-штормами, скиданнями сховища, мережевими сплесками або помилками драйверів.

Рішення: Якщо сплески System CPU збігаються з затримками — переходьте до ETW трасування або ізолюйте стек драйверів (NIC/USB/аудіо/сховище/GPU).

Завдання 16: Захопіть базове ETW трасування з WPR (режим «доведіть це»)

cr0x@server:~$ wpr -start generalprofile -filemode
WPR has started the profile.

cr0x@server:~$ wpr -stop C:\Temp\stutter.etl
WPR has stopped the profile.
The trace file has been saved as C:\Temp\stutter.etl.

Що це значить: У вас тепер є трасування, яке можна відкрити в Windows Performance Analyzer, щоб побачити DPC/ISR, планування CPU, диск I/O і більше.

Рішення: Якщо LatencyMon вказує на драйвер, але оновлення/відкат/тонування не допомагає, ETW — як зробити справжню підмогу (або вирішити замінити апарат).

Шлях виправлення: драйвери, BIOS, USB, аудіо, мережа, GPU, сховище

1) Спочатку порядок з драйверами: оновіть, потім відкотіть, якщо потрібно

Більшість проблем DPC-латентності — це проблеми якості драйверів. Перший крок — банальний: переконайтеся, що у вас стабільні релізи для чипсета, NIC, аудіо та GPU. Але «оновіть усе» може створити нові проблеми. Ставтесь до цього як до управління змінами:

• Оновлюйте один стек за раз (GPU першим, потім чипсет, потім NIC/аудіо).
• Відтворіть проблему і виміряйте після кожної зміни.
• Якщо після зміни проблему не відтворюється — зупиніться. Ви зробили свою роботу.

Так, це повільніше за хаотичні оновлення. Але це також запобігає перетворенню ПК на місце для судово-археологічних розкопок.

2) BIOS і чипсет: де латентність ховається

Якщо LatencyMon показує ACPI.sys, Wdf01000.sys або дивні періодичні сплески, підозрілий BIOS/прошивка. Оновлення BIOS часто включають:

• Покращені таблиці ACPI або методи керування живленням.
• Оновлення AGESA/мікрокодів, що впливають на поведінку простоїв CPU.
• Виправлення сумісності PCIe для певних GPU або NVMe дисків.

Але не починайте перемикати кожну опцію BIOS, наче ви розмінуєте бомбу. Використовуйте невеликий набір високоефективних тестів:

• Вимкніть «Global C-state control» як діагностичний A/B тест, а не як постійне рішення.
• Вимикайте spread spectrum лише якщо шукаєте нестабільність такту (рідко).
• Переконайтеся, що XMP/EXPO стабільні; нестабільна пам’ять може виглядати як «випадкова затримка».

3) Мережа: interrupt moderation проти латентності

NIC оптимізовані для пропускної здатності. Ігри чутливі до латентності. Два звичних перемикача підводять людей:

• Interrupt Moderation: пакує переривання, щоб зменшити навантаження CPU. Чудово для серверів. Іноді погано для ігор/аудіо.
• Energy Efficient Ethernet / енергозбереження: може вносити затримки або дивну перенастановку лінку.

Стратегія тестування: якщо вимкнення Wi‑Fi або зміна налаштувань NIC усуває затримки, залиште зміни і задокументуйте. Якщо вам потрібен Wi‑Fi, спробуйте іншу версію драйвера або інший адаптер. Залізо може бути поганим — і це нормально.

4) USB: патерн «хаб-апокаліпсис»

USB обманливо складний. Хаби, isochronous аудіо-ендпоїнти, миші з високою частотою опитування, пристрої захоплення та «розумні» периферії можуть генерувати часті переривання. Дві тактики працюють у реальному житті:

• Перемістіть критичні пристрої (миша, клавіатура) на порти материнської плати, а не на фронтальні хаби.
• Уникайте «нашарування»: не підключайте аудіоінтерфейс + вебкамеру + захоплення + контролер RGB до одного хабу/контролера, якщо можете цього уникнути.

Іноді вирішення буквально таке: від’єднати LED-стрічковий контролер за $12. Це принизливо, але ефективно.

5) Аудіо: покращення, ексклюзивний режим і перемога «простого конвеєра»

Аудіо-тріск — один із найчистіших індикаторів проблем DPC. Windows аудіо працює за дедлайнами. Якщо ви пропустите — почуєте це. Остерігайтеся:

• «Покращення» (віртуальний супровід, приглушення шуму, вендор-складові DSP), що додають CPU і складності драйверів.
• Сторонні віртуальні аудіо-пристрої.
• Bluetooth-гарнітури (складний стек, узгодження кодеків, енергозбереження).

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

6) GPU: стабільні драйвери, розумні оверлеї і стабільність живлення

Стек драйверів GPU важкий. Він також взаємодіє з кожним оверлеєм і інструментом захоплення, що ви встановлюєте. Якщо LatencyMon вказує на драйвери GPU (поширені імена: dxgkrnl.sys і модуль ядра вендора), ваш шлях виправлення:

• Чиста інсталяція драйвера GPU (уникайте «опціональних/бета» під час діагностики).
• Вимикайте оверлеї по черзі (Steam, Discord, GeForce Experience, інструменти запису).
• Перевіряйте TDR-події (Event ID 4101). Якщо є — це стабільність.
• A/B тестуйте HAGS і налаштування режиму подачі кадрів.

Жарт #2: RGB‑софт — єдина робота, що може впасти і FPS, і вашу гідність одночасно.

7) Сховище: затримка не потребує високого використання диска, щоб бути дисковою

Сховище може викликати затримки трьома шляхами:

1. Події тайм‑аут/скидання (storahci/storport warnings): система паузить, щоб відновити шлях до пристрою.
2. Нюанси прошивки/драйвера: баги прошивки NVMe, стани енергозбереження контролера або баги драйверів можуть створювати піки латентності.
3. Фонові I/O: індексація, антивірус, запис кешу шейдерів, патчери і хмарні синки, що конкурують у невдалий момент.

Практичні поради по сховищу, що тримаються у продакшні:

• Тримайте прошивку NVMe оновленою, але знову: по одному зміненню за раз.
• Переконайтеся, що гра та її shader cache не на проблемному або підключеному по USB диску.
• Слідкуйте за Event ID 129; якщо бачите їх — припиніть звинувачувати рушій гри.

8) Режим «MSI» і заяложена тема маршрутизації переривань (використовуйте обережно)

Message Signaled Interrupts можуть зменшити контенцію спільних переривань, але примусове включення MSI через реєстрові інструменти без розуміння може поламати пристрої або ускладнити діагностику. Моє правило:

• Якщо ви не впевнені як відкотити зміну — не робіть її.
• Якщо робите — застосовуйте до одного пристрою за раз (зазвичай GPU або NIC) і повторно вимірюйте.

Три корпоративні міні-історії (чому це не лише проблема геймерів)

Інцидент через неправильне припущення: «Мережа не може впливати на аудіо»

У середній компанії з великою кількістю віддалених нарад служба підтримки почала отримувати скарги: «Мій USB-гарнітура тріщить під час дзвінків, але тільки по обіді». Машини були нові й швидкі, і аудіо-команда міняла гарнітури немов це проблема постачань.

Неправильне припущення було тонким: вони вважали аудіо проблемою рівня додатка. Драйвери були «невидимими трубопроводами». Першою реальною підказкою став користувач, який помітив, що тріск посилюється, коли починається великий синхронізований обмін файлів. Технік запустив інструмент латентності під час дзвінка і побачив часті сплески, приписані Wi‑Fi драйверу та компоненту ACPI.

Патерн «по обіді» не був таємницею. Це було засилля RF‑середовища будівлі, коли приходила більша кількість людей, плюс заплановане вікно фонової синхронізації. Поведінка Wi‑Fi драйвера з interrupt moderation і енергозбереженням створювала сплески ISR/DPC, які позбавляли аудіопотік CPU достатньо надовго, щоб пропустити буфери.

Виправлення не було «купити кращі гарнітури». Вони розгорнули стабільну версію Wi‑Fi драйвера, відключили конкретну опцію енергозбереження в політиці адаптера і перенесли важкі вікна синхронізації поза годинами нарад. Тріск зник. Аудіопайплайн був у порядку; проблема була в переривальному пайплайні.

Оптимізація, що обернулася проти: «Увімкнемо всі offload-фічі»

В іншому середовищі — робочі станції інженерів і локальні віртуальні машини — хтось вирішив «оптимізувати мережу», ввімкнувши набір фіч NIC по всім машинам. Мета була чесна: зменшити завантаження CPU при великих передачах і покращити пропускну здатність для збірок і образів VM.

Пропускна здатність на папері покращилася. Використання CPU впало в діаграмах. Всім стало приємно, бо дашборди люблять усереднені метрики.

Потім почали надходити скарги: інтерактивні затримки в RDP, ривки під час демонстрацій і аудіопроблеми під час трансляцій екрана. Машини залишалися «швидкими», але людський досвід погіршився. Навантаження, чутливе до латентності, платило за пакетування і коалесценцію.

Вони відкотили частину налаштувань: interrupt moderation зробили «адаптивним», деякі offload‑и вимкнули для конкретних адаптерів, і пом’якшили енергозбереження. Пропускна здатність залишилася прийнятною, а інтерактивність відновилася. Урок — класичний SRE: оптимізуючи одну метрику без SLO по латентності, ви створюєте невидимий біль для користувачів.

Нудна, але правильна практика, що врятувала ситуацію: «контроль змін і базові образи»

Машини студії, що збиралися для маркетингових роликів, також служили як захоплюючі риґи. Що кілька тижнів хтось оновлював «всі драйвери, що здаються старими», бо ці риґи не вважалися продакшеном. Потім, перед дедлайном, сесії захоплення показали сплески часу кадру і пропущені аудіо-кадри.

Один інженер нарешті ввів нудне правило: кожен риг отримав базовий образ, маніфест драйверів і журнал змін. Оновлення відбувалися тільки в вікні технічного обслуговування, по одному компоненту з коротким тестом захоплення і збереженим трасуванням.

Наступного разу затримки знайшлися за годину: нещодавно оновлений драйвер USB-пристрою захоплення почав генерувати підвищені DPC-часи при певних роздільностях. Вони відкотили драйвер, відправили звіт вендору з прикріпленим трасуванням і встигли в дедлайн.

Це не були геройські дії. Це була несексуальна дисципліна базових образів. У продакшн‑системах «нудне» часто означає «надійне».

Поширені помилки: симптом → корінь → виправлення

• Симптом: «Гальма кожні кілька секунд, особливо онлайн.»
  Корінь: DPC-сплески NIC/Wi‑Fi драйвера; interrupt moderation/енергозбереження; багована версія драйвера.
  Виправлення: Вимкніть Wi‑Fi для тесту; оновіть або відкотіть драйвер NIC; налаштуйте interrupt moderation; вимкніть EEE/енергозбереження для діагностики.
• Симптом: «Аудіо тріщить під час ігор або дзвінків.»
  Корінь: DPC‑голодування від Wi‑Fi, USB або ACPI; аудіо‑покращення додають обробку; розмір буфера занадто малий для нестабільної системи.
  Виправлення: Спростіть аудіо-ланцюг (вимкніть покращення), перемістіть пристрій на інший контролер USB, тестуйте дротовий Ethernet, оновіть чипсет/BIOS.
• Симптом: «Випадковий великий ривок, потім все гаразд.»
  Корінь: Скидання сховища (Event ID 129) або GPU TDR (Event ID 4101).
  Виправлення: Для сховища: прошивка, кабелі, драйвери контролера. Для GPU: відкотити OC/undervolt, чиста інсталяція драйвера, перевірити подачу живлення.
• Симптом: «Гальма тільки з великою кількістю USB-пристроїв.»
  Корінь: Перевантаження USB-хаба/контролера; проблемний драйвер периферії; конфлікт isochronous-пристроїв.
  Виправлення: Зменшіть ланцюги хабів, підключіть критичні пристрої напряму, видаліть софт для RGB/керування, оновіть драйвери USB/чипсету.
• Симптом: «Гальма почалися після оновлення BIOS.»
  Корінь: Змінені за замовчуванням налаштування енергоменеджменту; нестабільне тренування пам’яті; змінена поведінка PCIe.
  Виправлення: Скиньте BIOS до дефолтів, заново застосуйте лише необхідні налаштування, підтвердіть стабільність RAM, розгляньте відкат BIOS, якщо є стабільна опція.
• Симптом: «LatencyMon показує ACPI.sys або Wdf01000.sys.»
  Корінь: Часто проксі: драйвер пристрою взаємодіє з ACPI, менеджментом живлення або фреймворком, що викликає затори.
  Виправлення: Корелюйте зі змінами пристроїв (USB/NIC), оновіть BIOS/чипсет, тимчасово вимкніть глибокі C-states як тест, потім звузьте список пристроїв шляхом їх відключення.
• Симптом: «Гальма тільки під час запису/стриму.»
  Корінь: Хуки оверлею/драйвера захоплення, тиск на GPU, запис на диск, DPC-сплески USB-пристрою захоплення.
  Виправлення: Тестуйте без оверлеїв, змініть метод захоплення, перенесіть запис на інший диск, оновіть драйвери пристрою захоплення, зробіть ETW трасування для перевірки.
• Симптом: «Усе гаразд у бенчмарках, але не в реальному геймплеї.»
  Корінь: Бенчмарки не викликають ті самі переривання (голос, мережа, античит, запис кешу шейдерів).
  Виправлення: Вимірюйте під час відтворення реальної сцени; ізолюйте, вимикаючи мережу/USB/овeрлеї; використовуйте WPR трасування.

Контрольні списки / план крок за кроком

Чекліст A: 30-хвилинний триаж (мінімальна перевірка)

1. Перезавантаження. Не обговорюйте цей крок.
2. Переключіть план живлення на High performance для тестування.
3. Вимкніть оверлеї (по одному) і повторіть тест.
4. Відключіть неважливі USB-пристрої і повторіть тест.
5. Вимкніть Wi‑Fi (або Ethernet) і тестуйте з одним мережевим шляхом.
6. Запустіть LatencyMon на 10 хвилин під час відтворення затримки; зафіксуйте топ-3 ISR/DPC винуватців.
7. Перевірте Event Viewer на GPU TDR (4101), WHEA попередження (17/18/19) і скидання storport/storahci (129).

Чекліст B: Послідовність виправлень (контроль змін для одної машини)

1. Зробіть базу: запишіть версії драйверів (GPU/NIC/chipset), версію BIOS, збірку Windows.
2. Стабільність перш за все: приберіть розгони/undervolt; підтвердіть, що WHEA тихий під навантаженням.
3. Оновіть BIOS/чипсет якщо ACPI/фреймворк драйвери показуються і ви відстаєте на декілька релізів.
4. GPU A/B: чиста інсталяція, потім тест HAGS вкл/викл, потім оверлеї.
5. Налаштування мережі: оберіть один адаптер, одну версію драйвера; налаштуйте interrupt moderation при потребі.
6. Упрощення USB: перебудуйте порти й хаби; тимчасово видаліть вендорські набори керування.
7. Валідація сховища: шукайте скидання/тайм‑аути; оновіть прошивку SSD; перемістіть гру/записи з підозрілих пристроїв.
8. Доведіть ETW: якщо застрягли, захопіть трасування і знайдіть вузьке місце планування.

Чекліст C: «Не робіть цього» (як люди марнують дні)

• Не застосовуйте 30 реєстрових правок з відео і не запитуйте потім, яка допомогла.
• Не вимикайте спочатку функції безпеки. Виправляйте драйвери і стабільність спочатку.
• Не міняйте налаштування BIOS випадково. Тестуйте A/B одну змінну і вимірюйте.
• Не звинувачуйте гру, поки не перевірили, що система не логить апаратні або драйверні скидання.

FAQ

1) Яке число DPC-латентності вважається «поганим»?

Універсального порога немає, бо навантаження відрізняються. Для ігор/аудіо вас цікавлять піки. Система може сидіти низько більшість часу, але при сплесках до багатомілісекундних ISR/DPC вона все одно гальмуватиме.

2) Чому LatencyMon часто звинувачує ACPI.sys?

Бо ACPI залучено в управління живленням і контролі пристроїв. ACPI.sys може бути кур’єром, а не злочинцем. Шукайте кореляції: події енергоподій пристроїв, періодичні сплески і які стеки пристроїв змінювалися нещодавно.

3) Чи може сховище справді викликати мікрозатримки, навіть якщо використання диска низьке?

Так. Подія тайм‑аут/скидання — про латентність, а не про завантаження. Один скидання шляху може заблокувати потоки, що чекають на завершення I/O, навіть якщо загальний MB/s мізерний.

4) Чи варто вимикати C-states?

Як діагностичний A/B тест — так, іноді. Як постійна «оптимізація для ігор» — зазвичай ні. Це може збільшити енергоспоживання та тепло. Використовуйте, щоб підтвердити, що латентність пробудження пов’язана з енергоменеджментом, потім шукайте оновлення прошивки або краще налаштування.

5) Чи HPET вкл/викл — це вирішення?

Іноді це змінює поведінку таймерів настільки, що симптоми зміщуються, але це не надійне кореневе вирішення. Якщо перемикання HPET допомагає, розглядайте це як підказку, що таймінги/планування важливі, і заглиблюйтеся в драйвери й енергоменеджмент.

6) Чому оверлеї та інструменти захоплення викликають затримки?

Вони підключаються до конвеєрів рендерингу, планують роботу GPU/CPU і додають драйверні компоненти. Якщо вони погано поводяться або конфліктують з античитом чи плануванням GPU, вони можуть додавати джиттер. Вимкніть їх для ізоляції.

7) Мій ПК гальмує тільки коли увімкнений Wi‑Fi. Яке справжнє рішення?

Спочатку підтвердіть, вимкнувши Wi‑Fi. Потім: спробуйте іншу версію драйвера, вимкніть енергозбереження адаптера, налаштуйте interrupt moderation або замініть адаптер. Якщо це дешевий USB-dongle — це знак змінити його.

8) Чи завжди допомагає план «High performance»?

Він зменшує деякі переходи енергозбереження і може знизити джиттер, тож часто допомагає для діагностики. Для щоденного використання можете повернути Balanced після виправлення основної проблеми або зберегти план для ігор, якщо потрібно.

9) Чи безпечно видаляти випадкові драйвери, що показуються в LatencyMon?

Ні. «Показується» не означає «безпечно видаляти». Краще тимчасово відключати пристрої, відкотити драйвери або оновити від OEM/вендора чипсету. Якщо видалите не те, можна зламати сон, звук, мережу або сховище.

10) Коли слід використовувати ETW (WPR/WPA) замість LatencyMon?

Коли потрібен доказ, коли LatencyMon вказує на щось неоднозначне або коли зміни не дають результату. ETW покаже планування CPU, диск I/O, DPC/ISR хронологію і кореляцію з моментом затримки.

Висновок: наступні кроки, що не зіпсують ваш вікенд

Гальмування на швидкому ПК зазвичай не проблема сирої потужності. Це проблема дедлайнів. Щось у режимі ядра тримає CPU на підвищеному пріоритеті достатньо довго, щоб зіпсувати вирівнювання кадрів. Ваше завдання — визначити стек: мережа, USB, аудіо, GPU, сховище або прошивка енергоменеджменту.

Зробіть наступне:

1. Відтворіть затримку на вимогу (та сама сцена гри, ті самі налаштування, ті самі периферії).
2. Запустіть LatencyMon на 10 хвилин під час відтворення і запишіть топ-винуватців.
3. Перевірте Event Viewer на скидання GPU, WHEA-попередження та скидання сховища.
4. Ізолюйте: вимкніть Wi‑Fi, від’єднайте USB-пристрої і вимкніть оверлеї — по одній зміні за раз.
5. Застосуйте цілеспрямовані виправлення: відкат/оновлення драйверів, оновлення BIOS/чипсету, налаштування плану живлення, очищення USB-топології.
6. Якщо ще застрягли — захопіть ETW трасування з WPR і проаналізуйте DPC/ISR + планування CPU навколо моменту затримки.

Якщо ви будете ставитися до цього як до реагування на інцидент, а не як до містицизму, ви виправите проблему — і точно знатимете, що саме виправили. Ось різниця між «налаштовано» і «стабільно».