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

Я уже искал, но не нашел. Есть только к USB3, но они не утсанавливаются.

Все было подключено и так в usb2, я переключил в usb3 - кажется стало лучше.

Переустановил драйвера на Uni, но эффекта как такового нету.

Сложно сказать, заметил я после переустановок и обновлений Windows.


что еще можно попробовать ?

надо как тут - http://www.win-raid.com/t834f25-USB-Dri ... odded.html

С чего вы решили что причина вашей проблемы связанна с DPC latency? Причин фризов существует достаточно много и нужно уточнять каким образом и в каких ситуациях они проявляются. Последнее куда нужно копать это задержки, вообщем вы не по адресу обратились. Также в профиле не указана видеокарта, похоже вы сейчас на встроенной сидите, а тема называется "DPC latency на видеокартах Nvidia"

Удивительно даже насколько тема развилась за полгода.
Я приобрела свою карту почти сразу после ее выхода, на замену Radeon 380, где замечу никогда проблем с задержкой звука не было. А пользовалась ей почти год.
Как только поставила nvidia проблемы преследуют по сей день. Я уже отчаялась даже надеяться что это как-то исправится с выходом новых драйверов или еще как (к слову у меня Windows 10).
Если работать весь день за компьютером, слушать музыку или смотреть видео в браузере или плеере неважно, играть в игру - стабильно задержки, залипания, короткие трески какие-то.
Я просто не понимаю почему такого не было с радеоном.
Да, и еще какая-то особенность именно в браузерах (чего тоже не наблюдалось на предыдущей карте), видео дергается 4 или 5 раз. Это прям тоже стабильно и всегда одинаково происходит.
И помимо задержек невозможно записывать тот же геймплей - на выходе получается очень плохой звук, слышны трески и щелчки.

Мне таки кажется, проблема в PCI звуковой и её дровах. Очень много total execution time на её драйвере. У меня драйвер Creative и карта pci-express, цифра total execution на порядок меньше.
Пробуйте отключать PCI звуковую, пользоваться интегрированной либо переходить на pci-express звуковую.

Вытащите карту и проведите все те манипуляции которые приводят к проблемам на встроенной в процессор, отпишитесь потом о результатах.

Гайс, подскажите.
У вас встречается что камера/картинка во многих играх в оконном режиме идеально плавная при стабильных 60 fps с vsync, а в полном экране чуть дёрганная?
Полный экран фиксится банальным локом 60 fps в RTSS - так становится плавно как и в окне, значит проблема софтовая.
Сегодня проверил на Mass Efffect Andromeda и Overwatch. Раньше замечал и в некоторых других играх.
NVIDIA в курсе этой проблемы, знает кто? Или у вас именно такого нет? Я так понимаю это только на 10 серии.

Pekalord
Вы не путаете "дерганную" картинку и банальный tearing, который пропадает при включении вертикальной синхронизации?
Overwatch прекрасен при 300fps без vsync. GPU 1070.

k2viper
Не, сравнивал с vsync в окне и с vsync в полном экране.
В полном экране как-будто vsync работает криво (при стабильных 60 fps).
Тиринга нет, как без vsync, но объекты (забор, дом) при обзоре камерой подёргиваются - нет гладкости/плавности, как в окне с vsync.
Микрофризов, звуковых щелчков, как описано в теме, нет. А именно проблема с гладкостью объектов при перемещении камеры в полном экране.

Вот страницей ранее камрад описывает что-то похожее:
Уточню - проблема именно с полным экраном (полноэкранный режим). В окне/окне без рамки плавно.

С какого это перепугу такой вывод? Фпс, который вы видите в мониторинге - это ЦПУшный фпс (от ЦПУ на ГПУ, а не после ГПУ, который ещё не факт, что выдаст на монитор столько же). Поэтому, лок, всего лишь заставляет ЦПУ отдыхать всё то время, которое ранее он тратил на "лишние" кадры. И пока ЦПУ писал эти "лишние" кадры" в буфер, ГПУ мог запросить очередной кадр, т.е. приходилось ждать конца записи в буфер от ЦПУ. При локе ЦПУ такое возникает редко, т.к. чаще всего, к моменту запроса от ГПУ, ЦПУ уже всё сделал и "ушёл покурить".

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

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

