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

у меня счас так:

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

Настраивать инпут лаг лучше на мой взгляд в однопользовательских играх. Что касается оборудования и конкретного определения- инпут лаг в играх. Лимитирует его - частота обновления монитора,+фактический фпс с настройками,и тип матрицы+ подключение к вк(dvi,hdmi),само собой энергосберегающие.

Отсюда гонка "киберспортменов" за по сути бесполезными "маркетинговыми" мониторами 144гц и выше, потому-что у таких частот есть свои существенные недостатки и ограничения.

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

Другой момент на ос версиях карт и таких мониторах- могут быть проблемы с сбросом частот- особенности работы видео тракта, и самый главный не достаток- нужны мощности для обеспечения 144 фпс без "тиринга и ваты с vsync" , если для простых игр и сетевых не нужен 1080ti. То для современных тяжёлых - таких мощностей нет- стабильную минималку в 144 никто "не вывезет". это вопрос 4-5 поколений карт и года 20-21 ого. Ниша таких мониторов-пара игр,что уже само по себе имхо глупая трата денег.

А пока обычных 60-75гц с хорошей матрицей хватает вменяемым людям за глаза. Про windows 10 отдельная тема-ось сама по себе сильно влияет на это-очень много хлама,сетевой активности,и кривой менеджер окон+dvr режим - возможно fall creator update будет лучше. Для сетевых игроков могу порекомендовать только windows 7.

Alex TOPMAN, доступ к таймерам, находящимся вне системной шины(ring bus(intel), HT, Infinity Fabric(amd), одинаковый, задержка создается не самими таймерами, а типом доступа у ним, LAPIC и HPET имеют почти одинаковую задержку и ТОЛЬКО tsc быстрый из за того, что находится непосредственно в зоне доступа шины проца. (http://aakinshin.net/blog/post/stopwatch/)
Задержки в latnecymon dpc latency checker как минимум надо проводить с отключенным состоянием простоя(C state) в ВИНДЕ. Многие просто слепо верят в цифры, отключают все в биосе, хотя на самом деле они больше теряют, чем получают(меньше задержка в простое, где она совершенно безразлична(разве что для музыкантов и аудиофилов и то спорно) vs. большее энергопотребление + неправильно работающий турбобуст, если без разгона(на интелах что получить тб 1 ядра или двух, требуется чтоб остальные были в C состоянии) На самом деле, даже с включенным C state в биосе, задержка в нагрузке одинаковая, могут быть небольшие задержки, вызванные уже скорее несовершенным ПО, ненастроенными планировщиками, которые кидают потоки не учитывая состояние ядра(все настравивается).
Проблемы с HPET могут быть обусловлены так же его настройкой, в райзен например, системе заточенной только под 64 бит ПО, hpet работает в 32 бит режиме, хоть он и изначально 64 бит, и даже в 64 бит режиме он совместим с 32 бит, там по умолчанию он делится на 3 программных таймера 1 64 и в по 32, которые строятся из одного так сказать хардварного, так вот они решили, что хардварный надо обрезать до 32 бит... За инициализацию, настройку отвечает AGESA, написал в амд, третья неделя без ответа...
Столько не тестил на i7 950, i5 3570k, ryzen 1600, лучше всего работает все в дефолте + просто план высокой производительности в винде(8-10)+ минимальное состояние процессора на 5%, в 7 в дополнение к этому просто отключать переопределение ядра приостановки и минимальное количество число ядер в состоянии простоя на 100(отключаем парковку).
Так же синхронизация таймеров работает не на всех платформах. То есть по умолчанию TSC, на интеле если хардварно выключить hpet, то GTC будет иметь другую частоту, т.к. TSC синхронизируется уже с LAPIC,другой частотой, то есть работает как программный таймер TSC + HPET|LAPIC, такое я заметил точно на i7 950, на 3570к не чекал, на амд такого нет, что бы ты не делал с hpet используется родная частота tsc без синхронизации, всегда одинаковая.
Если пояснить проще, есть такие результаты некоторых определенных платформ интела:
1)TSC+LAPICs Low performance (slow timers + syncing) = 2.76MHz
2)LAPICs low performance (slow timer - no syncing) = 3.5Mhz
3)TSC+HPET medium performance (slow and fast timer + syncing) = 3.8Mhz
4)HPET high performance (fast timer - no syncing) = 14.3MHz
А для амд, TSC+LAPICs и TSC+HPET будут одинаковы = частота TSC.
Useplatformclock я бы забыл как страшный сон, enhancedsync неизветно вообще как работает и как влияет и влияет ли вообще и на какие платформы, disable dynamic tick в теории да, может уменьшить задержку, опять же больше относится к простою, либо непостоянной нагрузке.
UPD: забыл просто планы энергосбережения, на задержку хорошо влияют ASPM шины PCIEx вполне прилично, на некоторых МП настройки ASPM скрыты в биосе,а ведь по сути PCIEx связывает все элементы, а именно самый важный это южный мост с ЦП, и получается, что с южного все данные могут идти с задержкой в зависимости от непостоянной нагрузки, столкнулся с этой проблемой на трех МП 1155 сокета, dmi link aspm control настроечка скрыта и включена, в винде ASPM по умолчанию отключен только в плане высокой производительности, так же PEG ASPM conrtol, PCI Ex от южника все 8 линий так же отдельно имеют настройку, в райзене вообще не нашел этого в биос, даже в AMIBCP, там все контроллируется виндой, причем при отключении ASPM в винде на райзен, падение задержки с юсб портов реально чувствуется...

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

