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

(я пока не уверен, в этой ветке стоит обсуждать это или в другой. Но, всё же.)

А вот это уже интересное наблюдение. У кого происходить та же ерунда при стриме?
Случай, когда видеопоток реально является плавным (т.е. более-менее равномерным), что подтверждает нам один из его получателей (при чём, самый медленный) - записывающее стрим ПО, а на экране мы видим некоторое лагалище, может говорить о том, что у стриминга может просто стоять более высокий приоритет. И пока стример не выполнит свой неделимый во времени кусок работы, другие, например обработчик вывода на экран монитора/ТВ может простаивать в его ожидании (идеально запараллелить тут не получится, т.к. источник 1 и обращение к нему за данными в буфер кадра будет всё равно поочерёдное, только если заранее специально не предусмотреть 2(!) одинаковых буфера хранения под такие дела).
А при отключении стриминга дергатня пропадает? Если да, то, скорее всего вышеописанное. Если нет - нужно немного подумать...

НУ без стрима микрофризы без всинк, хотел записать их шадоуплеем но он пишет в 60 фпс видимо фризы он поэтому не записывает.

faq. все софт и часть аппаратных причин описаны -в том числе датчики и оверлеи. Заполняйте профиль подробно на каком пк дергается Интел или Амд. Попробуйте новые 397.31 в связке Ос- 1803 и wddm 2.4 - у меня отличные впечатления от новых драйверов,а человек я привередливый в таких моментах.

В общем, я пока что сдаюсь. Фризы уменьшились и пусть не хотят пропадать, но я тоже не хочу целыми днями воевать с пк, уже работать на нём надо. В принципе, жить можно. Как созрею, начну с техподдержки MSI.

Да. Фокус именно в том, что записывать - не показывать. Запись 60 к/с это ровно 60 к/с, где каждый кадр ровно 1/60 секунды. При этом записывается в файл ровно то, что считалось с буфера кадра, где без всинка мог оказаться рваный кадр, состоящий из двух разных полукадров. Дёргание на видео появится только тогда, когда какой-то кадр слишком надолго (на 2+ фреймов) задержался в буфере, и то, если сжатие видео не использует какое-нибудь выравнивание/интерполяцию. При сильном же сжатии, когда используется мало ключевых полных кадров, видеоэнкодер вообще может брать только каждый третий/пятый/десятый... кадр за основу для ключевого, а несколько последующих будут кодироваться изменениями к нему с такой потерей качества и смазыванием, что ни один Шерлок Холмс не найдёт потом разницу и "виновных".

в буфере нет рваных кадров это проблема моника.

Нет, не монитора, а видеокарты. В тройном буфере - нет рваных. Но он не везде используется. А вот в двойном - могут быть запросто. Опять же - от типа синка ещё зависит.
Классический всинк-офф, насколько мне известно, передаёт кадр на монитор ровно по мониторной синхронизации: подошло время - перехватывает управление буфером и отправляет то, что получилось в буфере. Если ВК не успела дорисовать туда кадр, её обрывают и она продолжит его рисовать во второй (из двух) буфер. Если закончит, снова начнёт рисовать в него же. И так, пока у неё опять не перехватят управление и не отдадут под рисование другой буфер. Отсюда и растут ноги у тиринга.
Вообще, какую конкретно проблемную ситуацию рассматриваем? Чего гадать-то? Какой стоял всинк? Двойной или тройной буфер работал? А то мы в теорию от проблемы уже ушли...

Хуже стало по DPC с новыми дровишками,версия винды 1709 - 16299.15 без Meltdown и т.д.
Скрины кликабельны.


У всех так? в смысле ухудшились показатели?

Ваша правда по DPC показатели пошли вверх с 397.31 винда 1803 - 17133.1
Сорре без скринов т.к. с работы

Enkvar И да, и нет.
Скринов с 390.77, на них сидел все это время, не осталось, но там драйвер нвидии прыгал до 150us, тут же 200, т.е. вроде как и ухудшилось, но не в 2 раза же.

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

Для статистики оставлю: на 378.92 было примерно 10-30us на 397.31 прыгает до 140+us

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

Всё сейчас на 397.31 так-же на мой взгляд, эти значения нельзя же без отрыва от ос и текущей задержки анализировать. При измерениях-должны быть максимально равные условия-одно время измерений и состояние ос.
В 3д приложениях и играх я вижу отличный очень стабильный фреймрейт, а если у кого-то скачок единчный до 300-400,это ниочём не говорит. Перемеряв позже- вы получите другие значения.

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

у меня со всеми заплатками, dpc в норме

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

kiberman Прошу помощи у Вас как у специалиста: не могу вернуть значение таймера с 3,11 на 1,73. История такая, на плате ga-b150m, проц i5 6500, был биос F2: из коробки на старте глючили контроллеры юсб и рс2, перешил на F21(под 7серию)- стало хуже, вернул назад, все стало о.к. контроллеры подхватились, но теперь не могу вернуться на старый таймер, на нем задержки были 50-90, на этом 230-290. В биосе матери только одна настройка: hpet доступно или недоступно. При вкл. если bcdedit /set useplatformclock true, то таймер 24, если bcdedit /deletevalue useplatformclock то - 3.11, если выкл. то тоже 3.11, а раньше с недоступным в биосе hpet таймер был 1,73, как его вернуть? По системе больше ничего не крутил, только новые интеловские дрова на чипсет, может в них быть дело? Остальные настройки биоса те же, разгона нет

Многопоточный процессор (i7, Rysen), приличная материнка, и память работающая по jedec параметрам (без всяких XMP и разгонов) вероятнее всего уберут все эти latency.
У Nvidia драйвер многопоточный, и делит время с игровой логикой, от этого могут быть фризы на слабых либо на чрезмерно разогнанных процах и памяти т.к. код более сложный.

Здравствуйте-специалист я "такой себе" честно ,лично я после каждой прошивки делаю clr-cmos перемычкой для очистки таблицы dmi- с этого я бы и начал-

Так вы сейчас вернулись на F2?-там нет опции?.

Мои бы действия были бы такие- отключил в биосе hpet-если вы на f21, прописал bcdedit /set useplatformclock false в ос и перед перезагрузкой после ввода ключа- проверил бы в диспетчере задач драйвер:

"Высокоточный таймер событий" - попробовал бы отключить/удалить. Но учитывайте, что у вас какая-то была не понятка с контроллёрами, Рабочая схема TSC+HPET сейчас на 95% Пк используется и у меня в том числе,без необходимости что-то ковырять- и задержки такие могут быть у вас от неисправного оборудования и проблем с драйверами/ос на этом оборудовании.

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

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

Золотые слова,если не гнать в шею контроллёр Озу- это очень благотворно сказывается на всём.

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

kiberman Сделал как Вы написали, 1.прописал bcdedit /set useplatformclock false 2.Отключил и удалил высокоточный таймер через диспетчер, 3. в биосе отключил Hpet: результат вместо 3.11 получил 3,57. Какие мысли у Вас на такое поведение системы?