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

опять стрелки переводишь...
вопрос же простой...
и да CorniliuS, в овервоче нет офлайна.

https://www.twitch.tv/videos/1059194682

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



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

у меня система выдает порядка 270 или больше.
но я играю на ограничении 145. Перепробовал кучу всяких фпс, но именно на этом все более четко и именно на этом у меня бывает по 70% точность.

iG0Lka
А это что?

В замесах? Просто на полигоне у меня 400. Посмотри в замесах - там меньше 100 будет, а то и даже ниже 60. 7700 - проваливается ниже 100, а уж он явно твой превосходит.

У меня вообще нет зависимости от этого, что 144, что 360 играю примерно одинаково. Просто свыше 300 как-то все уж очень живо становится, это чувствуется.

это боты онлайн.

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

на полигоне у меня 360-396. Скрин надо?

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

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

я играю на вдове.
попробовал
на вдове когда замес в среднем 200-220
на трейсе в замесе 180-190

я играю на 145.

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

не знаю когда это случится, пока что не вижу надобности тратить 500$

Прикольно вы постите видео, которые на Ютубе, один фиг, проигрываются в 60 фпс. И что-то даже сравниваете по ним.

Привет xeo, как тесен интернет
Кстати, для тестирования есть специальные заготовленные, повторяющиеся сцены для Мастерской
https://workshop.codes/search/fps
Самый жесткий это Оазис и Кингс Роу, а вот Айхенвальд by NEXO на мосту - помягче и больше похож на реальную игру в момент замеса.
В мониторинге лучше ставить опрос 200мс, а не стандартный 1000мс, потому что секунда это большой кусок времени, можно не увидеть как дропнуло в дно. Впрочем, если смотреть на игровой счетчик, то там видно больше, он быстрый.
Дропы до 180 случаются.

Гляну как-нибудь на досуге. Бенчи хороши, но как я уже говорил - сами по себе цифры могут не говорить о реальной производительности. Но вообще я для себя уже все проверил и сравнил в боевых условиях. Я в овер умудрился поиграть на трех процах (вообще-то даже четырех - еще был у меня i3 2120).
Кстати, еще такое наблюдение: пользователи интела жалуются на лаги (фризы, там статтеры, в общем все что говорит о низкой производительности), а пользователи АМД могут жаловаться на мониторинг (типа фпс дропается), но не на производительность в чистом виде. Я сам был недоволен мониторингом на 1600-м, смотрел в сторону 8700 даже, но тем не менее у меня там не было низкой производительности. Это уже сейчас, опробовав несколько процев, понимаешь мониторинг и комфорт на интеле и АМД разные вещи. Вот типа на интеле мол много фпс - да это так, но почему тогда там лаги. Или наоборот, на АМД есть просадки по мониторингу, однако комфорт очень высокий.

Не важно, боты есть боты, с ними лаг есть?

CorniliuS с ними нет. В свое время массово отстреливал "музыкантов" и "ан". Несмотря на то что музыканты быстро двигаются, там процент хедов был наверно 80 или больше т.к. это боты и они предсказуемые.
Но если играть вечером, когда плохая отзывчивость прицела, то и по ним попададь хуже.

Посмотрел, чёт не очень. Так же все дерганое как у всех, плавности ни анимаций ни игрового процесса нет. Видимо реально у них сейчас дно сервера которые не тянут тикрейт.


Сцены, бенчи, а так же реплеи это одно, а игра на сервере, с ещё 11 игроками, у которых разный пинг, свои лаги и все это считается сервером - другое.

Для начала надо быть уверенным, что проц вытащит перегрузку в игре, без микродропов с 200 до 120 фпс. От этого зависит как ведет себя мышка.
А вот как работает хитрег, какой десинк визуальной модели и хитбокса - это уже вопросы к интернету и сетевому коду игры. Первое ты частично контролируешь, а второе - никак.
Кадры в секунду и микрофризы от слабого железа - полностью твой контроль.

Лок поставь на 120 если у тебя с 200 до 120 падает.

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

Я уже говорил как пример КС 1.6 . Его тоже компы не тянут?

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

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

Такое теоретически возможно, но зачем это делать. Онлайн и так падает - в эту игру мало кто сейчас играет, в рейтинге одни смурфы (в золоте смурф на смурфе, смурфом погоняет). До овера 2 тут делать вообще нечего. У них и так много свободных мощностей, экономить на этом еще сильнее?

Чел тебе пишет, что разработчики для оптимизации траффика - сами разбивают датаграммы на атомарные. Но! Фокус-то в том, что если исходный пакет был размером явно больше, то как ты его ни передавай, получатель (не важно, клиент или хост - это действует в обе стороны), для того, чтобы произвести дальнейшие расчёты движком игры на клиенте или на сервере - должен собрать весь отправляемый пакет! Иначе, потерянная по дороге атомарная датаграмма (или не одна, если в пакеты намеренно заложена некая избыточность) не позволит собрать весь пакет, то значит все остальные его успешно полученные атомарные датаграммы - можно смело выбрасывать в "корзину". Вот почему твоё значительное увеличение MTU запросто может быть никаким не плацебо (если грубо: при 50% выбрасываемых пакетах, у тебя шансы, что из 2 полных отправленных пакетов всегда дойдёт 1, а при 20 атомарных, по 10 на пакет - получатель не соберёт ни одного полного /см. вероятность распределения/). И понятно, что текущая ситуация зависит от типа нагрузки на траффик шейпинг: он отбивается сейчас от кучи мелочи и тупо режет каждый пятый/десятый пакет или идёт большая потоковая нагрузка и тогда задействуются совсем другие правила приоритезации пакетов.
P.S. и я ни разу не удивлюсь, если мне скажут, что трафик шейпер сам твои же пакеты может объединять в более крупные блоки, чтобы отправить дальше, ибо делать 1 отправку по 1 адресу за определённое время, а не 5/10, ему явно проще (в алгоритме шейпинга такое тоже вполне могли учесть).
P.P.S. И на выбор маршрута размер MTU теоретически может влиять (корневые узлы сети прекрасно "знают" друг друга и оценивают взаимные возможности, так что настроить пересылку мелочи "налево", а крупный поток "направо" - тоже можно. Другой вопрос, заморачивается ли вообще кто-то такой "очень тонкой" настройкой маршрутизации?).

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

Пройдёт. Оно в этом случае работает множителем амплитуды (при переменном) и силы тока (при постоянном). Лет 8 назад я смог избавиться от БСОДов тупо поставив стабилизатор напряжения (в городской квартире). И я не "гуманитарий" типа "О! получилось! (и успокоился на этом)". Я пару-тройку раз убирал и ставил его обратно при прочих неизменных условиях и какого-то времени пробега (которого по длительности хватало для получения минимум пары БСОДов без стабилизатора), чтобы убедиться, что это не случайность. Да, разгон ЦП и памяти был на пределе. Ибо, без него я бы хрен поймал этот важный нюанс.

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

Это отдельная большая тема. Ззаня хорошо её раскрыл в серии своих видосов, но даже с ним мне нашлось где и о чём поспорить и не согласиться.

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

Я только что выше привёл пример самого большого их влияния на инпут лаг. Это аж целые БСОДы!

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

Это не самый простой вариант. Схема подключения аккума в УПСе может быть совсем не онлайновая + время переключения режима работы (если не постоянно через аккум, что его очень быстро убивает и так почти никто не делает). Инвертор в этом случае ведёт себя более предсказуемо и гарантировано.