ОПТИМИЗАЦИЯ ПРЕРЫВАНИЙ, ПРОЦЕССОВ, ДРАЙВЕРОВ, ПРИОРИТЕТОВ:

Требования:
1. Мозг
2. Process Hacker Или WindowsD (https://github.com/katlogic/WindowsD)
3. Msi Utility 
4. IAPT или GIP
5. ReservedCpuSets
6. 8 ФИЗИЧЕСКИХ ядер - минимум для положительных результатов
7. Отключенный HT/E-CORES
8. Мой Поверплан (По ссылке ниже)
9. https://mega.nz/file/kj0w2RbI#EE5OAufPZ ... KbfSe-BzIg
10. Network Adapter, который поддерживает RSS, MSI, MSI-X (если адаптер поддерживает RSS, MSI, MSI-X, но RSS неверно работает, то вот решение: https://github.com/djdallmann/GamingPCS ... t-windows)
11. Если вы собираетесь резервировать ядра, то убедитесь что вам хватит ядер оставшихся для вашей игры

Выбираем 3 ядра.
К примеру, у меня 8 ядер, поэтому буду рассказывать на своём примере.
4 ядро я выбрал для GPU.
5 ядро я выбрал для USB (имеется ввиду USB контроллер).
7 ядро я выбрал для инета (если бы у меня было две очереди RSS, то я бы выбрал для инета 6 и 7).
Поставить GPU, USB легко, даже интуитивно в IAPT.
(При выборе ядер учитывайте core-to-core latency (Не забывайте о CCD, так как, когда, например, игра взаимодействует с DWM, но DWM и игра находятся в разных CCD, то будет грустно.). Например, помните, что GPU (драйвер) взаимодействует с DWM, и если они на разных ядрах, то будет важен показатель CORE-TO-CORE LATENCY. Бенчмарк core-to-core latency: https://github.com/CXWorld/MicroBenchX). Но если вы уже побежали ставить DWM и GPU на одно ядро, то я вас обрадую, то что DWM на новых билдах также связан с драйвером USB aka WDF01000 (хоть и незначительно). Поэтому, ставя dwm на ядро с GPU, вы не только нагрузите ядро с GPU, но и создадите насильно дистанцию между ядром с USB и ядром, где стоит DWM. Поэтому лучше оставить DWM на всех ядрах, либо вовсе отключить его, если вы не юзаете FSO, т.к. DWM юзает много циклов и создаёт проблемки с аффинити. Но учитывайте, что на новых билдах обработка инпута полностью пересядет обратно на CSRSS.
А чтобы поставить инет, нужно сделать следующее (все параметры это не дворды, а стринги и звёздочка в них не лишняя):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0009(тут может быть не 0009 у вашего адаптера поэтому ищите надпись DriverDesc где будет написано имя вашего адаптера)]
"*NumRssQueues"="1" (это кол-во очередей)
"*RssBaseProcNumber"="7" (это ядро "первое" для RSS)

Когда мы это выполнили, мы можем переходить к ReservedCpuSets и изолировать(Резервировать) те ядра, где у нас стоит Инет, GPU, USB.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]
"SerializeTimerExpiration"=dword:00000002

Если вы резервируете ядра, то ставьте значение 2, так как это распределит прерывания системного таймера на несколько ядер и это может улучшить точность системного таймера и снизить показатель STDEV (подробнее о таймере и тестах на гитхабе Амита: https://github.com/amitxv/PC-Tuning/blo ... esolution). Но резервирование ядер сделает так, что система не будет ставить прерывания системного таймера на зарезервированные ядра и ничего не испортит.

Если вам для чего-то нужно автоматически перенести процесс на какие-то ядра, то для автоматизации сделаем скрипт в Powershell:
Get-Process @("svchost", "audiodg") -ErrorAction SilentlyContinue | ForEach-Object {$_.ProcessorAffinity=0x1}

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

Вместо цифры 1 (например, цифра 1 это для того, чтобы зафорсить процесс на 0 ядро, а цифра 2 это чтобы зафорсить игру на ядро 1), ставим нужную цифру в зависимости от ядра, определяя по этому калькулятору:
https://bitsum.com/tools/cpu-affinity-calculator/

Этот скрипт нужно запускать после каждого рестарта пк

(Также можно сделать скрипт, чтобы запускать какое-либо приложение с уже заданным аффинити. Чтобы поставить нужное аффинити, нам нужен такой скрипт: start /affinity 0x6 notepad.exe, где 6 мы будем заменять нужной цифрой для аффинити, определяя по калькулятору, а notepad будем заменять на нужный процесс.).

ОПТИМИЗАЦИЯ ПРИОРИТЕТОВ:
CSRSS-REALTIME (I/O приоритет-high) (Для старых версий винды (до WINDOWS SERVER 2022) или же для тех кто отключил DWM на новых).
DWM-REALTIME (НА НОВЫХ ВЕРСИЯХ, так как там DWM связан с мышью, да и в использовании FSO там ИНОГДА есть смысл) (Но я предпочитаю оффнуть DWM) (I/O приоритет-high) (Если отключить DWM на новой версии, то обработка мыши снова будет полностью на CSRSS).
ВСЕ МУСОРНЫЕ ПРОЦЕССЫ-IDLE (I/O приоритет-Very low).
ПОТОКИ: (Выполнять каждый ребут)
DXGMMS2-TIME CRITICAL (I/O приоритет-high).
NVLDDMKM-TIME CRITICAL (I/O приоритет-high).
ntoskrnl.exe!DbgSetDebugFilterState-IDLE (I/O приоритет-Very low).
Поток связанный с USB-TIME CRITICAL (I/O приоритет-high).
Есть и другие потоки, которые стоит настроить, но это нужно исследовать (Позже добавлю)


ОПТИМИЗАЦИЯ AFFINITY У ПОТОКОВ И CSRSS/DWM: (Выполнять каждый ребут)
За GPU отвечают: DXGKRNL, NVLDDMKM, DWM
За USB отвечают WDF01000, CSRSS, DWM(На новых билдах)
Но тут нужно исследовать (Насчёт Affinity) (Позже добавлю)

Бонусом, советую посмотреть на потоки вашей игры и те, которые бесполезные по типу аудио/оверлеев. Можно поставить на IDLE (приоритет) и very low (I/O приоритет).


Бонусом про потоки: "Ideal Processor and Affinity
A thread’s ideal processor and affinity determine the processors on which a given thread is scheduled to run. Each thread has an ideal processor that is set either by the program or automatically by Windows. Windows uses a round-robin methodology so that an approximately equal number of threads in each process are assigned to each processor. When possible, Windows schedules a thread to run on its ideal processor; however, the thread can occasionally run on other processors.
A thread’s processor affinity restricts the processors on which a thread will run. This is a stronger restriction than the thread’s ideal processor attribute. The program sets affinity by using SetThreadAffinityMask. Affinity can prevent threads from ever running on particular processors."
|||
То есть, не следует использовать технику "резервируйте ваши E-CORES и сбрасывайте туда весь мусор" из-за принципа работы IDEAL PROCESSOR. У потоков, например, вы зарезервируете E-CORES, но USB/GPU/ИНЕТ вы поставите на какое-то из ядер. И тут, например, поток DXGMMS2 выпадет на ядро, куда вы поставили USB. А если бы ядро с юсб было зарезервировано, то тогда бы IDEAL PROCESSOR игнорировался. Вы можете зарезервировать определённые P-CORES и все E-CORES, но включение E-CORES имеет кучу негативных эффектов. Поэтому врубать их просто чтобы поставить туда мусор учитывая, что важные ядра и так зарезервированы, это глупо. Поэтому надо отрубать E-CORES и резервировать ядра с важными драйверами. А мусору и прерываниям системного таймера дать сжирать все ядра без резервирования, чтобы нагрузка распределена была так, как если вы сделаете одно ядро наполненное мусором, и это ядро выберет за IDEAL PROCESSOR какой-то важный системный поток, то будет хуёво. Конечно, можно зарезервировать ядро с мусорными процессорами, но тогда вы отберёте у игры ещё больше ядер, просто для мусора. Но зато у вас будут отрублены E-CORES и мусор будет на отдельном ядре, на которое ничего важное не встанет. Так что это зависит от того, сколько ядер требует ваша игра.


Аффинити для диска в гайде не рассматривалось, так как почти все NVME диски не поддерживают смену аффинити и всегда будут стоять на всех ядрах.

MSI UTILITY:
Ставьте все устройства, которые поддерживают MSI в MSI MODE, и ставьте максимальные лимиты для USB контроллера/Сетевого адаптера, а для мусорных устройств по типу INTEL ME, ETC ставте лимит 1 (например, цифру 2048, так как Windows тогда сама выберет максимально возможный лимит для устройства). Приоритеты нужно поставить одинаковые у главных устройств, то есть нужно поставить GPU, USB, Инет, Диск на high, чтобы между ними не было приоритизации, но при наличии других устройств, чтобы они были выше. (Некоторые GPU (10/16 серии лучше оставлять без MSI MODE)

После всего этого, вы можете проверить результаты переноса через XPERF. Также нужно убедиться в выполнении отложенного вызова процедуры (DPC) для прерывания (ISR) на том же ядре. Например, чтобы DPC (от nvlddmkm) для прерывания ISR (от nvlddmkm) был на одинаковом ядре. Когда DPC и ISR выполняются на разных ЦП, требуется обмен информацией и данными между этими процессорами. Эта межпроцессорная коммуникация (а точнее её увеличение) может привести к увеличению задержки. А также, обработка DPC на другом ЦП может нарушить когерентность кэш-памяти. Когерентность кэш-памяти обеспечивает согласованность представления общих данных между всеми процессорами. Когда DPC обрабатывается на другом ЦП, он может обращаться к данным, которые хранятся в кэше другого ЦП, что может вызывать инвалидацию кэша и операции сброса/очистки кэш-памяти, а это руина производительности. Также, вы можете поиграться с потоками у системы или же с потоками игры/процессов.

(Этот гайд частично основан на разделе PER-CPU SCHEDULING из гайда PC-TUNING от AMIT)

MADE BY:
DISCORD: _iiiexoiii_
LOW LATENCY GAMING DISCORD SERVER: https://discord.gg/SHFKFfRFtS