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

2. Ссылки.

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


Позднее дополню каждый раздел.
Все проблемы у нас связаны с тем, что windows относится к операционным системам с вытесняющей многозадачностью.
Вытесняющая многозадачность требует обработки системного прерывания от аппаратного таймера. По истечении кванта времени, отведённого процессу, происходит прерывание и вызывается планировщик процессов. Частота вызова планировщика критична: слишком частый его вызов будет расходовать процессорное время впустую.
Единственное, что мы можем изменить - это увеличить время кванта и поменять соотношение квантов времени на активную задачу и задачи в фоне, за это отвечает параметр в реестре
Win32PrioritySeparation
По умолчанию
0х26 квант 18:6 = Оптимальный вариант
При этом само время кванта зависит от системного таймера.
При системном таймера 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Гц.[/spoiler]

Главные правила для таймеров:
Таймеры используются для времени (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 (на англ.) о проблемах статтеров, фризов и лагов (терминология, описание и причины возникновения)

Agiliter я уже путаюсь во всех этих таймерах,таймингах,clock,tick,false,true,тsc,rtc,etc... После всех ковыряний, комбинаций, синт/игровых бенчей и личных ощущений, я остановился на одной useplatformtick yes (0,5ms) против стоковых n/a (0,496ms)как наиболее приятной в игровом плане на моей системе и железе. Все это субьективный выбор и отличается от компа к компу и от юзера к юзеру.
По прерываниям определил что какие дергает, покрутил критичные, и теперь укладываюсь в лимиты Вагнарда за пару часов повседнева :если для разраба DDU это норма, то для меня подавно. И даже редкие криты за 1s тоже норма, мало ли в системе тяжелых процессов запускающихся по ивенту, расписанию или от действий юзера. Главное чтобы не частили )

А что за сборка и зачем?

OLD Hunter не хочу в рекламу, обычный репак вин 10 с личным видением репакера "чоткой" системы, куча их в инете. Зачем ? Скорее почему - нет денег на лицуху )

А зачем она нужна эта лицуха? Я про сборку, можно же образ любой поставить, не знаю там, домашнюю, лтсц или как там и т.п.

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

Да это бред полный как по мне

в результатах тестов 3dmark есть инфа о статусе HPET :проверьте кто нибудь с установленным 3dmark и стоковым нетронутым таймером его статус, пжста.

Попробовал замерить задержку в LatencyMoon и всё как 2 года назад, самый вызывающий драйвер это от нвидии Что может влиять?

нагрузка любая на адаптер, режимы энергосбережения гпу в панели драйвера, специальные режимы рендера/DWM на рабочем столе - включая рендер режимы направленные на снижения "частоты" вызова drawcalls и снижения частоты рефреша экрана при определенных условиях , для снижения жора вк. Это может как увеличивать так и уменьшать запросы к железке и задержку.


HPET по умолчанию не используется, ядро Ос использует TSC, и его вариации в приоритете при доступности, а в самой Ос(новых билдах), в виде софтовой абстракции TSC, с виртуальным таймером на "10" мгц - функция QueryPerformanceFrequency.


Проверять не нужно, т.к с зафорсенным HPET enabled, валидации тестов не будет. в 3дмарке это справедливо считается читом, т.к таймер чуть чуть "накручивает" результат.

По запросу софта, Hpet может быть задействован, например опция в HWINFO.

kiberman Ну чот показатели вообще не очень



Думал на оверлей ShadowPlay, но нет.

MurkLyaMurk а сколько под нагрузкой тогда ? В играх. До 1000ms вроде как норма, если не частит. У меня на радике ~300-500 все что с видяхой связано.зафорсенный HPET у меня наоборот снижает результаты. Вообще любое действие с таймерами где нибудь что нибудь ломает, профит на уровне плацебо а принцип работы ломает моск. Вроде бы по видяхе лучше стало после ковыряний, начал бенчить проц а там упали попугаи, некоторые проги ругаться стали. Вернулся в сток короче, пусть винда решает как ей лучше, Agiliter знаю ты говорил, но на практике лучше усваиваю. В стоке бенчи cpu пришли в норму :

WhiteRatify 550 во время игры.

Но еще самое забавное, что какие-то pagefaults по тысячи текут из-за SVCHOST.exe хз что это даже

MurkLyaMurk у меня pagefaults из-за антивиря, он все сканит в фоне.

А зачем крутили?, технический интерес как работает и что даёт?, ну в шапке темы есть рекомендации, но они как бы сказать актуальны были 10-15 лет назад,для тех платформ и цпу, может быть и можно было получить профит - в каких то случаях.

Добавлено спустя 6 минут 9 секунд:


https://ru.wikipedia.org/wiki/%D0%9E%D1 ... 1%86%D1%8B

