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

Запустил я тут ради интереса LatencyMon на GTX580 и профильной системе (2600к в стоке, и т.д.), и просто поработал пару часов (серфинг+маткад+чтение пдфок в хроме). Дровишки 355.82. Ужасы присутствуют (на звук жалоб нет).

Дополню, что за эти пару часов фризов я не заметил, в играх (в тех, которые не упираются в 1.5гб видеопамяти) тоже всё норм. С глазами тоже всё окей.
Не хочу делать какие-либо выводы, просто информация. Хотя чтонибудь из настроек в системе я бы покрутил, почему бы и нет

Olegdjus Ребята, давайте по серьезнее, зачем вы издеваетесь? и причем тут ХЕВАН, у меня с хеваном тоже нулевые задержки даже в СЛИ
ПРОВЕРЯТЬ НУЖНО В ИГРАХ, а не в хеване
#77

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

antiOVER камень тут вообще не причем, просто Олег сжульничал и прогнал зачем-то хеван. в хеване и у меня все зеленое по 1 квадратику

wolfire
я эти "микрофризы" наблюдаю с самой gtx 8800... эдак с 2007 года. были ВК разные, обоих производил - одно и тоже в общем. дело совсем не в паскале.

wolfire игры были созданы задолго до паскаля многие

Ну давай так - идет дефрагментация, пишется видео игры, я играю в ROTTR и мониторю задержки с помощью святого грааля LatencyMon
Вот итог

Какой следующий шаг? Вызвать Ктулху? К слову, это я тестил на карте с 2ГБ vram.

В чем я сжульничал теперь? Игра не та?
В дополнение - драйвер в стоке(то есть оптимальный режим работы включен) и сбалансированный в винде(видно по сбросу частоты проца)

все правильно он прогнал, хевену цпу по барабану, там уклон на тестирование ГПУ.


практика показывает обратное. и5 - он и африке ипять.

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

камень - сказка!!!

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

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

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

Вы альтабитесь, смысл-результат будет в любой игре +- такой,вобще откуда пошло это тестить в играх.

Если логи выводить и как фоновой процесс ещё может быть-а так оно переключилось и вывалило овер 500+


Это не заслуга i7,в биосе хлам отключен не нужный-встроенный звук,шины выставлены и множители вручную,фапч на llc,spread выключен,мониторинг. Порты те что нужно,смарт и энергосбережение на портах выключен. В ос ничего лишнего-стандартный Ав.
Кстати asus z97-k без настройки хуже себя показала gigabyte z87-dh3p.

Чем плата проще тем лучше по этому показателю.

antiOVER да причем тут господи процессор,если в окне играть и видео записывать у меня еще ниже чем у Олега задержки, тут дело не в процессоре

Стоп, так надо было играть в окне, чтобы увидеть эти задержки(которые есть у всех, но их не все видят), теперь не в окне надо?
Может определишься уже?

В том то и ирония что окне теоретически проблем должно быть больше,а в фуллскрине как не мерь да-же свернув latency monitor-она зафиксирует снятие нагрузки с железа при выходе с игры-то-есть покажет всплеск.
Другими словами такая метода меряет пшик-нерепрезентативна. Мерять в Ос,простой +окно

antiOVER мой и5 лучше чем 99% процессоров, 6 ядерник не факт что удачный попадется и будет еще хуже.
Что бы вы не троллили вот снял тоже самое на своем и5, задержки еще ниже чем у Олега, что теперь будешь всем говорить что и7 фигня, нужно брать и5 там ниже задержки?? Причем заметь что я записывал видео в 4к разрешении и играл в 4к разрешении с 300фпс, стоит ли говорить о том что в этом случае нагрузка на ЦП выше??
Я тут пытаюсь найти проблему, которая может быть и не в DPC задержках, а вы тут начали старую байку не смешную что для игр нужен 100 ядерный и999

ты наверно забыл, как залетел в тему и начал рассказывать про проблему dpc latency, которая есть у всех? А сейчас сливаешь свои же громогласные заявления.

обычный четырехядерник с посредственным разгоном. Удивлю, но у нас в среднем 42см.
Mellow, поддерживаем эго "профессора")

Человек просто не совсем понимает для чего этот инструмент. И зачем тестировать простой. Железо в порядке -будет зеленая зона. Драйвера переходят в спящий нормально-то-же порядок.
Если при минимальной активности в Ос,когда сеть и диск стоит,а цпу ничем не занят- задержки скачут аномально высоко- это беда,а не когда подключено -4к монитор,происходит дёрганье гуи и так далее. Инструмент не правильно используется.

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

Это стало нормой для автора

Olegdjus да залетел, и настаиваю на том что в ОКНЕ тестить не правильно,в окне и у меня отлично все. В окне рендерится в лоу разрешении игра. нужно именно игровой режим фул скрин, запись только программу бы сменить.что бы ЛОГ писала, а не смотреть в нее. что бы альтабы не учитывались
Сейчас вот увидел, что на видео сли вырубилось у меня в настройках игры одну карту показывает.
Значит проблема в СЛИ, на одиночной карте более менее!
Ну пробелма то высокой задержки DPC есть, нвидиа же даже признавала, что ан меня накинулись то? буд-то я что-то плохое делаю, а не пытаюсь помочь комьюнити найти проблему фризов на паскале?

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