1. Ликбез по прерываниям.

2. Ссылки.

3. Борьба с прерываниями.


Позднее дополню каждый раздел.
Все проблемы у нас связаны с тем, что windows относится к операционным системам с вытесняющей многозадачностью.
Вытесняющая многозадачность требует обработки системного прерывания от аппаратного таймера. По истечении кванта времени, отведённого процессу, происходит прерывание и вызывается планировщик процессов. Частота вызова планировщика критична: слишком частый его вызов будет расходовать процессорное время впустую.
Единственное, что мы можем изменить - это увеличить время кванта и поменять соотношение квантов времени на активную задачу и задачи в фоне, за это отвечает параметр в реестре
Win32PrioritySeparation
По умолчанию
0х26 кванты 18:6 = Оптимальный вариант.
https://github.com/keoy7am/Win32PrioritySeparationTool
При этом само время кванта зависит от системного таймера.
При системном таймера 15.625 мс оно будет больше, чем при 1.0 мс.
Высчитывается время системного таймера * тики.
1 тик= 3 кванта
Для системного таймера 0.5 мс фону тогда буде даваться 0.5мс*6/3 = 1мс из каждых 4 мс.
При 1 мс - 2мс из каждых 8мс.
При 2 мс - 4мс из каждых 16мс.
Для борьбы с фризами оптимально выставить системный таймер 0.5мс.

SMI-прерывания зависят от BIOS/UEFI и оборудования.
Отключаем все лишнее, отключаем энергосохранение, скорость вентиляторов фиксируем, это все, что мы можем сделать.
В нашем плане энергосохранения выбрать оценка для поднятия частоты вместо 15 мс максимум 5000 мс.
Есть программа Intel SMI Latency Checker
Для гипервизора - отключаем поддержку виртуальных машин в биосе.

Про прерывания на уровне ядра и пользователя в windows.


Наш пользовательский процесс может иметь следующие приоритеты:
Idle - 4
Below Normal - 6
Normal -8
Above Normal -10
High -13
Real-Time -24
Внутри процесса мы можем задать приоритет для его потоков:
Idle дает итоговый приоритет процесса с потоком 1, кроме real-time, там он его просто снизит до фиксированной 16
Lowest -2
Below Normal -1
Normal 0
Above Normal +1
Highest +2
Time Critical +7

Итоговый приоритет потока - это сумма приоритетов процесса и потока.
31 - максимум
Real-Time - от 16 до 31.
При этом даже максимальный 31 приоритет не лает нам возможности подняться выше уровня Passive/Low(0), поэтому любое прерывание на нашем ядре прервет нашу программу.


Программы для оценки прерываний:


Настройка прерываний


Борьба с прерываниями.
Бороться надо двумя путями.
Первый путь - уменьшить само количество прерываний=их частоту.
Частота прерываний за 1 секунду до 10000 считается еще неплохой.
Второй путь - уменьшить длительность прерываний.
Есть еще третий путь - освободить от прерываний нужные нам ядра.

Отключить VSYNC.
Включить тройную буферизацию если процессор успевает рендерить, то компенсирует воемя двух кадров: 2*1000 мс / частоту кадров в Гц
Краткий список исследований по психофизиологии:
Watson (1986): Задержки <5 мс незаметны.
Kelly (1979): Порог фликера <2 мс.
Burr & Ross (1982): 10% кадра = 100мс/частоту кадров (при движении).
Clayton (2018): 1–2% кадров= 1000мс*процент пропуска кадров (10–20 мс/с) незаметно.
Carrasco (2011): <5–10 мс при внимании.
Hoffman et al. (2017): <3 мс с размытием.
Swafford et al. (2016): <4 мс, 2% (20 мс) при редких фризах (реже 1 раза в секунду).
Digital Foundry (2025): 0.125 фриза/с=0.125*1000мс/частоту кадров Гц) заметно при частых повторениях.

Для 120 Гц:
1982-0.833мс
2025-1.042мс


Снизить частоту опроса мыши до 125Гц.

Главные правила для таймеров:
Таймеры используются для времени (QPC) и для системных прерываний=тиков.

При этом возможны разные комбинации таймеров.


bcdedit /set useplatformtick no (отключаем RTC и включаем TSC для тиков)
bcdedit /set useplatformclock no (отключаем HPET и включаем TSC для времени QPC)
bcdedit /set disabledynamictick yes (отключаем динамическое изменение частоты системного таймера - влияет только на тики)
bcdedit /set tscsyncpolicy Enhanced (включаем улучшенную синхронизацию TSC-таймера)
HPET не следует отключать в биосе и в диспетчере устройств.
Посмотреть текущую конфигурацию можно с помощью команды
bcdedit /enum


Обсуждение проблем ОС и оборудования: задержка реакции системы (latency), микроcтаттер, инпутлаг, фризы.

Перед тем как задавать вопросы, просьба прочитать FAQ

Осуществлять мониторинг программой Latency Monitor нужно в течение 1 минуты, в состоянии простоя системы т.е. без дисковой, сетевой активности, и любой другой, с выключенным ав и приложениями в трее и автозагрузке,
не раньше чем через 2 минуты после загрузки системы.
Не двигаем мышку и не используем клавиатуру в момент измерений. Потом остановка и скриншот.

Презентация NVIDIA (на англ.) о проблемах статтеров, фризов и лагов (терминология, описание и причины возникновения)

т.е. каждый раз после загрузки надо делать?


а по простому?

если 13 бит не установлено то счетчик 32х битный. как можно считать 2 раза по 32 из 32х бит мне непонятно.
бит 15 включает режим совместимости, добавляет лаги.

13 COUNT_SIZE_CAP Counter Size: • This bit is a 0 to indicate that the main counter is 32 bits wide (and cannot operate in 64-bit mode). • This bit is a 1 to indicate that the main counter is 64 bits wide (although this does not preclude it from being operated in a 32-bit mode).

Hpet- это 64 битный счётчик).

13-ый и 15 биты в тех регистрах, Это Read -only и по спекам Hpet- их нельзя менять, софт не должен туда лезть так как они зарезервированы не для Ос.

15 LEG_RT_CAP LegacyReplacement Route Capable: If this bit is a 1, it indicates that the
hardware supports the LegacyReplacement Interrupt Route option.

Конкретно это бит всего лишь индикационный, и показывает поддерживает это железо этот режим работы таймеров или нет.

Для использования должны выполнятся 2 условия:

LEG_RT_CNF LegacyReplacement Route:
• 0 – Doesn’t support LegacyReplacement Route
• 1 – Supports LegacyReplacement Route
If the ENABLE_CNF bit and the LEG_RT_CNF bit are both set, then the interrupts will be
routed as follows:


Оба эти регистра, Read write= и могут использоватся для модификации софтом.

1. Software can access the various bytes in this register using 32-bit or 64-bit accesses. 32-bit
accesses can be done to offset 010h or 014h, but not to offsets 011h, 012h, 013h, 015h, 016h, or
017h. 64-bit accesses can only be done to 010h.

Добавлено спустя 38 секунд:

Читайте выше)

уменя на msi x570 tomahawk 13 бит по дефолту сброшен, т. е. 64 битный счетчик отключен.
15 бит не индикационный, меняется движение курсора, т. к. windows не использует hpet для замены других таймеров.

уставновка 13 бита зависит от производителя биоса, одни включают, другие нет.
бит 15 походу ставят на всех биосах.

Нет это не так:

15 LEG_RT_CAP LegacyReplacement Route Capable: If this bit is a 1, it indicates that the
hardware supports the LegacyReplacement Interrupt Route option


"Замены чего кого"?))),hpet = не используется в windows по умолчанию))), он используется по запросу софтом, а причём тут RTC?))).



я вам уже написал что это рид онли регистры, комбинация их зависит от поколения чипсета/разрядности ос/ и поколения цпу амд/интел

Остальное считайте и думайте как хотите, мне это порядком надоело

Эффект то есть?

1. Включить HPET в биос.
2. Включить HPET в Windws 10:
bcdedit /set useplatformclock yes
3. Включить 64-bit для HPET - бит 13 в 1.
4. Отключить режим совместимости - бит 15 в 0.

