Все прерывания делятся по следующим приоритетам: 1 место - работает на уровне кольцо -2 прерывания SMI (system management interrupt — прерывание системного управления), которое возникает: -по сигналу от чипсета или периферии на материнской плате -программный SMI, посланный системным ПО через порт ввода-вывода -запись по адресу ввода-вывода, для которого микропрограммно установлена необходимость активации SMM. 2 место - гипервизор, который работает в кольце -1 3 место - ядро операционной системы - работает в кольце 0 4 место - пользовательский уровень - работает в кольце 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.
В Windows применяется: - для x86 - 32 уровня IRQL от 0 до 31 (в скобках указано числовое значение): High (31) Power fail (30) IPI (29) Clock (28) Profile (27) Диапазон аппаратных прерываний, называемых Devices IRQL, или DIRQL (от 26 до 3) или ISR DPC/DISPATCH (2) APC (1) PASSIVE (0) Это означает, например, что планировщик (работающий на уровне DPC/DISPATCH) может быть прерван аппаратными прерываниями, межпроцессорными прерываниями (IPI) и т. д., но не может быть прерван асинхронными процедурами (APC) и обычными потоками, работающими на уровне PASSIVE. Межпроцессорные прерывания IPI могут быть прерваны сбоем электропитания (прерывание на уровне Power fail), но не могут быть прерваны обычными аппаратными прерываниями от устройств и т. д. - для х64 16 уровней IRQL (от 0 до 15) High/Profile (15) Interprocessor interrupt/Power (14) Clock (13) Synch (12) Device n (11) ......... Device 1 (3) Dispatch/DPC (2) APC (1) Passive/Low (0)
При этом: hardware interrupts 3-15 (3-31) software interrupts 1-2 (1-2) normal thread execution 0 (0)
Наш пользовательский процесс может иметь следующие приоритеты: 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 считается еще неплохой. Второй путь - уменьшить длительность прерываний. Есть еще третий путь - освободить от прерываний нужные нам ядра.
Первое и самое главное. Установка максимально облегченной и очищенной системы. Если хватит windows 10, то лучше ставить ее. 23H2 лучше, чем 24Н2. Отключить динамический таймер. Поднять, а не снизить время для системного таймера до 15,625 мс! Если снизим до 0.5 мс, то увеличим количество прерываний. Но тут вступает в действие многозадачность винды. 1/4 времени отдается фоновым процессам. Минимум - это 6 тиков=2 кванта Полностью вырубить все фоновые процессы на винде мы не сможем. Для 120 кадров нам нужно иметь перерыв не больше 1/120=8.(3) мс. Поэтому подходит время для системного таймера только 0.5 мс /1 мс и условно 2 мс , так как 2 мс*2=4 мс. Внести в реестр для глобальной настройки системного таймера (работает только для win 11) [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel] "GlobalTimerResolutionRequests"=dword:00000001"
Отключить 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) и для системных прерываний=тиков.
useplatformclock disables TSC and uses the platform source clock instead (HPET or PMT). PMT is used when HPET is disabled in BIOS. useplatformtick disables TSC tick and uses the platform source tick instead (RTC). Does disabledynamictick work when useplatformtick is used? No, it does not do anything since RTC is not a dynamic tick counter.
При этом возможны разные комбинации таймеров.
TSC + TSC without desync: bcdedit /deletevalue useplatformclock - bcdedit /deletevalue useplatformtick (make sure HPET is enabled in BIOS) TSC + RTC: bcdedit /deletevalue useplatformclock - bcdedit /set useplatformtick Yes HPET + RTC: bcdedit /set useplatformclock Yes - bcdedit /set useplatformtick Yes (make sure HPET is enabled in BIOS) PMT + RTC: bcdedit /set useplatformclock Yes - bcdedit /set useplatformtick Yes (make sure HPET is disabled in BIOS) Частота HPET 14.318180 MHz, в 4 раза выше частоты ACPI PM Timer. RTC устаревший тайминг с частотой от 2-х до 8192 Гц. Использует кварц 32.768 KHz HPET требует больше времени на вызов, чем TSC или PM Timer, но это важно только для системных прерываний. HPET и PM timer находятся в южном мосте. TSC в процессоре. Поэтому вполне допустима комбинация HPET (для времени QPC)+TSC (для тиков).
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 минуты после загрузки системы. Не двигаем мышку и не используем клавиатуру в момент измерений. Потом остановка и скриншот.
В общем, по вопросу задержек. Оказывается такая проблема не нова. Более-менее проблема решена. Мои действия: 1. Я переустановил с windows 7 на Windows 10 (LTSB 14393). 2. Установил последний хотфикс на видюху. 3. Загрузил и установил обновленные дрова на звуковую карту Realtek. 4. В настройках звуковой поставил качество звучания на качество DVD (16 бит). Подсмотрел на англоязычных сайтах. 5. Установил в настройках панели нвидиа процессор Physx на GPU (на видюху) 6. Сделал undervolting видюхи. Проблема с видеокартой ПОКА отпала. Буду дальше тестировать. Сборка Windows от монкрус, если кому поможет.
Member
Статус: Не в сети Регистрация: 19.11.2012 Откуда: С фронта Фото: 7
sergielebedev писал(а):
В общем, по вопросу задержек. Оказывается такая проблема не нова. Более-менее проблема решена. Мои действия: 1. Я переустановил с windows 7 на Windows 10 (LTSB 14393). 2. Установил последний хотфикс на видюху. 3. Загрузил и установил обновленные дрова на звуковую карту Realtek. 4. В настройках звуковой поставил качество звучания на качество DVD (16 бит). Подсмотрел на англоязычных сайтах. 5. Установил в настройках панели нвидиа процессор Physx на GPU (на видюху) 6. Сделал undervolting видюхи.
7. Помыл руки 8. Поел. 9. Сходил в туалет Где во всём этом непосредственная связь с проблемой?
7. Помыл руки 8. Поел. 9. Сходил в туалет Где во всём этом непосредственная связь с проблемой?
Для вас, уважаемый Nik t-800: Я написал, что эта проблема НЕ НОВА. Далее, все вышеперечисленные действия каким-то "странным" и "нелогичным" для вас образом, снизили задержки DPC. Понижение напряжения в видеокарте, почему-то тоже (в моем случае) повлияло на уменьшение задержки DPC. Я всего-лишь поделился тем, что СРАБОТАЛО у МЕНЯ. До сих пор остается проблема со встроенной звуковой картой от Realtek. Но, это вопросы к софт-разработчикам. Хотя, последние драйвера улучшили ситуацию. Более того, я перечитал англоязычные форумы, на которых обсуждались данные проблемы и, как оказалось, они связаны не только с видеокартой, но и с другими компонентами. Т.е., я веду к тому, что данная созданная тема несколько "узкая" в понимании разрешения проблемы задержки DPC. Я тоже начал искать проблему только в одной видеокарте, но, увы и ах, проблема оказалась связана не только с ней. И, если модератор позволит, я создам другую тему "DPC Latency - проблемы и возможные решения". Как-то так. Хотя я не вижу в этом смысла. Можно создать FAQ, где будут выкладываться возможные решения данной проблемы.
Member
Статус: Не в сети Регистрация: 19.11.2012 Откуда: С фронта Фото: 7
sergielebedev писал(а):
Для вас, уважаемый Nik t-800: Я написал, что эта проблема НЕ НОВА.
Непойму акцент по поводу - Ново, не нова. Какая разница?
sergielebedev писал(а):
Далее, все вышеперечисленные действия каким-то "странным" и "нелогичным" для вас образом, снизили задержки DPC. Понижение напряжения в видеокарте, почему-то тоже (в моем случае) повлияло на уменьшение задержки DPC.
Проблема полностью устранилась или нет? Частичная устраняемость проблемы есть в самой шапки темы и в комментариях пользователей (в частности и моих). Ваши вышеперечисленные действия абсолютно разносторонние и не несут конкретики.
sergielebedev писал(а):
Более того, я перечитал англоязычные форумы, на которых обсуждались данные проблемы и, как оказалось, они связаны не только с видеокартой, но и с другими компонентами.
Ваши вышеперечисленные действия абсолютно разносторонние и не несут конкретики.
На чем вы делали выводы относительно неконкретики моих действий? Частично, в моем случае оказалась оставшаяся проблема со звуковой картой (1 компонент, а не несколько), а это уже достаточно, считаю, для того, чтобы выложить данную инфу здесь. Я всего лишь опытный пользователь, как и вы (с 1999 года) и делюсь информацией, а не авторитетным результатом, согласно исследованиям многочисленного профессионального штата, изучающего проблемы задержки DPC. Простите мою язвительность, но вы привыкли не думать,а получать готовое.
Nik t-800 писал(а):
Вот это поворот! Короче, пруфы есть?
ВУАЛЯ. Ниже, пользователь Alarchy дает ссылки на другие сайты относительно задержек. Есть и другие сайты. Не поленитесь и почитайте. Успехов вам. Просьба модератору. По-моему время уже орет, чтобы объединить темы в одну.)))
Тоже есть проблема на 1060 6G. В CS:GO при включенной тройной вертикальной синхронизации мышка очень сильно запаздывает, ощущение, что почти 0,3-0,4 секунды, при этом ФПС 200+. Без V-Sync вроде нормально (хотя мышь беспроводная и монитор IPS, так что небольшое запаздывание все равно есть). Так же в Resident Evil 7 запаздывает даже в меню на минимальных настройках. Пробовал отследить через Latency Mon - максимальная задержка около 1500микросекунд (1,5 мс), но по факту при этом была запущена контра и запаздывание было. Что это значит? У меня в чем-то другом проблема? Сегодня последний день обменять видеокарту.
Проблема была на Windows 7, так же осталась и на Win10
_________________ i7-8700/DeepcoolGammax 400(Arctic MX-4)/MSI Gaming X Trio 3070/2x8Gb Patriot Viper 4 3700Mhz/ASRock Z390 Pro4/Corsair RM750/Samsung 970 Evo Plus 1Tb
Member
Статус: Не в сети Регистрация: 16.05.2010 Откуда: Ленинград Фото: 545
BeeRAbuseR писал(а):
Альт-табался, там же Highest значение выводит, за весь период мониторинга, вот оно и было в районе 1300-1500
В момент альт-таба и будет скачок в мониторе,смена режимов оборудования. Монитор запускаете просто в простое машины после загрузки. Когда частота цпу переходит в энергосбережение. Это 1.5 минуты от загрузки +-
Если игры играют,это уже не брак,менять карту какой тогда смысл-остальное в вашей платформе и софте. Заполните профиль подробно и опишите конфигурацию железа-версии драйверов и биоса.+набор программного обеспечения.
Member
Статус: Не в сети Регистрация: 16.05.2010 Откуда: Ленинград Фото: 545
BeeRAbuseR писал(а):
мать ASUS P8P67LE GTX 1060 6Gb 378.77 BIOS ver. 1011 от 08.04.2011
Плохая совместимость с старыми чипсетами-уже обсуждали тут в ветке. Ваш случай вывел это уже в разряд потверждённой статистики с Паскалями.
У вас 2 варианта.
1) Если хочется оставить Нвидия и меньше "заморачиватся".
Обновить версию биоса до 3801 от 2014/05/22 - там целый вагон исправлений-включая предыдущие апдейты-улучшение pci-e. Тут я только рекомендую-все риски-делать или не делать-решения за вами. Ответственности не несу.
2)Поменять на радеон,действительно ,скорее всего будет всё хорошо сразу. Но кто знает-карта чуть "погорячее" и по "прожорливее" к питанию. Есть свои нюансы эксплуатации,но на радеоне dpc всегда хорошим был.
p.s Если возьмёте Амд-отпишитесь пожалуйста в тему с наблюдениями и мониторингом,для статистики-это многим поможет при выборе карт.
Member
Статус: Не в сети Регистрация: 18.02.2008 Фото: 0
Замена видеокарты с EVGA GTX 1070 на MSI GTX 1070 не решила проблемы. Мне помогло отключение: EIST, C-State, Speed Shift, Turbo boost, в винде Электропитание максимальная производительность. неделя полёт нормальный, загрузка GPU 100/99%, полегчало. так же отключение повысило минимальный FPS. Сейчас общаюсь с поддержкой MSI. те изучают влияния алгоритма Speed Shift, предварительно в этом дело.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения