Blur Busters Forums

hello guys, can we do some testings?



in short: SMI - smi - system management interrupt is type of event when device like thermal / voltage sensors triggers hardware event that forces the cpu to pause its current execution, save its state to smram, and jump to a high-priority firmware handler. this effectively "freezes" the system's time signature—halting the tsc and blocking all other i/o operations until the smm routine completes and returns control back to the os.

smi events: thermal monitoring and management for polling sensors and adjusting power limits, dynamic voltage regulation through vrm communication, power management for handling c-state , system error reporting for logging hardware issues, legacy hardware emulation

smm handler code: it's image stored in uefi firmware inside spi flash , it's accessed by spi flash controller in your pch, the image is copied to your smram which is reserved and hardware protected memory region.
SMI event itself is invisible to OS and is literally stealing your cpu time, if this events were handled and visible to os , it should be easily debugable and scheduled.

What i want you to test is increase spi bus speed:

Switch from auto/disabled to Enable

Setup Question = ESPI Enable
Help String = No help string
Token =116 // Do NOT change this line
Offset =62
Width =01
BIOS Default =[0F]Auto
Options =[00]Disabled // Move "*" to the desired Option
*[01]Enabled
[0F]Auto

Setup Question = HID Enable
Help String = No help string
Token =119 // Do NOT change this line
Offset =AD
Width =01
BIOS Default =[0F]Auto
Options =[00]Disabled // Move "*" to the desired Option
*[01]Enabled
[0F]Auto

Setup Question = HID Spi Read Mode
Help String = No help string
Token =11A // Do NOT change this line
Offset =180
Width =01
BIOS Default =[05]Quad IO 1-4-4
Options =*[05]Quad IO 1-4-4 // Move "*" to the desired Option <--- keep this default
[04]Dual IO 1-2-2
[07]Fast Read 1-1-1

Setup Question = HID Spi Speed
Help String = No help string
Token =11B // Do NOT change this line
Offset =181
Width =01
BIOS Default =[07]spi_spd7
Options =[01]33MHz // Move "*" to the desired Option
[02]22MHz
[03]17.6MHz
[05]800KHz
[06]spi_spd6
*[07]spi_spd7 <--- use highest possible frequency or spd profile

Locate your spi spd profile and change the freq:

Setup Question = HID Spi Speed7 N
Help String = Spi Speed7 = 200Mhz/HID Spi Speed7 N
Token =11D // Do NOT change this line
Offset =183
Width =01
BIOS Default =32 <--- default
Value =4 <---change it lowest possible value u can , most likely to be 4.. 200/4= 50 mhz

Change this to "distributed" !

Setup Question = Location of private memory regions
Help String = Controls whether or not the private memory regions (PSP, SMU and CC6) are at the top of DRAM, at the top of 1st DRAM pair or distributed. Note that distributed requires memory on all dies. Note that it will always be at the top of DRAM if some dies don't have memory regardless of this option's setting.
Token =43 // Do NOT change this line
Offset =1C5
Width =01
BIOS Default =[FF]Auto
Options =*[00]Distributed // Move "*" to the desired Option
[01]Consolidated
[02]Consolidated to 1st DRAM pair
[FF]Auto


What we did: increased bus frequency when spi controller reads vars from uefi
Private regions distributed: SMU buffers are spread evenly across both memory channels instead of concentrated on one. SMM handlers that touch these regions get parallel channel access, reducing SMI handler duration and jitter INCREASING responsiveness
Runs absolutely perfect for me

unrelated to main post /////

observation 1: hid implementation bugs across multiple platforms and motherboard vendors—including z790 gigabyte aorus, z790 asrock nova, and x870 apex—consistently cause high-polling-rate mice like the razer deathadder v3 and endgame op1 to default to incorrect, significantly lower polling rates (250hz, 500hz, or 800hz) upon system boot. this persists despite having the latest firmware installed on both devices, and the only reliable way to force the controller to renegotiate the intended 8000hz connection is a physical replug of the mouse. Each time you start pc , check your polling rate https://cpstest.org/polling-rate-test/

observation 2 : u can play whole day deadmatch and everything just "works enough", then u decide to play some premier or unranked, as you play the warmup it's pretty much same as when you played the deadmatch, u're owning people while waiting another players to connect and when they do and game goes live , mouse sensitivity and mouse responsiveness is instantly worse. Also , in my case there is like 0.25ms hard freeze after warmup timer ends and scene transition goes to team overview scene (scene where you see your teammates and their skins, same that plays after game ends).

observation 3: for users with external usb audio interfaces like the scarlett, enabling the "usb audio controller" setting is mandatory, without it, the system experiences audio dropouts and severe inconsistencies in spray and hit registration, even when dpc latency appears low.

in addition to this settings, u can keep spi read mode on quad io 1-4-4 and for hid spi speed u can choose from avaiable profiles if your bios offers it, like i have spi_spd6 and spi_spd7, by default its using spi_spd7 which runs at 6.25mhz by default

Setup Question = HID Spi Speed7 N
Help String = Spi Speed7 = 200Mhz/HID Spi Speed7 N
Token =11D // Do NOT change this line
Offset =183
Width =01
BIOS Default =32 <-------
Value =4
as you can see bios default speed is 32/ 200/32= 6.25 mhz, but using value 4 gets me 200/4=50 mhz

this actually makes a lot of sense why this could be the cause an why we CANT measure it by any benchmark tool. It's not directly tied to any usb issue , its tied to embedded controller a chip that collects various informations about system state. And reason we can't measure it is , because its f***** SMI interrupts that are invisible to kernel. For people that don't know there are several type of interrupts.
irq > normal one. device fires > cpu handles > os sees everything. measurable, schedulable, debuggable.
nmi > non-maskable. cpu can't ignore it, but still visible to os. usually hardware errors, watchdog stuff.
smi > system management. cpu drops into smm, runs firmware code, os has zero visibility. no counter, no trace, no perf event catches what happens inside. only thing you get is msr showing how many fired, never HOW LONG THEY TOOK
sci > acpi events. ec sets a bit, os gets notified via normal irq path, kernel runs the handler. clean, fast, non-disruptive.
so when your fan curve updates, thermal sensor gets polled, ec syncs voltage or oc parameter > that runs as smi on most desktop boards. cpu freezes, firmware talks to ec over espi, cpu resumes. at 6.25 mhz espi that conversation takes forever. at 50 mhz it's 8× shorter.
benchmark tools measure what the os can see. smm is not one of those things. your fps counter is fine, your frametime graph is fine, your latency tool is fine, and meanwhile cpu is periodically deaf for hundreds of microseconds and no software will ever tell you.
and what is smm actually? system management mode. a separate cpu execution mode that sits ABOVE the os, above the kernel, above ring 0. when smi fires, cpu saves its state, switches to smm, runs code from smram (a locked memory region only smm can touch), then restores state and returns. os never knows it happened. it's not a process, not a thread, not a driver > it's the cpu literally leaving the world your os lives in and coming back later. So maybe whole time while we modding our bioses, except some really impactful things like clock frequencies or ram timings we're mostly disabling stuff that we don't need ( i dont know about you guys but i strip everything) while there may be some improvement in gameplay its mostly because pc now generates less smi interrupts which is what we want but also we want SHORTER time that cpu spends in smm, and thats where this clock frequency of this bus matter.

nice finds!

It's a pretty noticeable difference but it's like everything else, a drop in the ocean.

Hey agN, I have the same symptoms as you. Whenever I play deathmatch or warmup the delay isn't there. its only during rounds. I'm 90% sure its got something to do with the Internet and not the pc itself. During rounds, the udp gaming packets being sent are much higher than when the round hasn't started.

I have a Rog strix b550-f gaming motherboard. The way the chipset works on the motherboard is it shares lanes with the usb/internet connection traffic. I bought a separate pcie usb card, as well as a pcie wifi card but it didn't work.

The reason why I'm really certain its the internet connection is because every time I reset the ethernet driver, or wifi driver the delay goes away and its the most noticeable whenever I make a change to the wifi driver or ethernet driver, that's when I notice the most difference. Over time it accumulates "bad traffic" which causes the delay. I know there are a few forums in here that say the delay is still there with the internet drivers disabled, so I understand if this isn't for everyone.

