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

Win 10 ltsb
как то так
MSI AB выключен


#77

С включенным MSI AB

Чувствуете разницу?

#77

Отсюда вывод :А нах нужен посторонний софт в виде АБ(ну эт на любителя конечно )

1)Получается, что по LatencyMon, разницы то и нет(MSI AB, не MSI AB), а по Latency Checker не пойми что рисуется в пределах 1000, разве нет?
2)Соотв, если DPC Latency Checker выдаёт на постоянку(для win 10): что +-50(избранные системы), что +-500, да даже +-1000(cкрин ниже) - в реальности, это те же +-50 по LatencyMon.
3) Так чем же чекать на реальность win 10:)?

Чтобы MSI Afterburner не увеличивал задержки системы достаточно в нем отключить мониторинг

Никак, Тип таймера определяется-флагом цпу,платформой. На интелах-это инвариантный Тск,в современных реалиях использование Hpet- не актуально. Ядро виндовс учитывая железо выбирает наилучшее.
Опцию в биосе оставляют для дебага и тестирования различного оборудования.
Можно с ней получить завышенные результаты в 3дмарк,но это кукуруза. и эти данные не принимаются в качестве репрезантивных.

Если вас интересует только минимальный инпут лаг любой ценой,то тут можно попробовать ключи загрузчика:

bcdedit /set useplatformclock true
bcdedit /set tscsyncpolicy Enhanced
bcdedit /set disabledynamictick yes

Или просто отфорсить минимальное разрешение таймера,выключив все энергосберегающие+ динамический тикрейт выключить. Лично я от такой схемы отказался.


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


Сам разработчик говорил что http://www.thesycon.de/eng/latency_check.shtml Dpc latency checker всё что выше win7 меряет не правильно. Для 10-ки есть Latency Mon.
Результаты можно получить минимальные и в dpc в win10-но это лишь отражает разрешение таймера. Фиксацию режимов оборудования.

То-же самое справедливо к методике измерения в win 10. Не меряется практически полезные значения задержек в играх,или при разгоне оборудования-фиксированные частоты и множители-в этом случае там всегда будут значения около плинтуса-минимальные.

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

Может быть всё, что выше Windows 7?!

Да конечно от 8 ки и выше,опечатался-благодарю поправил.

видимо при определенных условиях. Если устранить то что мешает неправильно мерять то будет как у нас с fazometr

Инструмент не для "пиписькомерства".

Личное дело каждого форсить таймер и выкручивать все "энергосберегайки" в ноль-если нужен инпут лаг любой ценой. Для себя практического смысла не вижу- эту схему себе я зарубил на корню. Так как для определения реальных проблем в системе-он не подходит- 20-30 микросекунд текущая и красивые графики- мне ниочем не говорят-а только то что я выключил или оборудование "кочегарится".

А с точки зрения Служб Ос и софта, да и простого рационализма не "кипятить" систему просто так на рабочем столе/разгон его- то-же дилемма.

https://habrahabr.ru/company/intel/blog/186998/



p.s Вижу ветка форума актуальна,пока был в отъезде уже набралось постов

Ссылки, как посмотреть, какой именно вариант у вас сейчас включен и т.д. (работает и на Win10 - проверил):
http://www.mediafire.com/file/xzo9n84d8 ... er_1.1.zip
http://www.softpedia.com/get/System/Sys ... l#download
(скрины тут: DPC latency на видеокартах Nvidia #15024383)

И достигнуто это тем, что убили панель настройки в автозагрузке и прибили HsMgr.
Тоже на Asus Essence STX переделал и накатил дрова от Asus Essence STX II
и сделал Low DPC latency

А это чё, плохо нет ?!

сам решай - для сравнения
(только что снял)

Чё из этого у тебя включено, всё ?
bcdedit /set useplatformclock true
bcdedit /set tscsyncpolicy Enhanced
bcdedit /set disabledynamictick yes

а как посмотреть?

В голове моей опилки , да да да

сочувствую чо.

а у тебя эти три параметра какие имеют значения?

Учитывая, что я их не трогал с момента установки винды, то значит в дефолте

Ну и правильно зачем она нужна когда из за нее задержки выше. Я юзаю XonarSwitch т.к. наушники подключены к звуковой напрямую, а колонки к передней панели. Забиндил в XonarSwitch переключение на горячие клавиши и стало удобно, что кстати обычная панель делать не умеет.

Кстати кто нибудь пробовал этот твик: http://maxedtech.com/xonar-disable-spea ... k-testing/ ?

Зависит от вашего набора энергосберегающих настроек и периферии. если в ос и биосе по дефолту всё-это более чем отлично.

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


DPC latency на видеокартах Nvidia #14463979

У "Иглы" там С-уровни в биосе вырублены если вобще не всё -отсюда эти красивые цифры).

Всё это субъективно и на слух имхо вряд ли определяется.

Xonar-Switch классная тулза, но смущает одно, она зачем то, лезет в инет при запуске
Вот бы кто нить такую же панельку написал для видео драйвера, было бы просо ахренительно .. эх мечты

Как я и говорил выше, на слух вряд ли будет разница


Энерго-сберегалки в биосе все включены.

Неее на такие жертвы идти не согласен, ради красивых графиков

Итого, получается, что у него выставлен (должен быть по тому посту) и опрашивается только низкочастотный (и он же самый отзывчивый, т.е. с самой низкой задержкой опроса) аппаратный LAPICs (который на 3,5 МГц) без синхронизации и без динамических тиков (что логично для низкочастотного таймера). По сути - идеальный вариант для однопоточки. А теперь, внимание! "Иглу", как, наверняка, и всех других игроков в шутаны лимитирует в боях именно канал приёма, передачи и регистрации инпутов (конкретно: рука => мышь => драйвер мыши => игровой движок), а не число фпс на экране, их микрофризы или их отсутствие и всё т.п. А обработка мыши - это однопоток. Этому процессу 2+ ядер и не сдались никуда и никогда так и не понадобятся. Вывод: наименьший инпут лаг на однопотоке, высокие приоритеты и частоты контроллеров ввода, а также процессов их обработки - вот он, главный залог успеха в сетевых баталиях и комфортной игры, как таковой.
Имхо, конечно же. Можете поспорить.