Alex TOPMAN какой тогда вывод? Для полноэкраного режима не хватает проца i5@4.7Ghz, как у камрада leetSmithy (у меня без разгона)? Только i7?

Имхо, вся эта муть из-за переходного wddm. Решили, видать, уходить от старых монопольных видеорежимов в угоду полной их мультизадачности, но "по соображениям совместимости со старым железом и софтом", решили старьё пока оставить, а новое уже пришить. Вот мы и имеем эдакого "франкенштейна". Наверное, опять "из-за ограниченных индусо-ресурсов"...

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

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

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

А другие режимы синхронизации попробовать? Fast sync например.
Оконный режим - есть оконный режим. Впрочем, что я объясняю, раз вам overwatch с 60фпс и всинком нормально играется

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

У массы людей на 1155 + паскале всё хорошо.

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

i7 3770K ходит в разгоне 4.6 по всем ядрам с фиксированным напряжением 1.26, HT включен
Комп работает 24\7
БП Zalman ZM-850HP, старичок, уже отработал 24\7 больше 7 лет, тьфу-тьфу, до сих пор идеален по всем линиям

Проблема DPC Latency решается очень забавно, диагностика LatencyMon ничего не дает, тычет на dxgkrnl.sys и ndis.sys

На матери есть 6 нативных SATA Intel портов и еще 2 висят на отдельном контроллере Asmedia.
Как видите в конфиге, у меня используются все 8 портов.


Барабанная дробь...
ВНИМАНИЕ! Решение:)

Если к одному из двух Asmedia SATA портов подключен DVD-дисковод, тогда наслаждаемся цыканьем звука и красными шкалами на графиках диагностического DPC Latency софта каждые 10-15 секунд, иногда с перерывами.

Просто подключен, даже не крутящий диск, а просто подключенный самый обычный дисковод.
Если на Asmedia висят жд под жесткой загрузкой торрентами все ок.
Обновления, переустановки и прочее шаманство с дровами Asmedia ничего не дает.

Вот такое нетривиальное решение проблемы DPC Latency в моем случае. Страждущим советую попробовать поперетыкать SATA и обратить внимание на ненативные (вендорские, не чипсетмейкера), сторонние контроллеры и различные устройства на материнских платах. Ну и повыкидывать свои ссаные железяки от вендора gigabyte до кучи

Дело то в платформе и в вашей периферии, а то что Паскали просто чувствительны к качественной "пиле" на Pciex- просто эта особенность дополнительно предъявляет повышенные требования к совместимости-качеству биоса,драйверов,прошивок сторонних контроллёров на шине и их настройке.

Спору нет, топовая Вега обещает по всем утечкам быть в районе 1080ti -Titanxp -но что-бы прокачать такой аппарат- лично я смысла не вижу ставить такую карту- на старый чипсет и 2600 камень+ - да-же в разгоне. Если есть деньги на Вегу-вам на мой взгляд актуальнее и рациональнее платформу поменять до выхода карты- дабы обезопасить себя от подводных камней и узких мест в текущем и будущем времени. Для меня дико бы смотрелось P8Z68V-PRO, i7-2600k+ Vega топ или 1080ti. Но это только мои мысли и не моё дело, дело ваше

locobu
Когда устанавливал линукс-подобные ОС, с DVD-приводами тоже были проблемы: система долго грузилась, так как долго определяла этот привод на контроллере. Как только отключил привод, все встало на свои места. К чему я клоню: не факт что именно asmedia или другие ненативные контроллеры являются причиной задержек. Видимо, само ПО dvd-приводов вызывает конфликт с контроллером.