Корректной работе Турбобуста С-уровни не нужны. Eist опирается на P-state. Случаи "ленивых разрабов" материнских плат с кривыми биосами не рассматриваю. или когда опции просто по умолчанию нет,и выставление с-state в disabled- вырубает eist.



Была статья на оверах где твик реестра был открывающий все настройки в плане питания.

Об этом в той статье речь?

да.
По умолчанию параметр и так есть, у Интел можно почитать на тему энергосберегающих ,документ нудный и много воды, но полезная инфа то-же есть. https://software.intel.com/ru-ru/articl ... e-c-states

А HPET в BIOS/UEFI как выставлен? И чем обусловлен выбор по вашему же не самой оптимальной (для игр) конфигурации?

Как-то так, да. У меня специально для этого стоит второй системой урезанная по максимуму 7-ка. Хотя в W10 v1709 вроде как тоже все достаточно неплохо в этом плане, но надо будет более внимательно потестить.

выключен.

ощущениями. Я вчера/позавчера посмотрел тот старый пост и удивился что установлена была не оптимальная конфигурация.
После этого я еще раз проверил в игрушке и по ощущениям лучше когда оба параметра "no"

Да соглашусь,второй день уже стоит билд 16299.15(1709) - в целом ничего плохого пока сказать не могу. Отзывчивость хорошая. Ещё к официальному релизу Нвидия должна выкатить что-то новее 387.78

kiberman, Имелось ввиду, что проверять DPC с включенным C state в простое не имеет смысла. Многие пишут, что выключение С state в биосе творит чудеса, когда на самом деле в нагрузке разницы почти нет. Турбобуст одного и двух ядер зависит от C state, и только остальные от P state, и отключение С State ни коем образом не влияет на работу EIST и управляемыми им P State.
Просто пример на 3570к, с state включен = в простое 1 ядро 3800, 2 3700, более 3600. Без С всегда ТБ будет не более 3600, P состояния при этом работают, частота падает до 1600...
По поводу "твика" а точнее, программки от уважаемого Serj, я думаю все давно знают, и поэтому не уточнял, чем и как менять эти настройки, да и тем более и без нее можно обойтись, Regedit у всех есть, powershell почти у всех...
Для тех, кто вообще не в курсе: Некоторые аспекты энергосбережения Intel Core i* and Windows
UPD: хотел бы добавить еще, так же вляют AHCI link power management, а именно HIPM режим работы, и Adaptive ALPM. Так же USB3 LPM со совими u состояниями.
Во многих жестких дисках AAM и APM могут создавать задержки. Это все так же будет влиять и зачастую в большей мере, нежели настройка энергосбережения проца...
Я если на своем сеагейте терабайтном с одной пластиной не выключаю APM, вообще жуть получается, ставлю WD синий тоже на терабайт, там с APM даже никаких задержек. Тоже от реализации и ПО контроллеров зависит много в хардвари.

День добрый!

У себя не наблюдаю такого с-state disabled , одно ядро качегарится до 4.4- возможно у вас баг биоса, особенность платформы или так настроено, в документе интел по крайней мере так и пишут турбобуст- пакетное п состояние,а все ядра или нет не знаю.

Говорил выше наблюдал кривую работу турбобуста на другом железе с отключением ц состояний,но тут я уверен это реализация биоса или старая платформа+цпу, возможно у вас так.

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


Да соглашусь-очень влияют,но не все это "крутят"-. С установкой ssd решил множество проблем,и отказался от rst драйвера. У меня регулировка AHCI link power management чуть улучшает скорость в бенчах и чтение мелких файлов- по CrystalMark.

значит надо и EIST отключить

iG0Lka, в идеале да, но разница DPC в p состояниях очень мала. Даже если сравнивать проц на 1600 и 3800 мгц. Только при очень больших нагрузках, наверное только linx, будет разница во время теста. Да и скорость смены P состояний велика, при реальных задачах, например игры, это будет влияет только в случае плохой оптимизации игры или работы планировщика задач для цп, который будет постоянно швырять потоки туда-сюда, как это есть на 7, если не выключить переопределение ядра производительности.
kiberman, да, возможно реализация TB 3 и 4 поколений отличатся. С работы приду, гляну в спецификациях интел... Та система ТБ и с состояний действительна для ASUS P8P67 PRO 3.1, GA H61 d2v, MSI Z77 GD65 + 3570k.

я несколько туповат в этих тонкостях если можно по подробней , как и где это дело можно выловить
В смысле где эта хрень в планировщике и как вырубить

Сейчас в Стиме и Юплей дают бесплатно поиграть в Ghosts recon wildlands , так вот в этой игре у меня сильнейшие фризы через каждые 10 минут примерно Даже в кат сценах бывают! Кто нибудь скачайте поиграйте минут 30 хотя бы и скажите у вас также? Подозреваю что на Паскалях у всех так из за DPC latency

Граждане, как проверить текущее состояние
disabledynamictick и useplatformtick - включены/выключены?
Гранмерси

bcdedit /enum