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

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

не у чела, а у многих и у меня в том числе

там об этом тоже написано

ctrl+shift+N сразу видно если есть проблемы с соединением

в ОВ нет влияния соединения на отзывчивость ввода

Вы может невнимательно прочитали, но это в том треде обсуждалось

ctrl+shift+N... всё видно

на этом мы и закончим. успехов.

Mr_VIT откуда у Вас такая бесцеремонная уверенность в собственной правоте ?
у меня это не три кнопки, а одна.
Я специально переназначил чтобы удобней было вызывать, это Вам должно сказать о том что я постоянно пользуюсь этой функцией.
У меня уже целая коллекция этих скринов спецом собирал, чтобы понять разницу между тем когда реакция игры тормозная, а когда нормальная.
Да, в случае когда есть потери пакетов, это конечно видно, но в остальных случаях циферки примерно одинаковые.
Если Вы такой специалист по графикам то вот вам подборка, это примерно 1/4 часть этих скринов с графиками
https://habrastorage.org/webt/ik/ac/vt/ ... 1qxu8.jpeg
https://habrastorage.org/webt/ea/om/ha/ ... egjk0.jpeg
https://habrastorage.org/webt/0d/w0/jt/ ... r7t3w.jpeg
https://habrastorage.org/webt/59/cd/68/ ... 14964.jpeg
https://habrastorage.org/webt/59/cd/68/ ... 89096.jpeg
https://habrastorage.org/webt/59/cd/68/ ... 37218.jpeg
https://habrastorage.org/webt/59/cd/68/ ... 08651.jpeg
https://habrastorage.org/webt/se/tj/3b/ ... vn0xy.jpeg
https://habrastorage.org/webt/5u/uy/qk/ ... ujlcw.jpeg
https://habrastorage.org/webt/cy/v5/r7/ ... rbcjg.jpeg
https://habrastorage.org/webt/9f/9s/ry/ ... 3v9cy.jpeg
https://habrastorage.org/webt/zr/in/lq/ ... ompfq.jpeg
https://habrastorage.org/webt/nf/6b/80/ ... 2q0jq.jpeg

что там видно?

т.е. если у нас имеются потери пакетов, а в игре я перевожу прицел, а он идет скачками, после этого я жму кнопку раскрытия оптического прицела а он раскрывается с задержкой в 1 секунду, и после этого выстрел происходит с задержкой в полсекунды, это не влияние соединения?

Короче чтобы не тратить время - в чем Вы видите причину, с отзывчивостью ввода, в моем случае, в ОВ, учитывая что эта самая отзывчивость может меняться от идеальной до ватной в течении одного раунда игры?
чтобы было проще ориентироваться
система w10 1709
все лишние службы остановлены.
антивирус не включен.
защитник виндовс остановлен
индексация, центр обновления и прочие обслуживания диска остановлены.

iG0Lka писал(а):

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

Все верно описываешь, так и есть, только инструментария все это замерить и показать нет. Приходится только по ощущениям все определять.

iG0Lka писал(а):

но кроме того вполне возможно сюда же суммируется загрузка игровых серверов. Ведь на одном сервере крутится сразу несколько матчей.

Да не, с серверами все отлично(смотрим стримы топ игроков Европы/Москвы) Проблема на уровне дома, макс района, не более.

Mr_VIT писал(а):

не у чела, а у многих и у меня в том числе

опиши подробнее, неск предложениями, читать 60+ страниц с гугл транслейтом в чем там проблема нет времени.

Mr_VIT писал(а):

в ОВ нет влияния соединения на отзывчивость ввода

Влияет, и еще как. И не только в овере, а в любой сетевой игре. Это я тебе как человек с самым худшим инетом для игр говорю. А инет я видел всякий за 12 лет. Начиналось с того что он был неотличим от локалки, затем становился все хуже и хуже, а теперь та самая зедержка и ватность(что говорит иголка, но у него легкая форма ) доходит до 300-500мс(по ощущениям, при пинге 90). Вот такие дела.

Я тоже их нажимаю - там все отлично. Но отзывчивость игры с задержкой ~500мс, если даже мили бить заметно Урон хз где за стеной, + самого персонажа дергает и фризит уже, когда когда вокруг какие-то действа происходят. Я тоже ранее такого инета не видел и не думал что он может влиять на отзывчивость, но это так. Конечно если сам никогда с таким не сталкивался, то можно и не поверить. Приезжай ко мне покажу, офигеешь

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

iG0Lka писал(а):

т.е. если у нас имеются потери пакетов, а в игре я перевожу прицел, а он идет скачками, после этого я жму кнопку раскрытия оптического прицела а он раскрывается с задержкой в 1 секунду, и после этого выстрел происходит с задержкой в полсекунды, это не влияние соединения?

