Windows: Line-Based vs. Message Signaled-Based Interrupts ...

Gotcha, i was just thinking about whether to give it another try but nah

 

Also wanted you to know that i heard Intel NIC's past 19.1 or something i believe cause issues

https://forums.intel.com/s/question...-latency-spike-once-a-few-secs?language=en_US

 

There always will be combinations of hardware and software with failure behaviour. But Intel`s NICs will do just fine with older drivers, while Killer`s NICs will not do fine with any drivers.

Newest versions of drivers for NICs are not needed for home users, because usually only server ones (and maybe office ones too) do work in heavy loads.

 

Spoiler

(screenshot related) HW config is: Ryzen 1700, ASUS X370-F Strix Gaming, Powercolor Vega64, Samsung 960 EVO M.2 (nvme)
The line I selected in the screenshot is the Powercolor Vega64 sound device, 2 lines below the Realtek onboard sound chip. This config was standard by the drivers I installed (always current ones except Vega64: 18.12.2 instead of .3).

Probably others who used the tool could show their config, too? So over time there would grow a collection of devices which are proven to work in MSI mode, to minimize the necessary "trial and error" for others.

 

I would recommend you place everything in msix. I've tried the high definition audio ones and they all work. One is for my creative sound blaster recon 3di and though it wont say on msix I'd recommend it though. It even works too. I've places both high definition audio controllers in msi/msix.

Nvme... 2048 msix you can get for those... so yes. If you read win-raid and look for this

https://www.win-raid.com/t871f50-Gu...rt-for-all-Systems-with-an-AMI-UEFI-BIOS.html

 

Can i add wdf01000.sys driver to msi mode ??

 

Since this is not a PCI device driver, you can't.

PS This driver is part of Kernel Mode Driver Framework - a way for driver developers to unify and simplify the development offered by Microsoft.

 

Hi MBK1969, one extra question, i was messing with drivers like i said couple pages before i believe if i left my comments there or not. I hope so, but i was wondering...

1. I installed a different chipset driver and i got (2x) PCI to PCI bridge drivers in system device's in device manager when i did this. I was hoping to get clarification as to why that happens? Recently i downgrade back to my oem chipset drivers provided by mobo manufacturer's site and i got back

• Intel(R) 8 Series/C220 Series PCI Express Root Port #1 - 8C10
• Intel(R) 8 Series/C220 Series PCI Express Root Port #4 - 8C16

and i noticed less input latency with that which is good!




2. Also, I installed i THINK it was USB 3.0 drivers from Intel win7 drivers that was modded by Fernando at Win-Raid.com and it caused my issues with input latency. I got PCI Root in device manager rather than PCI Express Root Complex driver in system device's. I uninstalled it using device manager and it went away and PC installed the proper driver. (PCI Express Root Complex) Driver.
Just curious as to how weird that happens to be...
This also caused input latency because it was using an older standard of PCI rather than PCIE driver. Sometimes you would think Microsoft would name these PCI " " so forth because its still an extension of PCI for PCI Express so i doubt it didn't matter until i tried testing theories. lol



3. Do you know how i can get back my PCI Express Root Port's back? Demonstration or example from: X7007 1st post on page 35.
I lost these after i was messing with my device manager settings and stuff and no matter uninstalling or reinstalling Intel Management Engine Interface driver or Intel chipset drivers, nothing comes up in MSI-X utility v2. I think i might need to reformat to get these back, Unfortunately >_>.

Luckily i have 125mbps down and up symmetrical speeds and can download back my stuff quickly, once i acquire enough $ to purchase a Samsung 970 Pro 512GB, i'd need to retest these settings. Right now, i'm just going along my day configuring pc for gaming more and continuing to try new stuff out/configurations/settings.

https://forums.guru3d.com/threads/w...sage-signaled-based-interrupts.378044/page-35

 

