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

kiberman каким софтом можно биос редактировать?надеюсь не HEX редактором в слепую)))

Боже упаси

AMIBCP 4.55.0070 и Uefi bios updater. Для разлочки вам нужна первая, у неё Гуи интерфейс,открываете дамп-там всё понятно. В теме выложены статьи как и что.

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

Модификация AMI Aptio UEFI биосов. Софт для работы. Обновление Option ROM и EFI модулей.

Первый вариант разлочки, без программатора и полного дампа я вам не рекомендую-получить кирпич можно. На конкретной плате проверять надо.

Не несу отвественности. Uefi updater проверен в работе не однократно-отлично,но то-же требует знания матчасти. Программатор за 3-4 рубля,позволяет избежать проблем.

kiberman вскрыл биос программой AMIBCP 4.55.0070 но не могу там найти параметр HPET. там просто все стандартыне менюшки и можно выбрать отображать или скрывать их в биосе и что использовать по умолчанию, а что за полный дамп? типа свой текущий биос слить программатором что бы если что восстановить?

Вы должны открыть дерево разделов,и посмотреть опции в каждом подразделе,есть ли в графе Show значение No.
Что бы открывать всё- для всего раздела просто меняете опцию Default на User.
Полный дамп-с регионом Me,вашими данными платы,мак адресом сетевой,короче слепок. Слить можно программой fpt -низкоуровневым прошивальщиком или программатором, бинарники эти шить можно только ими. Файлы с кепкой-cap. шить ими нельзя.

Вот пример

https://forum-ru.msi.com/index.php?topic=85630.0

Но повторюсь без программатора не пытайтесь.

kiberman дак дело в том, что у меня ВСЕ настройки включены уже, нигде нет галочки NO

Счас гляну биос от вашей платы напишу

Есть разделы и параметры-откройте ветку сетап-посмотрите в подразделах,но все с доступом default.

Выставить глобально я имел ввиду https://forum-ru.msi.com/index.php?topic=85630.0

потом проверяется на работоспособность. Вариантов 3-ничего не открывается-производитель залочил,кирпичь,и открывается.

HPET нужно отключать однозначно, как вообще может высокоточный таймер работать быстрее? А он и не может, в большинстве случаев с ним задержки больше, но это зависит от его реализации на мат плате. Сужу по времени выполнения разных вызовов. С HPET время не просто выше, а в десятки и сотни раз выше! Померяемся?)

http://www.satsignal.eu/software/net.htm#PCClockTiming
http://www.nvidia.com/object/timer_func ... mance.html

TimerResolution v2 у меня меняет между 1.0 и 0.5, никакой разницы я не заметил.

Mikanoshi у меня вообще частота счётчика 2,8 МГц... обнаружилась другая беда, в Диспетчере Устройств, где Вид > Ресурсы по подключению > Запросы на прерывание обнаружилось, что тупой Хуанг повесил карту на IRQ 16 и она не в режиме message signaled interrupts, в скобках не минусовая цифра. Такое говорят есть у многих. Соотв. на этом прерывателе висит ещё и штеудовский Intel(R) 6 Series/C200 Series Chipset Family PCI Express Root Port 1 - 1C10 из Intel INF за 2016й, возможно он туда и повесил карту, в легаcи режиме line based interrupts теперь пытаюсь разобраться как его вернуть MSI режим. Говорят это опасно и можно поломать вендух

В добавок к моему предыдущему сообщению, еще одно видео, но уже в случае с 3гб версией 1060. На ней все так же плавно.

А на каком прерывании она должна быть если весь обмен данными идёт через шину pci-ex. Общее адресное пространство-локальный(видеопамять) и нелокальный видеобуфер(Озу).

Msi может добавить не стабильности и не более,на некоторых машинах бсоды. Нужно ли переключать то-же вопрос -может там уже нативный режим. В задержках не увидел на глаз разницы.

http://www.intel.se/content/dam/www/pub ... -paper.pdf

Она и должна быть в обычном режиме IRQ, MSI вручную надо ставить. Утилитой быстро:
http://www.mediafire.com/download/hrxw4 ... I_util.zip
У меня не поломалось ничего)

#77

читал у АМД сконфигурировано в MSI режиме, может поэтому у них вечно Вучдогс 2 летает на рабстол с последними ReLive единственное что у меня в PCI воткнута сетевуха и она тоже висит на 16й IRQ, при том что риалтек на чипсете в MSI режиме, как и SATA AHCI штеудовский. Какая вообще должна быть латентность бен его знает, обычно показывает 1-2 зелёных кубика, но иногда dxgkrnl выдаёт аж 207 на ровном месте, также mvlddmkm набил 238 мс. При сетевухе отключенной в диспетчере. Что там в Паксвеле натворили даже хз, видимо Хуанг очередной раз урэзал шынЪу до 256 битов на картах уровня тишки, или более чем тишки, а печ1060 вообще запомоили

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



