Discussion in 'Operating Systems' started by mbk1969, May 7, 2013.
NVIDIA videocard and High Definition Audio controller sharing IRQ is not good, but if you do not output audio through videocard the problem is small. But I see another device using same "IRQ 16". Also I see two completely unrelated devices sharing "IRQ 17". I would switch all capable devices to MSI mode.
Actually I switched everything except of the Synaptic SMBus Driver and the CUDA, PhysX and everything else seems ok. Not sure what bugged before, might be because of multiple stuff combined. I like trying out things. Bad part is when you don't notice something broke
So I guess it was a combination of things and Windows. As always, thanks for your effort and help!
Unexpected behaviour here.
I set all supported devices to MSI. IRQ's don't conflict.
The network interface "Killer E3000 2.5 Gigabit Ethernet Controller" has begun resetting. There will be a momentary disruption in network connectivity while the hardware resets. Reason: The network driver detected that its hardware has stopped responding to commands. This network interface has reset 1 time(s) since it was last initialized.
I get this a lot now, which is new. I changed them so GPU and "High Definition Audio Controller" are Legacy and the issue went away.
This is caused by the new AMD agesa
Why not changing NIC alone to legacy?
Also Killer NICs are known for causing troubles.
Yeah that's what I've done now. I just wanted to confirm this as the cause.
Hello everyone! I tried to test MSI mode by myself (RTX 2070, latest driver) and for me it feels that MSI mode has MORE latency but just a little bit. I don't know, maybe it is placebo. I found some strange info that nvidia cards use MSI mode even if it shows positive IRQ in device manager. The string IRQ: not used in NVCPL is confusing in this case. In theory MSI is better but there may be nvidia tricks here. So I want to know that is technically better solution. Enable MSI mode for Nvidia videocard or not?
PCIE doesn't use legacy interrupts in the way that PCI and ISA happen to, it emulates them across the native messaging interface that pcie uses, MSI's skip the emulation and are more efficient use of the bus, and also allow for multiple MSIs on the same endpoint.
Which latency - ISR or DPC? MSI or legacy modes do not affect DPC stage so they can`t directly affect DPC latency. They can affect only indirectly: in theory ISR stage of interrupt handling is better in MSI mode so the shorter ISRs the less they influence other code in the system (DPC included).
Yeah, we all want to solve that mystery. But Device Manager is final judge here - positive IRQ number means legacy mode.
I think that mouse is more responsible in legacy mode. I am competitive FPS gamer, so I can tell if there is change in input lag. But I am not confident yet, so I will check latencies in LatencyMon.
Anyway it is strange for me, because MSI is technically better. But nvidia drivers for some reason dont run MSI natively, so I assumed that there might be pitfalls.
P.S. CPU is 10700k, no IRQ sharing in legacy mode. All devices are in MSI mode by default except nvidia...
should i put intel management interface on msi mode ??
You can try to update your ME driver to last available version for your chipset. If msi tool show that msi is supported it should be ok. I have Intel MEI in msi mode by default on all my intel systems with latest ME drivers.
@Kolbasambo the driver is updated should i put on high priority too ??
https://prnt.sc/wjro4v thats my current settings and i have 0 problems
No. IME does not need high priority.
I would advise to not toy with priority setting.
@Astyanax Could you tell me, when transferring the video card to "msi" mode, do I need to set the "limit" value? for example 2048?
May I answer instead?
You do not need to touch limit for videocard.
Yes, thank you for your answer. I've already tested both options and was surprised that setting the "limit" value to 2048, I got a decrease in latency (msi mode on). I am on gtx 1066 and am ready to remove the "limit" value if it could have consequences. But so far I have not seen any stability problems.
No consequences. This parameter is relevant only for devices capable to utilize multiple IRQs in MSI mode. (And this parameter allows to limit the number of IRQs. If you see only one IRQ for device - no matter with or without the limit parameter - then such device either is not capable to use multiple IRQs or is not configured to do so.)
I saw only network cards, storage controllers and USB controllers utilizing multiple IRQs (and most of them were server grade HW - read "expansive", and on server Windows mostly).