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

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

Эта хреновина (ДЦП Мон) даже не пашет на 10х64 ,а на оф.сайте написано якобы робит. В пустой нижней полосе должно быть всё красное до упора вправо, ибо HDD , а там вообще пусто. Т.е. не фурычит прога. Винда не сборка, не глючит. Повреждений. если верить sfc /scannow, нет.

тоже в играх картинка не плавная, хотя фпс более-менее.
(и5 6500 +1066, без разгона всё, т.к. h110)
Прочитал всю тему. В принципе полезного мало, всё сводится к отключению энергосберегаек, что не айс. Это не вариант воще я бы сказал.
По-поводу ограничений в RTSS (или как там его) как правильно надо настроить на 60гц монике? Плавности нет, вообще, дёрганое какое-то всё. Если я правильно понял надо лок на 60 фпс на видяхе, а в игре всинх включать или выключать надо, или фаст? Или что-то ещё? Тут кто-то писал надо проц тоже ограничить , чтобы не молотил впустую. Первый раз такое вижу. Это как вообще сделать можно??
Играю я на среде-низких обычно (кроме текстур) + фаст всинх, фпс всегда на таких настройках как минимум 50, один чорт всё дёрганое.

Rm76, фаст синх это дичь какая-то, то работает, то не работает, еще и тиринг от него. Тогда уж проще вообще вертикалку нафиг любую выключить и играть с тирингом... И не напрягать сухой орех в черепе насчет инпут-лагов всяких По православному же нужно принудительно в драйвере ограничение сделать на 60 фпс, вертикалку force on, и трипл буфер on, кто-то говорил в DX приложениях он не пашет, кто-то говорит пашет, но я включаю всегда, разница вроде чуть-чуть есть, мышка отзывчивее. Всё делается в пару кликов через NV_inspector и не требует установки, RTSS по сути и не нужен.

Ну я не провидец, откуда я знаю что было сделано. Тут тогда только один выход, копать почему всё сбрасывается, и как-то в ЗАГРУЗЧИК WINDOWS вписывать эти самые команды, чтобы еще на уровне загрузке ОС они применялись и не приходилось перезагружаться

COЛb, спасибо за пояснение. А можно подобное запилить с RTSS ? Просто я ещё фпсиков смотрю сколько и иногда карточку чутка пинаю через АБ. Мне инспектор не очень удобно получается. Кстати где его взять, НВ инспектор этот?
Если так сделаю нормально будет?
1) в RTSS лок на 60 фпс
2) в дровах всинх вкл
3) тройной буфер вкл
3)в игре всинх выкл
4) в игре тройной буфер выкл ???
и ещё один момент, поскольку лок на 60 кадров, получается уже не нужно в дровах выставлять макс. производительность для ВК ?

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

Грамотей... Как ты в GTA поставишь ограничение, нет там такой функции. А если принудительно не выставить в RTSS или NV Inspector ограничение в 60 фпс. Vsync будет валить 60 фпс до 30 кадров при любой просадке. И вообще без вертикалки играть мазохизм для имбецилов-дрочеров, свидетелей инпут-лага.

Ставь лок в RTSS, в чем проблема то? А Инспектор на 3дгуру как и РТСС, всё там лежит..
Остальное через панель невидии.

COЛb все понятно с тобой. с моей стороны вопросов нет.

Rm76, всегда в дровах форсируй всинх! Ибо "игровой" всинх постоянные глюки вызывает, ведьмак, гта5, и прочие игори этим грешат. Уже все проверено-перепроверено 1000 раз и обсосано. Не слушай всяких даунов любителей стеклянных ковриков и полированных мышек) Которые сосут в шутанах, списывая это на инпут-лаги, неправильные коврики и мышки)))))))

Кстати в гта 5 встроенный всинк действительно кривой. Когда я играл он работал в наркоманском режиме или 60 фпс или 30 прямо в игре на лету выбирая одно из двух... Может сейчас там и нормально всё будет, даже проверить объективно не смогу, так как и карточки нет на которой играл и какая там была версия драйвера и игры тем более не помню.
Вот только, что за накромания использовать синхронизацию и предел одновременно? то есть оно конечно будет работать, но смысла мало.
Самое на мой взгляд оптимальное это или адаптивная синхронизация или просто лимит. Просто лимит лучше когда железо не может выдать нормальный фпс для вертикальной синхронизации.

А кто знает почему так: выключен в биосе HPET (запрещено), мат. плата гигабайт, частота таймера составляет 1,94, выполняешь команду: bcdedit /set useplatformclock true и частота таймера становится 3,57! Не 24 мгц, а 3,57, и почему меняется, если запрещено. С включенным HPET на 24 мгц вообще сплошные фризы, попробовал и выключил. Теперь думаю какая из этих частот правильная 1,94 или 3,57?