Все 4-ре пункта надо сделать иначе не работает.

Тут я выключаю всегда, в моём случае это значительно лучше чем в дефолте.
В биосе всегда должно быть включено, по крайней мере если железо относительно новое и не допотопная ОС стоит.
3 и 4-й пункты вообще никогда не заморачивался.

Ещё один фактор в копилку потенциальных проблем: https://www.techpowerup.com/278548/nvid ... 09-drivers

У меня и на 442.74 "рекомендованный" глобальный параметр V-sync по выбору приложения

Согласен. Насколько я помню они всегда рекомендуют от приложения.

Привет, никто не сталкивался с процессом ntoskrnl.exe, который дает задержку? В гугле ничего конкретного не обнаружил.

Это ядро ОС и оно не даёт задержку иначе бы вой стоял повсеместно. Ищите проблему если она есть в другом месте.

Добавлено спустя 27 минут 42 секунды:
Для тех кто поковырял таймеры.
Значение по-умолчанию соответсвует:
bcdedit /deletevalue useplatformclock
То есть не нет или да, а ничего. Система сама решит. Предложенный бенч использует нет или да, но не удаляет за собой явное указание.

В биосе выключил и в системе тоже. Это как то относится к моей проблеме?

Не надо выключать в биос и системе до тех пор пока вы не убедитесь, что вы подвержены проблеме. Принудительное отключение может не позволить софту который хочет воспользоваться HPET нормально работать.
Например у меня включён HPET в биос и ничего не указано в системе. По-умолчанию HPET не используется.

Понял. Сейчас буду эксперементировать.

Знать бы в каком...

Смущает что этот экзешник постоянно дает задержку. В какой бы момент я не запустил программу.

Вообще ни в каком. Надо для начала разобраться (научиться читать) то что показывает Latencymon. И разобраться по существу, например, с тем что запуск любого приложения или игры или любая другая нагрузка генерит "задержку".
Так вот, верхние две строки отображают значения measured (измеренные программой), а нижние - reported самими процессами или виндой. Какой процесс и почему репортит высокие значения - нужно сопоставлять с тем что вы в этот момент делаете с системой. Нормально ли работает система в плане задержек DPC вообще принято в простое оценивать.

На вашем скриншоте нормальные показатели и нет аномалий. Часто на месте вашей "высокой задержки ntoskrnl" оказывается драйвер nvlddmkm.sys (я сильно подозреваю, что данная тема несёт в названии указание на проблему с Nvidia именно поэтому )
Однако любой внимательный пользователь с лёгкостью заметит что нвидиевский драйвер даёт spike по reported DPC routine time в момент любого переключения P-state видеокарты. Вот, для примера заснял вам скриншотик просто запустив старенькую игру. Некоторые увидев это сразу бы закричали - ахтунг, памагите, у меня Нвидия ДПЦ! Но я знаю что с моей системой всё хорошо. В покое показатели отличные, да и если P-state видеокарты не менять а запустить Latencymon скажем уже после запуска игры, будет достаточно красиво

Короче, узнать о том что существуют задержки DPC и найти программу мало. Надо ещё хоть немного разобраться, что же она показывает и почему.

День добрый

Какая версия ос и билд?, целостность ос в порядке?
wdf01000 очень высокий, что у вас из оборудования есть, опишите подробно конфиг - есть сторонние контроллёры юсб?, оборудование на шине юсб 3.0/2.0, что в каких портах?, на них есть энергосбережение? Оно исправно?, используется ли режим фаст бут?

Драйвера на чипсет полный комплект? я имею ввиду, самые последние?,версия биос?

Что с таймерами? - вернули всё как было как вам советовал Agiliter?

Запишите трассировку рекордером WPR https://docs.microsoft.com/en-us/window ... e-recorder из комплекта Windows Performance Toolkit

и посмотрите его потом анализатором WPA.

Не забудьте подключить Symbols для анализа-после открытия файла трассировки.

Каков нормальный диапазон? У меня его показания ещё выше, видимо т.к. специфические устройства на USB, но всё исправно и в системе нет проблем