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

tsc в районе 2.9- 3.9. Hpet в районе 14

Проверяется так же список ключей в загрузчике:

bcedit /enum.

Никаких useplatformtick, useplatformclock -что реально полезно disabledynamictick- можно прописать или нет по желанию- Остальное в топку имхо, если стоят, лучше удалить.


Time for Qpc call -22.4 Мне кажется высоковат,что-то вы перекрутили у себя в Пк. Имхо

сделал /deletevalue useplatformclock
ничего не изменилось
счас попробую сделать true

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

т.е. есть всего два таймера? tsc и hpet ?
значит если меньше 14 то tsc?

вот с useplatformclock = true

чтото мне 4 строчка с 772нс не нравится

Hpet, Tsc и его разновидности- гибриды tsc, 3.57 с 772 это скорее всего tsc+hpet получился. вобще для вашего пк был оптимальный первый вариант скриншота.

Была таблица в сети:


Но надо учитывать что ей 100 лет в обед, платформы и чипсеты уже другие. В большинстве случаев чистый tsc без миксов и синхронизации - наилучше на свежих платформах. На вашем 2700к не думаю что исключение.

я у себя нашел скрины где Time for Qpc call - 7.0нс к сожалению по имени файла непонятно какие параметры были использованы.
от чего он зависит?

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

#77

что может это значить? все плохо?

Может и ничего.

1.5 часа никто не меряет,любая активность или выход из сна-покажет аномальные скачки, 1-2 минуты достаточно. Режим простоя когда нет никакой активности- пониженные частоты и напряжение на цпу. Лучший вариант после перезагрузки Пк. 1.5-2 минуты подождать до момента ухода цпу в "простой" - потом запуск.

iG0Lka,по поводу таймеров, на последнем скрине ACPI PM таймер используется (3.57 мгц), т.к. HPET видимо выключен в биос, а в системе useplatformclock, это всегда так и у всех... По поводу этих твиком, я напиасал на той же странице по ссылке, только ниже. Так же синхронизация таймеров(именно для использования в качестве основного, а не по отдельности) не всегда и не на всех полатформах тоже стоит учитывать.

я это читал, и сейчас еще раз прочитал, букв много но как применить к себе не понятно, т.е. нет конкретных выводов и рекомендаций.
Ок счас попробую включить hpet в биосе и удалить useplatformclock совсем (сейчас он в значении no)

вот что получилось:



чото разницы не вижу...
пойду попробую в игре

iG0Lka а есть какие то нормы для показателей pc clock frequencies? чтобы понимать в норме всё или нет

iG0Lka, как я и писал выше, синхронизация таймеров происходит только на определенных платформах в определенных условиях, это надо уточнять в мелкомягких. В твоем случае работает просто TSC без синхронизации, но HPET так же может использоваться независимо от TSC, поэтому люди и видят разницу при отключении HPET в биос, точно не известно, как сама ОС использует HPET.

EaST вот бы и мне их узнать. у меня это спрашивать бесполезно, я в этом как ночью по тайге
вот товарищъ Deviance судя повсему в теме.

iG0Lka, все нормально у тебя Норм по сути как таковых нет, и даже если были бы, никто ничего с ними не сделал бы. Т.к. скорость доступа к таймерам не особо зависит от других условий, кроме их местонахождения в системе. То есть не особо важно как настроена у вас система, настройки энергосбережения и т.д. Либо вы используете TSC в пределах шины проца(Ring bus, Infinity Fabric), либо используете HPET, ACPI PM с чипсета. Все просто. 5-70 мс(в зависимости от платформы отклик TSC) против 600-1000 мс от любого таймера в чипсете, и обусловлена задержка в большей степени не самими таймерами, а именно средствами доступа к ним.
Поэтому еще раз всем советую оставить все в дефолте относительно этих настроек таймера.

а зачем тогда HPET включать?

iG0Lka
напротив, зачем вообще ее ОТКЛючать? по умолчанию всегда задействована, вроде проблем никаких не приносит. откуда инфа, что HPET несет в себе некий негатив?

если используется как основной таймер?

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

iG0Lka, во времена реализации HPET tsc только появлялся, первые реализации tsc невозможно было использовать с многоядерными системами без синхронизации со сторонним таймером + tsc имел зависимость от частоты процессора(состояний энергосбережения). Сейчас HPET используется как замена старым таймерам для совместимости с некоторым ПО и + для мультимедия, т.к. он более точный, нежели tsc в нынешнем виде.

В винде по-умолчанию HPET отключен. Точнее, не используется как основной таймер. В BIOS по-умолчанию включен, но там и много другой ненужной фигни изначально по-умолчанию включено, так что это ни о чем не говорит.


Ну это у тебя не приносит, а кому-то приносит. У меня, в принципе, с включенным HPET тоже нет проблем с латенси.


Как и в чем сравнивал? Я между включенным или отключенным HPET (в BIOS) ощущаю приличную разницу в движении мыши при игре в сетевые шутеры. Что лучше -- "вкл" или "выкл" -- трудно сказать.

Кстати на 1709 Time for qpc call -выше в 3 раза- 18- 22, и это при работающем оборудовании, что то они на хмичили в ядре.

Добавлено спустя 6 минут:


Ядро ос само решает, а включать его на новых цпу какой смысл?- чем лучше инвариантного?.