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

Да уже давно надо было переименовать в "DPC latency, Input lag" или сделать раздел, как на blurbusters "Input lag, Display lag, Newtwork lag"

Ну поставил Apex Legends, Джорджия
Средняя Задержка: 146.57мс
Средний джиттер: 18.43мс
потерь нету

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

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

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

Кстати, отличная идея!

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

Замечательно. График без всплесков?
Лучше выставьте вручную параметры конкретно для своей игры: кол-во снимков можно оценить по переменным типа "snpas" и "cl_maxpackets", а размер пакетов конечно лучше через перехватчик какой-то типа wireshark поглядеть.

Ну сначало пакетов 30 пинг 300, потом 140 и идет в принципе все ровно. Ну если сервера в Джорджии и Австралии, то эт как то не очень надо, в Германии бы сервак.

brot3
да, неплохо бы было б в разных частях света и Европы иметь данные. Ну хоть оценить, если уж в любое время дня и ночи потери и зашкаливания по пингу - то что-то с линией провайдера явно не то. Или у друзей в подъезде на другом провайдере всё пучком , а на вашем - вакханалия....

Да не показывают эти тесты ничего. Даже если у тебя просто 0 рега, на тестах все будет отлично.
Да и во всех более менее современных сетевых играх есть значки/индикаторы плохого инет соединения - так вот и тоже может не быть, как и реги, + будут задержки рассинхрона и инпут лаг.

Смотрели моё видео,что скинул?

pepper1985 Про радио и ЭМИ? Ну так понятно что все электроприборы его излучают, вот только проблемы(если мы про инпут лаг конкретно) есть далеко не у всех.

Смотрите шире на проблему.Ам радио даёт понять,что помехи везде.Для наглядности обычная лампочка и с энергосбережением.(пример БП AC\DC и DC\DC)Трубы отопления,есть ещё "умные" люди,которые через неё заземляются и т.д.

pepper1985 ну и? Помехи везде, у всех. А проблема не у всех. Как так и почему?
Тут нужно какое-то более серьезное оборудование, которое конкретно покажет уровень либо Эми помех либо же проблемы в электросети, в цифрах.

Вы меня не поняли. Осциллограф называется.

и как им наводки, скажем на сетевой кабель смотреть?

Неа, не верю Уже повторятся начинаю: много ли Вы знаете тестов на прохождение именно пакетов UDP? Это ж негарантированная доставка, их игра "выплюнула" в сеть, потом сервер "выплюнул" и что там с ними по пути произошло и тому и другому начхать. А они там где-то в переполненных буферах торчат в длинню-ю-ющей очереди, и там не десятки и даже порой не сотни миллисекунд... единицы секунд - вполне может быть.
Вот, к слову, ещё одна тема небезызвестная BufferBloat: http://www.dslreports.com/speedtest - можете поглядеть какие могут быть буферные "пробки" на пути. У меня, например, на работе показывает до 2625мс(!) задержку - вот они хитреги нулевые где.

у меня кстати BufferBloat зависит от настроек сетевой карты.
там есть одна настройка которая уменьшает его до единиц мс.
я вроде раньше писал об этом.

и да продолжаю собирать вдовой лучшие моменты матча...
очень прикалывает что это со сломанной рукой

https://yadi.sk/i/7PcDhG4l8UQneQ

Игра на живом сервере - вот лучший тест.
Я уже писал про такую штуку как udp reordering и выявить ее смогли только при совместной работе разработчика игры и провайдера.
А что если такое же возможно и на уровне дома/подъезда/района? А не глобально на уровне повайдера? И какой "тест" это покажет? Никакой?
А вот это вообще бесполезная хрень, которая имеет смысл только если у тебя дома канал забит полностью другими девайсами. Решается элементарно нормальным роутером или его прошивкой с нормальной работой qos.

Я уже это давным давно писал на хер знает какой странице про этот тест.Говорил,что,когда у меня рядом проходил коакс.антенный кабель рядом с моей розеткой(розетка рядом с плинтусом)то бафферблоат был постоянно F,когда я убрал полностью коакс.кабель,стал в основном D-C и под 3000мс(на 2 провайдерах)и мышь стала легче,комп меньше гудеть стал и БП стал меньше греться(вообще практически не стал)ещё заметил,что стиралка ,тоже стала меньше гудеть,когда работает и старый холодильник,после всего этого

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

А какие проблемы его сделать? Пяток проверочных серверов в разных частях мира и клиентская + серверная часть теста. Клиентская отправляет нумерованные по порядку UDP(!), сервер пишет в лог о тех, которые поймал за тестовое время. То же самое делается и наоборот от сервера к клиенту. Оба лога потом показываются клиенту "для раздумий" на тему наличия проблемы вообще и её масштаба. И ничего, что это будет не какой-то конкретный игровой сервер. Проблемы "последней мили" прорисовываются очень даже ясно.

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