Их есть два типа.
Soft. Означает, что страница памяти нашлась в оперативной памяти с каким-то приоритетом и как минимум временно поменяла свой приоритет на "рабочий набор". Их очень много и смотреть бессмысленно.
Hard. Не нашлась в оперативной памяти и была прочитана с накопителя или откуда-то ещё. Происходят при чтении новых данных, которые ещё не были прочитаны.
В диспетчере задач они магическим образом были переведены как ошибки страниц.
Использование различных "полезных" утилит "чистящих" Standby(кэш) переводит Soft в Hard.

Добавлено спустя 7 минут 27 секунд:
Вообще перевод некоторых терминов просто невероятно полезен.
Allocate - выделить.
Commit - выделить.
Dedicate - выделить.

а этого нет в шапке ). Крутил и по интересу, и ради профита, пару лишних фпс или лучший отклик на дороге не валяются, а инфа на практике лучше усваивается чем в теории, тем более неоднозначная. И вообще это риторический вопрос на техническом форуме, здесь все что нибудь да крутят, за тем и посещают его.

Я знаю несколько способ однозначно уменьшить DPC, когда всё в целом исправно.
0. Не нагружать 0 ядро и его второй поток. Ну или хотя бы 0 поток.
1. "Выключить с1" через idledisable в плане питания. Радикально увеличит потребление, немного снизит производительность, но цифры будут красивые.

ISR/DSR могут быть высокие из-за "дрифта" TSC. Не знаю как у MurkLyaMurk и его 9800x3d.

На Амд AM4, в Agesa 1.2.0.6 - 1.2.0.8 и более ранних, цпу с 2ССD были серьёзные баги с таймером, при выходе из сна возникал: clocksource tsc unstable. Дополнительно в разных ситуациях проявлялся сильный TSC skew между разными ядрами в CCD, особенно если был включён DF-Cstate на IF. Именно по этому в 1.2.0.8 С-STATE GLOBAL в Auto - был в disabled, как временная полумера.

Забавно как люди нахваливали эти ранние прошивки по скорости, показывая в тестах лучшие результаты, только причина этого была в багах таймера)). Всё это добро залечили в 1.2.0.С и более новых прошивках.

В контексте отключения C1 - через профиль, не знаю. Но на АМД "Short-Term Boost" при отключении с-state global в самой прошивке по идее потенциально ухудшается или должен быть не оптимальным, т.к пропадает часть телеметрии, и просто потому-что цпу становится горячее:

"Precision Boost algorithms utilize C-state residency telemetry to:
a) Calculate thermal recovery rates during idle periods
b) Predict safe boost headroom for upcoming workloads
c) Optimize voltage/frequency transitions"


Key Boost Algorithm Inputs:
- Core Utilization
- Temperature (Tctl/Tdie)
- Power Consumption (PPT)
- Current (EDC)
- C-state Residency History [Critical for ST Boost]

Что думаю будет критично при каких то режимах работы PBO2. В любом случае кратковременный буст для разного типа нагрузки должен быть выше, если цпу прохладнее, в принципе это не секрет, достаточно запустить CB рендер на одном и том же цпу, но с разной температурой. На более холодном - рез-таты будут чуточку выше. По этому выгоднее на Амд не только ставить топ охлад и добиваться минимальной температуры на камне, но и юзать C-State, в том числе для этих целей.

Возвращаясь к задержкам,у меня лично сейчас такие цифры, на "сбалансированном профиле".

#77


Понимаю что 1 минута, не очень репрезентативно, но в данном случае у меня включены CPPC2 и CSTATE enable, а цпу при этом измерении отдыхает в районе 30-35С..т.е со всеми энергосберегающими.

Из настроек: в системе последняя Агеса 1.2.0.Е /чипсет драйвер 7.04.09.545, в самой Ос(24h2 26100.4349) выключены VBS/ и "Целостность памяти" и настроены 2 политики: отключены диагностические данные и фоновые приложения. Для снижения телеметрии и сетевой активности.

Мораль сей басни, такова. Не ленитесь обновлять UEFI/chipset и Ос. Иногда это действительно полезно.

Включен C-State как советует вендор для корректной работы проца...

Я хз, у тебя такой график чистый, у меня скачки лютые, но без красных зон, просто зеленая полоса скачет с 1 до 300

у меня амд вк, они по этому показателю всегда были по лучше.

А параметры такие скорее всего, потому-что обновляю софт на мп и все драйвера в ос, и лишнего в ос ничего не ставлю. Скорее всего результаты ещё улучшили групповые политики, которые уменьшили активность фоновых служб и диагностики. А, ещё забыл один твик в групповой политике. QoS настроена так, что бы Ос не резервировала себе полосу сети. Это то же снижает паразитную активность сетевую.

9800x3d специфический камень, благо что он с 1ССD. Не знаю почему у вас такие цифры, софт наверное ещё ос, у меня на системе один Антивирус стоит и в трее кроме него и оболочки вк панели,ничего нет.

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