Нет никакого конфликта,это совместное использование,так работает pci.

Добавлено спустя 56 секунд:


Вобще бредятина,причём тут dpc

да как не может быть конфликтов при совместном использовании одного и того же IRQ, если бы не так его не назвали бы interrupt query... если включить сетевуху она начинает чемпионить с 242 мс задержками (tcpip.sys), может и совместно, но тоже задержки оно создаёт. Это я посмотрел после того как на Вайтран как обычно налетели вомпирЪы, у меня два треля, Лидия и Серана по квесту тащится, и началась резня с кучей молнийну как при чём, а вдруг фризаки в Вучдогсе 2 будут на ультре

Совместное использование и конфликт-2 разные вещи. Шина pci допускает совместное использование прерываний. В данном случае это оно и есть.

А ваши задержки на Tcp. от проблем на стеке или сетевой активности. Прверяйте настройки драйвера,обновляйте его,крутите фаервол и Ав если есть. Всё описывать не буду-проблему вы не там ищите. Как сеть организована-провайдер,прямое подключение или роутер,мобильная.

а проблемы в духе "у меня было 2514 мс DPC exexution time на nvlddmkm.sys" у меня сроду не было, там наоборот 238 мс ещё лучше, чем у автора темы. Видимо Highest measured interrupt вовсе не дрова набивают, а что именно тупой LatencyMon сроду не показывает

Такие задержки были единичны и до dpc fix и после-причина была с работой интерфейсов,высоко частотными мониторами,и оптимальным энергосбережением,у меня нет статистики что это повальное явление.
Люди собирают Пк на Нвидия играют и радуются,объем продаж говорит.


Набивет этот счётчик контроллёр диска и служебные обращения к подкачке и вобще к диску
. Ос постоянно ведет логи и у неё есть множество задач.

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



1080 будет гарантированно быстрее и при любом раскладе в плане комфорта лучше кросса,карты новые, ось то-же,надо посмотреть ситуацию после мартовского редстоун 2, критичного ничего нет-всё работает.

а какую собственно затею я должен бросить, если я ничего сроду не затевал и не собирался? 4 дня тому назад в ветке дров уже разжевали вопрос с MSI режимом, профита нет и нестабильно. Видимо АМД хотят, чтобы у них в марке было меньше попугаэ, вот и выставили

kiberman писал(а):

Набивет этот счётчик контроллёр диска и служебные обращения к подкачке и вобще к диску

ну так и сказать "у Вас 13121 мс interrupt to process latency потому что нет SSD", иначе было бы всего 600 мс, но некоторые начинают нести бред про незнание матчасти каких-то шин PCI, как вроде остальные эту матчасть знали, а не лазили смотреть какой IRQ использует карта в дрова Хуанга, вместо Диспетчера вообще на кой бен нужна тут матчасть, я ж не собираюсь править биос, к примеру

Знание про матчасть чтоб вы бред не несли про конфликт сетевой и видеокарты. В любой железной литературе по устройству шины всё написано. и это даже не дебри- базис,эти знания не нужны для правки биоса.
Они нужны чтоб не пороть **?:?:;%%(ерунду) и лесть в монитор с полным не пониманием. Почему на старом ведре такие значения. Так яснее?.

По поводу Амд.
На современном железе шина pciex работает прозрачно для системы-вероятность что карта Нвидия работает в msi-есть,о ней рапортует информ менеджер драйвера карты,что прерывание не используется.

Об этом косвенно говорят и результаты. Всё уже выставила мат плата и чипсетный драйвер в ос.
,что там диспетчер показывает конкретно на pci- дело десятое. И если Амд полируют драйвера для работы в родном для шине режиме-только аплодировать.

Что вы с апломбом лезете в темы которыми не владеете? Задержки у вас на tcp? Вычистите своё "ржавое ведро"- настройте,поменяйте драйвер на сетевую или саму сетевую. А говорить вот драйвер Нвидии виноват. Фикс был полгода назд. И до фикса были единичные случаи.

Если бы это было нормой,гарантийка бы и сервис лопнули бы давным давно. Поиск фризов начинается у невежд по схеме:
1)Фризит!
2)Открою монитор! Задержки!!!!! Нвидия- виновата!!!!!!-напоминает майдан Киевский.
3)Безуспешный поиск и вопли без фактов.

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

Потом если вдруг проблемы используется как доп инструмент.

kiberman последний раз уточняю, под конфликтом я не имел в виду намертво зависшие дивайсы на шине ISA, я говорю о Sharing одного и того же IRQ 16, ведь передача данных с карты будет прервана ради того чтобы сетевая отослала пару пакетов, возрастает общая латентность обеих драйверов. Не нужно считать собеседника идиотом, и люди в Вам потянутся. За сих желаю всего наилучшего.