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

Я про это и говорю, что NVIDIA для Quadro видит в этом какой то профит, а для игровых карт нет.

Откуда уверенность что мы не форсим Legacy режим какой-нибудь этими ключами, Msi вместо Msi-x ?- парк квадро карт очень обширен от очень старых моделей в том числе. Для меня странное решение для рабочих станций.

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

В плане железа-его работы- я очень привередливый человек. И отказался форсить msi на карте не просто так

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

Возникло недопонимание, говорил я о приоритете ключей реестра которыми мы форсим msi в ОС -относительно привелегий драйверов pci.bus,видеодрайвера в режиме ядра и спецификаций оборудования. В том смысле что наплевать на них(ключи). Они могут ничего не решать, а только создавать проблемы. Вы сами тестировали на своем конфиге? Что можете сказать?- а вижу у вас видеокарта радеон в конфиге. Понятно.

О чём тогда разговор)). Говорил применительно к Паскалю,Нвидии вобще.

Не много оффтопа, и грузинского фольклора.

Спор ваш интересен, но я не увидел разници между msi и не msi, что в dpc latency, что в играх.

Тут не спор, дискуссия о целеособразности параметра на Нвидии, ценность которого равна нулю. Учитывая текущее "качество" драйверов и windows 10)).

объясните на пальцах что такое DPC latency ?

Подскажите , если столкнулся с этой проблемой на 1060 palit js, есть смысл просто взять другой палит или 1060 ? Или у меня со всеми паскалями так будет?

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

XIMERA123 а это у всей серии паскаль :?

Серьезно? А то что у другого исполнения будет другой биос ни как не повлияет? На паскаль все равно путь заказан? Я как понял они это фиксить не собираются да?

смена карты не поможет, это родовая болезнь паскаля, если он не подружился с системой, увы, смотрите в сторону АМД DPC latency на видеокартах Nvidia #14988906 сейчас вместо 1060 у меня 2х1080ти и на каждой те же самые траблы.

на какое приличное-то? На время меньшее миллисекунды?

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

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

У меня ивик 3770. Спасибо за ответы. Пойду сдавать это чудо.

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

а чего сдавать-то. У вас есть эта проблема?

SINgle84 писал(а):

проще видяху сменить чем целиком систему )))

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

Конечно, потому и написал в тему. Сдавать карту а не ивик)))

Вообще-то нет. Даже на Kaby Lake эта проблема может проявиться.

По моим наблюдениям,считаю это больше не совместимость с pci-ex, Паскаль вносит сильный джиттер сигнала на шину, другими словами сама карта является помехой для платформы и сама очень чутко реагирует на любой тюнинг в системе:

разгон контроллёров,шины pcie и памяти,сторонние устройства на pci-ex )). Это следствие работы gpu boost 3.0, в комплексе с импульсной нагрузкой на vrm. Проявление этого в задержках и драйвере- это конечное следствие:

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

При выборе карт обращал бы внимание на каких элементах и как построен питальник ( если сможете найти datasheet) и с каким бп карта будет работать Желательно качественный с минимальным уровнем пульсаций- что нибудь из топовых superflow, корсаров,энермаксов или соников(только не брак партии) и хороший фильтр на сеть.


По возможности свежий биос на мп, выбор платы с богатейшим набором настроек, и естественно ручная настройка шин,режимов работы и частот.
Фиксация pci-e 3.0 в биосе, любое энергосбережение на шине выключать. Любой спред частот то-же-. При настройке Фапч на Цпу и pcie-x(если есть) добиватся максимальной точной настройки. режимы low blclk и т.д.