(иногда для пользы дискуссии приходится повторяться)
Те же проблемы, но только в последних и недавних играх (при чём, тех, что с подозрением на использование deffered rendering и многопоточность). До недавнего грешил на то, что проблема "в dx11 и выше", но Сталкер Lost Alpha DC с треском опроверг эту версию. В рендере r4, фпс ниже некуда: 24-42 (настройки все на пределе, 2,5k + dsr x4), плавность есть! И играть приятно! И снова повторю себя из ранних постов: у DX11 есть проблемы с работой многопоточного распределения ресурсов. Для Сурвариума есть даже фикс (Князева), который эту вещь специально отключает. Возможно плавности у многих игр нет именно из-за этой проблемы а паскали, наверняка, затачивались на работу именно в таком режиме.

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

Таймеров больше, чем два. И есть даже смешаные режимы их работы (когда винда сверяет один с другим или что-то вроде этого). Не буду голословить напамять. Почитайте в инете подробнее. Одно ясно точно: чем ниже частота таймера, тем меньше ресурсов он забирает и отзывчивее получается, но тем и грубее его показания и измерения на нём. Поэтому, 1,94 или 3,57 - выбирайте по своим ощущениям.

Да что там проверять, я вот сейчас играю в GTA Online, если ограничение отрубить в RTSS всунк валит то 30, то 60 фпс, ничего они не пофиксили, это видимо особенности двигла. В Ведьмаке у меня микрошуттеринг\статтеринг был, бежишь на плотве и окружение тык-тык-тык так подергивается как-будто подгрузки какие-то, ВНЕ ЗАВИСИМОСТИ ОТ НАСТРОЕК ГРАФИКИ И РАЗРЕШЕНИЯ. Время кадра прыгало как взбешенное на Vsync 60 fps = 16,6 ms должно быть, а оно скакало то 23-18-12 ms. Вообщем дичь творится если не залочить фпс. Ну и главное, САМО ОГРАНИЧЕНИЕ ничего не даёт без Vsync как не подбирай фпс, ТИРИНГ - РАЗРЫВЫ всё равно будут, хоть обосрись, ограничение же просто фпс лочит на определенной цифре, а синхронизация каждый кадр с частотой герцовки СИНХРОНИЗИРУЕТ дожидаясь из буфера кадры безразрывно, это вообще разные вещи, с чего это наркомания?

Да да, прям один в один описал

У себя заметил ещё (Ведьмак3), что лок на 60 + Vsync в драйвере даёт местами, где плотная "застройка" (деревушка какая-нибудь, или узкий проход), вот такие "тык-тык-тык", даже если будет стабильно 60 фпс. Вся картинка как будто перемещается сразу на несколько десятков пикселей. Если переключить на фаст синк + лок 60 - "тык-тык-тык" значительно меньше, но в целом плавность ниже ВЕЗДЕ, во всяком случае так ощущается , возможно потому что пропадает некоторая "ватность". Пока не решил что оставить на постоянку. Оба режима далеко не идеально.

Так и не понял, надо в дровах "высокую производительность" для приложения ставить если лок на 60 фпс + Vsync ?

т.е. на 1.94 задержки будут самыми минимальными?

а критична ли точность таймера для отрисовки игр?

kostik1966beta, Для виндовс ос в системе 3 основных таймера:
TSC, он работает от частоты ядер процессора, он и используется по умолчанию, т.к. самый быстрый, зачастую его частота это обычно частота проца в состоянии P0/на 100. На пенках изначально он вообще был равен частоте процессора, там и были траблы.
ACPI Power Management Timer, используется самой ACPI, при инициализации оборудования, так же может использоваться Windows, при отключении HPET используется как высокоточный для мультимедия и синхронизации с TSC. Частота 3.579545 мгц.
И собственно HPET...
Самым оптимальным считаю удалить параметр useplatformclock и включить HPET. В таком случае будет использоваться TSC(1.94 в вашем случае), а при необходимости для синхронизации, либо определенных приложений будет использоваться HPET, там где он реально нужен. Все эти супертвики наверно были целесообразны только на core 2 quad, там были некоторые проблемы с TSC, не было поддержки rdtscp, Invariant TSC. И при релизе WIN8, там траблы в самой винде были при разгоне...
Сколько не тестировал на разных системах intel nehalem, ivy bridge, а сейчас и на Ryzen 1600, у меня были только отрицательные эффекты. Раньше жестко пулял в CS, интересовался всем этим...
Доступ к TSC и ответ от него происходит всех быстрее.

Deviance
Спасибо за подробное и толковое разъяснение, сделал все, как Вы написали, изначально у меня так и было, и добавление этого параметра только вносит путаницу, т.е. чтобы добиться, работы системы на ACPI Power Management Timer с частотой 3,57 нужно выключить HPET и активировать параметр. А если HPET на каких-то биосах асус не отключается, то 3,57 не будет никогда, а будут стабильные 24мгц при которых задержки по 300нс

