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

Неа, не другой начиная с граничных BRAS и выше. Но вот сеть в доме/районе вполне себе другая. И я чуть выше об этом написал:



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

Вот так примерно это выглядит, мои тесты не совсем релевантны т.к. у меня "хорошая" ситуация и значительных лагов нет. Однако таким методом вполне можно заметить, что у провайдера без IPTV практически идеально ровно (первый скрин), а вот у провайдера с IPTV (ТТК) уже можно наблюдать небольшие флуктуации пинга. Там где обстановка хуже, эти флуктуации будут больше. Аплинки и сормы не имеют отношения к этому трафику.

Не помню, было здесь или нет (Системный таймер в Windows: большое изменение): https://m.habr.com/ru/post/522212/

У себя в системе через панель Нвидии выключил G-Sync для монитора с FreeSync - в том же PUBG сетка рабица перестала мерцать при движении, общий отклик и скорость движения мышки стали намного быстрее, что приходится править чувствительность сенсора в настройках игр. При всём этом никаких разрывов картинки не вижу. Хрен его знает, что они там в драйверах Нвидии чудят, но у себя заметил улучшения. Драйвер последний официальный 461.09.

Значит окно без рамки. Иначе не бывает.

OLD Hunter
Ты же меня не первый год знаешь - к чему такую глупость в мой адрес писать? Естественно, полноэкранный режим везде. Почему так, а не иначе - понятия не имею. Пишу то, что вижу конкретно у себя на своей системе. Расходится с общим мировоззрением - ну, бывает...

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

Полноэкранная оптимизация не выкл, возможно



Скажем при 300-400фпс и 240гц разрывы столь невелики что глаза не режут

OLD Hunter на каком-то этапе вы перестаете ощущать задержку монитора, инпутлаг. Также и с разрывами. Как только разница между 2 состояниями, которые вы способны распознать как разные, станут неразличимыми из-за неуловимой вашему глазу разницы, так вы сразу сможете считать, что "разрывов нет". Я именно потакому принципу и играю в шутеры. Навалить побольше фпс и отрубить все синхронизации. Итог: идеальная картинка, идеальный лаг.

И даже если фпс выше частоты развертки, в нём всё равно есть смысл.

И какая связь? ХОть включено хоть выключено, разрывы все равно должны быть. Во всех играх так. Или пубг как-то по другому работает?

Это понятно. Но на 144 и в пубг, сколько там у него фпс, 150 наверное вряд ли будут стабильные, разрывы должны быть заметны.

Некоторые игры при использовании неэксклюзивного полноэкранного режима (borderless windowed) или полноэкранного с неотключённой "оптимизацией во весь экран" (что по существу весьма близко к borderless) включали что-то вроде адаптивного vsync. То есть ты синхронизацию не заказываешь, а оно есть.

Ни разу такого не видел. В каких это играх?

На дефолтных настройках HPET таймера, курсор ватный.
Действительно отключение режима совместимости сброс в 0 15-го бита делает курсор очень чувствительным, а установка 13 бита переключает с 32bit в 64bit, повышается точность позиционирования курсора.

где и как это сделать?

Rweveveryting
http://rweverything.com/
В таблице apic ищещ смещение hpet в памяти, открывает редактор памяти, по смещению +9 DWORD от начала HPET в памяти. Устанавливаеш бит 13, сбрасываеш бит 15. Настройки hpet сразу применяются, до следующей перезагрузки системы.
#77

Ты думаешь это поможет, когда у тебя "сенса" меняется от времени суток?)

Вы зря потратили время:

Software has several ways of reading the 64 bit counter using 32 bit reads. The first is that it may halt the
counter, read the high and low 32 bits, and then restart the counter. This has the obvious drawback of
shifting the counter timebase.

If software does not want to halt the timer, it can use the 64-bit timer as a 32-bit timer by setting the
TIMERn_32MODE_CNF bit. This will cause the timer to behave as a 32-bit timer. The upper 32-bits will
always be 0.

Alternatively, software may do a multiple read of the counter while it is running. Software can read the
high 32 bits, then the low 32 bits, then the high 32 bits again. If the high 32 bits have not changed between
the two reads, then a rollover has not happened and the low 32 bits are valid. If the high 32 bits have
changed between reads, then the multiple reads are repeated until a valid read is performed.

Note: On a 64-bit platform, if software attempts a 64 bit read of the 64-bit counter, software must
be aware that some platforms may break the 64 bit read into two 32 bit reads, and therefore the
read may be inaccurate if the low 32 bits roll over between the high and low part reads.

куль, куль, куль, а выключить Hpet таким макаром можно? или HPET Number 0x00 (0)
Minimum Clock Tick 0x0080 (128) поднять, например, ну и соотв как.