@limeay
Chipset drivers are not actual drivers. They are just inf-files with (detailed) names for chipset devices. So no matter how device is called before and after installation of chipset drivers.
Hence it can`t change input latency. You got changed latency by something else.

My rig has all 3 devices: "PCI Bus", "PCI Express Root Complex", "PCI-to-PCI Bridge" - with one and the same driver "pci.sys".

 

Oh okay, i guess it might be a placebo. I believe i felt it but its very minor at that if "I FELT THAT", i believe you though.inf file do literally nothing except a nice name. I should've known. I looked it up week before but i just thought i'd put out what i noticed. >_> lol Except it's not real Yea, i have couple system devices with different names with locations of pci.sys

 

I was refreshing interrupts stuff in my head (by reading "Windows Internals"), and there is interrupt affinity and priority chapter there:

Interrupt Affinity and Priority
On systems that both support ACPI and contain an APIC, Windows enables driver developers and administrators to somewhat control the processor affinity (selecting the processor or group of processors that receives the interrupt) and affinity policy (selecting how processors will be chosen and which processors in a group will be chosen). Furthermore, it enables a primitive mechanism of interrupt prioritization based on IRQL selection. Affinity policy is defined according to Table 3-1, and it’s configurable through a registry value called InterruptPolicyValue in the Interrupt Management\Affinity Policy key under the device’s instance key in the registry.
Because of this, it does not require any code to configure - an administrator can add this value to a given driver’s key to influence its behavior. Microsoft provides such a tool, called the Interrupt Affinity policy Tool.

Other than setting this affinity policy, another registry value can also be used to set the interrupt’s priority, based on the values in Table 3-2.
​

(Enumeration is special type of integer values with names. First named value in enumeration has value "0", second named value - "1", and so forth.)
Table 3-1 describes values of this IRQ_DEVICE_POLICY enumeration from WinAPI.
Table 3-2 describes values of this IRQ_PRIORITY enumeration from WinAPI.

I have read that part many times, but since authors of "Windows Internals" failed to name the registry value for interrupt priority I failed to utilize that feature. But today I have an "eureka!" moment.
1. I was reading that page about interrupt affinity and noticed the registry value "DevicePolicy" which differs from "InterruptPolicyValue" mentioned in the book.
2. I browsed through many "Affinity Policy" registry keys of PCI devices in my rig and found many instances of this "DevicePolicy".
3. And in one place I found registry value with the name we can relate with interrupt priority from table 3-2 - "DevicePriority" with value "3" (IrqPriorityHigh)

So I went to MSI Utility project and here we go - updated version of utility with newly added column "interrupt priority". You can set that priority and reboot.
http://www.mediafire.com/file/2kkkvko7e75opce/MSI_util_v2.zip

This feature of MSI utility is still a speculation, a guesswork, so do test yourself.

PS I created dedicated thread about interrupts in Windows
https://forums.guru3d.com/threads/a-bit-detailed-info-about-interrupts-in-windows.424677/

PPS Another note: this priority tweak is strictly about ISR part of interrupt from device. ISR routine dispatches the DPC (actual work on interrupt) and DPCs are always executed with the same (lower) priority (and are always pre-empted by interrupts from devices).

 

Holy crayola lol. That's good. If you ever come up with anymore tweaks to latency I'd like to know. I was wondering if you have time, THOUGH this has nothing to do with it... can you send me a latencymon pic with default settings in latencymon on how much latency nvidia drivers should be. I've listed a post on this in earlier msix posts about how I was having issues with their crapola driver being 200.-1400. Just leave it running for awhile and play games or load test it with something for 15-30mins and record highest dpc or so.

Going to test this feature for msi utilv2 though.

Also windows ultimate performance plan, do you know how they planned to lower latency from high perf? I've already done this tweak but barely see difference in settings. I've never use anything but ultimate perf since it first came out so I have no clue to visual latency wise is it any different. Going to review older win10 version through wikipedia to see where I can find info on this.

I shall read the post on interrupt when I get time, so many things to do so little time

 

Also a question remains, should i only leave one of the device's in MSI-X utilv2 interrupt policy to high for whichever of my choosing or can i leave em all on high? That's a weird one and alot of testing probably needs to be done.

EDIT:
Okay i noticed differences, mouse seems to be a bit more responsive. Visually it feels a bit better too. Hard thing to understand is should i leave everything at HIGH or just leave certain devices. Not everything requires it but for me, i require the utmost lowest latency possible
If i leave so many device's on HIGH priority, it might not be as low latency as it could be from what i believe if i'm using some of these devices and don't require it and its just needlessly placing overhead i guess?

What could be NEGATIVE to having alot of device's set to high interrupt policy? Some type of bogdown? I believe there should always be a con to things but depends on if it doesn't bother you or matter very little or at all.
For ex: maybe CPU Utilization jumps up alot more?

 

@limeay

I don`t think you should set high priority for all devices. Better try one-by-one with a lot of testing. Most easy devices to test are videocard and SATA controller because there are plenty of tests for them. But SATA controller should already be on "High" priority.

My policy is - leave devices with no faulty behaviour on default "Undefined" priority, and if you have faulty device then try to raise interrupt priority.

Why you should not raise interrupt priority for all devices: while processor (core) services interrupt it can`t service another interrupts with the same or lower priorities; if many devices have elevated priorities of interrupts they can stall all available processors (cores) and as a result the servicing of some interrupts (either from devices or software ones like DPCs) could be delayed for too long.

PS Also note that this registry value is not an order for Windows kernel, it is a hint. So kernel can ignore it.

 

I take it yourSATA was set to high?
I ran a search in mine and nothing came up for all the settings.
IrqPriorityHigh, IrqPriorityNormal, IrqPriorityLow.

 

Got it, it rationally makes sense. I'll try to disable some devices. Does Intel MEI require priority by any chance? I feel like NIC requires it because of transmission of data, video card and sata controller and XHCI for mouse input.

 

Yea, none of my devices were set. It was on the default or w\e it says on the program lol.

 

A search in registry? In registry you should search for "DevicePriority" value. It is of DWORD type and of values from 0 to 3.

PS And yes - on my rig SATA controller is configured with DevicePriority = 3.

 

I have to correct my answer:
if many devices have elevated priorities of interrupts they can stall all available processors (cores) and as a result the servicing of interrupts from other devices could be delayed for too long
- because DPCs are always stalled by any interrupts from devices due to lower priority of DPCs.

 

yeh, I get a lot of them connected to driverdatabase/driverpackages

there all 3 values