kostik1966beta, сейчас на overclock.net уже популярнее твик стал просто отключать hpet в биос и ставить ОС)) Объясняя это тем, что наверно ACPI PM быстрее отвечает, чем HPET, синхронизация с TSC быстрее происходит, по факту же даже чуть чуть медленнее... Если интересно, можно тут почитать: http://aakinshin.net/blog/post/stopwatch/. Потом под плацебо с пеной изо рта доказывают, что все работает)))

Добавлено спустя 2 часа 4 минуты 24 секунды:
Update: не смог чуть чуть копнуть тему и слиться, нырнул с головой...
От отключения HPET может быть профит еще в одном случае! Когда Производитель МП неправильно задал настройки HPET... Есть у нас такой документик IA-PC HPET Specification, начиная с 10 страницы описываются все настройки и местоположение их в памяти. С помощью RWEverything чекнул у себя в дампе все настроечки на ASrock AB350 Pro4 и немного удивился, что разрядность таймера стоит 32 бит, вместо 64 и стоит настройка совместимости LegacyReplacement IRQ Routing, которая на современном железе вообще не уперлась... Проц чтоб получить данные читает 2 раза по 32 бита, а не один 64. Хотя 64 бит режим совместим с 32 бит приложниями... Если первые 64 бит с главными настройками недоступны для записи, то бит включение/выключения таймера и LegacyReplacement IRQ Routing доступны, выключение LegacyReplacement IRQ Routing сразу несколько меняет ощущение работы мыши(Logitech G502), выключение таймера медленно вешает систему в течении двух минут))) И стоит учитывать, что никаких useplatformclock не стоит, TSC используется по умолчанию. Так и приходится писать в асрок еще раз, то они XHCI hand-off включат и уберут, а учитывая новый AMD PSP, просто так после AMIBCP не прошьешься - беда, то теперь HPET в режиме совместимости 32 бит в 2к17 на мп под 4-8 ядер, когда этот режим просто изначально делали для 32 битных процессов на lga 775 просто без физической поддержки 64 бит. И видимо я все таки был неправ, не у всех плацебо на overclock.net)))
Так же кому интересно у себя чекнуть, можно считать все настройки таймера с ACPI таблиц, в аиде так же можно посмотреть и разрядность и наличие режима совместимости со старыми методами прерываний.

Deviance, самый быстрый таймер -не всегда самый точный и правильный. Никто не говорил, что нужно обязательно и неукоснительно выключать HPET.
непосредственно в моём случае, мне удобнее на TSC invariant. Удалил винду PRO версию, поставил LTSB и вуаля, TSC invariant по умолчанию. Без принудиловки в виде HPET.

Так-же ребята из ветки райзенов, показывали скрины и видео после отключения hpet. Некоторым даже +15 фпс в ведьмаке3 добавляло.

Другие наоборот, писали что им лучше было С вкл. HPET. Те. что хочу сказать. Тут не панацея.А каждому что и как будет удобнее.
А это исключительно методом собственных проб.

Если есть что у вас ещё посоветовать, буду благодарен.

korino по умолчанию всегда используется TSC во всех Windows начиная с 7 и линукс ядра 3.2. В случае с райзеном, принудительно "включался HPET" там старой версией Ryzen Master, там она его не включала, а использовала в качестве основного таймера для ОС.(bcdedit /set useplatformclock yes). И эти пользователи райзенов просто ворачивали использование TSC по умолчанию обычным способом(bcdedit /deletevalue useplatformclock), либо как вариант выше, перехедом на ACPI PM(отключением HPET в BIOS). Стоит учитывать то, что даже при использовании по умолчанию TSC, HPET используется для синхронизации и мультимедиа приложениях... Поэтому именно отключение HPET в биос может дать результат, если он настроен изначально не так, как в моем случае с AB350 Pro4 на последнем BIOSe, твик "useplatformclock" на мой взгляд в любом случае не улучшает работу системы, раньше он лишь избавлял от бага рассинхронизации при разгоне шиной на процах без rdtscp, Invariant TSC.

Возможно есть какая-то зависимость от подключения монитора, по HDMI у меня не полный диапазон цветов (16-255) был. Без ковыряния в панельке нвидиа: черный - серым был, в Google Chrome при просмотре видео на youtube разрывы кадров ползли без синхронизации. по DVI нет подобного, включена вертикалка или нет глобально в драйвере, тиринга нету при любых раскладах. В Ведьмаке я поборол статтеры так: удалил GeForce Experience с DDU, поставил чистый драйвер без всякой дичи отключил в игре всинх, форсанул его через драйвер, игровое ограничения FPS выкл, а в RTSS наоборот на 60 фпс залочил, отключил HPET в биос. Всё игра идеально плавна, 60 FPS, 16 ms, никаких статтеров, подергиваний, подгрузок, абсолютная плавность.