В это сложно поверить, если сам не сталкивался. У тебя же эта проблема тоже давно, еще в бф какой-то части вроде начала проявляться? Если бы вне в каком-нибудь 2006-2008 году сказали про такое я бы сказал переустановите винду или покрутил у виска, ну или сказал выключите закачки/торренты. А сейчас смотрю сам на это дерьмо, не понимаю что это, и как исправить. У тебя скорее всего ранее тоже был отличный инет, ты же играл в UT, думаю там все было норм, а если сейчас ты его поставишь, эта проблема и там себя покажет.
У меня проблема эта появилась где-то в 10-м году, причем это была не задержка, а микрофириз, когда кто-то кого-то убивает(килл фид в любой игре), но не сильно напрягало. Затем где-то в 13 году появились вот эти задержки и ватность, причем они были недолгие, где-то минут 30 за вечер(в любой игре). Потом стало похуже, дошло до того что такая задержка весь вечер до 2-3 ночи. Теперь же эта задежка перманентная и намного сильнее(~500мс) и не отпускает даже глубокой ночью. И смена провайдеров не помогает(как и смена ос и компов ) Наверное заземление шалит

К вам кот с лампой пришёл? Завязывайте с оффтопом.

И мне кодер Дима Ясенев лично на форуме описывал сетевую проблематику в игре и что решается, а что - нет. С описанным выше качеством инета у некоторых, я Диме даже писал, что для подтягивания игроков с "проблемным" интернетом, я на его месте решал бы проблемы многократно сильнее: раз нет никакого желания отказываться от UDP (а несколько приземлять лоупингеров - это тоже вполне здравая идея), то нужно, во первых, в каждом пакете дублировать дважды/трижды/... уже отправленные ранее данные (ID у них уже давно был введён, так что сортировщик сервера уже раз полученное повторно легко отбреет, чтобы не перегружать сам сервер), а во-вторых, я бы всё то же самое оправлял бы ещё и по TCP ("гарантия" против "скорости с потерями" - ещё не факт, кто придёт к серверу первым) и результаты стрельбы (попаданий) засчитывал бы только после получения 90+% от отправленных пакетов (ибо через UDP даже не понять сколько их высылали и часто до половины урона просто теряется в дороге). А то получается, что хайпингеры - прямо как бойцы с автоматами с рандомно заряженными холостыми А у других, оказывается, до кучи ещё и до сих пор фпс и/или мышь клиента к тикрейту сервера привязаны. Короче, большинство ищущих здесь решение своих проблем с играми, нужно сначала отправлять грамотно разобраться и настроить сетевую активность, а не лезть сразу в дебри DPC.

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

Есть, Сэр!

там видно, что проблем с соединением НЕТ.

согласно графикам потерей НЕТ

я давал ссылку на тред на форуме нвидиа, читайте всё посты, делайте выводы

Но Близард лично вам врет что ли? я в это не верю. Кто вы такой то для них? Если там(на нетграфе) все "отлично" - значит с сетевым соединением так("отлично") и есть.

Я вам факты говорю, которые при должном старании вы можете проверить. А по ощущениям люди в духов и нло веряли. А в 2к18 видимо новый тренд.

И что инпут лаг становился такое же как у iG0Lka?

А с проблемами сетевого соединения я сталкивался, и всё было как вы описываете, только на мышь(инпутлаг) это никак НЕ ВЛИЯЛО (и влиять не может). Если это сетевое соединение, то на графиках будут видны аномалии: 1) ЧАСТЫЕ скачки входящих пакетов (выделяются оранжевым фоном), 2) ЧАСТЫЕ потери пакетов (2 нижних графика неровные + выделяются оранжевым фоном на верхних), 3) неравномерность исходящего трафика (очень неровный черный график).
Если во время ваших проблем на графика нет этих аномалий, значит виновник НЕ сетевое соединение. Ищите проблему в другом. (или можете не искать, играйте с лагами, мне легче будет сделать вас в игре)

korino писал(а):

Это провайдер шейпит...

у меня колени побаливают. Это тоже провайдер шейпит? Для глупых: проблемы с коленями подтвердит врач; проблемы с соединением подтвердит нетграф ctrl+shift+N; а проблемы с инпут лагом(мышью) не могут быть вызваны сетевым соединением

Вот именно! а то у них на мышку то флоу контрол, то провайдер влияет (или сомбра на нло над домом пролетает и комп хакает)

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

я и не отказываюсь - при выключенном flow control, даже в вечерние часы, игра имеет лучшую отзывчивость.
и внезапно это подтверждается проверкой bufferbloat - с включенным flow control он составляет 40-60мс, а с выключенным 1-3мс.

и да ты может путаешь инпут лаг мыши с временем реакции игры на действия мыши?
есстно сетевые проблемы не имеют, никакого отношения к инпутлагу мыши (т.е. задержка с которой системе передаются манипуляции пользователя мышью).
а вот реакция игры, конкретно ОВ, на действия пользователя имеет явную зависимость от качества прохождения пакетов.
Простой вопрос - при потере пакетов, пользователь будет испытывать проблемы с движением своего персонажа в игре?

так я же говорю можно проверить степень внешней буферизации при разных настройках стека - http://www.dslreports.com/speedtest
конкретно при отключении flow control время буферизации уменьшается.

Интересные замеры latency привел один из пользователей тык .

Драсьте! ("Всё уже придумано до нас" (С) чей-то)

(не буду удивлён, если тов. модератор всё-таки надумает перенести часть обсуждения отсюда в тот топик)