I was just wondering if people could reply to my message with a few similarities to my situation so we might be able to figure out what's the cause.

------------------------------------------------------------------------------

My motherboard has an I225-V Ethernet adapter. I don't think this is the issue because I've tried a pcie wifi card as well as a usb wifi adapter and the same delay comes back.

My ISP is virgin media and I'm not on fibre. I'm not sure if this matters, but let me know if anyone has fibre and still experiencing the same.

I bought a 3rd party router made for gaming and set my hub 5 to modem mode to see if it might fix it, but it didnt.

I live in a house with a lot of people, could this be causing bad traffic being sent in some way?

does your motherboard share lanes with usb/ethernet?

does anyone know if its possible if bad internet traffic, or delayed traffic from an ISP can affect mouse inputs.

If anyone has the same similarities as me let me know. If you don't have the same similarities and still have the input delay, also let me know so I can figure out which ones aren't the issue.

You were supposed to be done with this topic because nothing worked and everything just felt like a placebo to you.

Muji wrote: ↑

18 Jul 2026, 05:29

Hey agN, I have the same symptoms as you. Whenever I play deathmatch or warmup the delay isn't there. its only during rounds. I'm 90% sure its got something to do with the Internet and not the pc itself. During rounds, the udp gaming packets being sent are much higher than when the round hasn't started.

I have a Rog strix b550-f gaming motherboard. The way the chipset works on the motherboard is it shares lanes with the usb/internet connection traffic. I bought a separate pcie usb card, as well as a pcie wifi card but it didn't work.

The reason why I'm really certain its the internet connection is because every time I reset the ethernet driver, or wifi driver the delay goes away and its the most noticeable whenever I make a change to the wifi driver or ethernet driver, that's when I notice the most difference. Over time it accumulates "bad traffic" which causes the delay. I know there are a few forums in here that say the delay is still there with the internet drivers disabled, so I understand if this isn't for everyone.

I was just wondering if people could reply to my message with a few similarities to my situation so we might be able to figure out what's the cause.

------------------------------------------------------------------------------

My motherboard has an I225-V Ethernet adapter. I don't think this is the issue because I've tried a pcie wifi card as well as a usb wifi adapter and the same delay comes back.

My ISP is virgin media and I'm not on fibre. I'm not sure if this matters, but let me know if anyone has fibre and still experiencing the same.

I bought a 3rd party router made for gaming and set my hub 5 to modem mode to see if it might fix it, but it didnt.

I live in a house with a lot of people, could this be causing bad traffic being sent in some way?

does your motherboard share lanes with usb/ethernet?

does anyone know if its possible if bad internet traffic, or delayed traffic from an ISP can affect mouse inputs.

If anyone has the same similarities as me let me know. If you don't have the same similarities and still have the input delay, also let me know so I can figure out which ones aren't the issue.

No i dont think it has something to do with internet, i think the reason it gets noticable really worse when game goes live is because: 1. anti-cheat increased activity on i/o 2. vproflite , the internal benchmark tool that monitors your frametime, framerate , p99 latency and more starts triggering this even more and i don't know why but interestingly similiar effect happens in cs 1.6 when you manually start recording a demo.
Hyote: Thats perfect u see noticable difference, because it says we're looking at good way. It's both smi count and time cpu stays in smm which can be reduced by this trick and by this logic i think it makes sense to let os control as much things he can instead of bios, the most triggered smi events would be i guess thermal monitor and fan control.

The USB port roulette problem is getting increasingly sophisticated! It was concluded a long time ago that the issue stems from the USB ports. Some motherboards have one or two usable low-latency ports, while most motherboards have all of them malfunctioning. Try buying a PCIe USB card with an NEC chip; if that doesn't work, return it. Currently, this is the only solution.

Sandy wrote: ↑

19 Jul 2026, 04:32

The USB port roulette problem is getting increasingly sophisticated! It was concluded a long time ago that the issue stems from the USB ports. Some motherboards have one or two usable low-latency ports, while most motherboards have all of them malfunctioning. Try buying a PCIe USB card with an NEC chip; if that doesn't work, return it. Currently, this is the only solution.

i removed my xhci reneasas card due to no effect but keeping my intel nic card due to lower cpu overhead. did you tried the spi bus speed trick?