Guru3D.com Forums

Go Back   Guru3D.com Forums > General > Operating Systems
Operating Systems Is Windows 8.1 giving you a hard time ? Wanna try out Windows 10 ?



Reply
 
Thread Tools Display Modes
Windows: Line-Based vs. Message Signaled-Based Interrupts ...
Old
  (#1)
mbk1969
Ancient Guru
 
mbk1969's Avatar
 
Videocard: GeForce GTX 970
Processor: I7-4930
Mainboard: Asus p9x79
Memory: G Skill RipjawZ, 16GB
Soundcard: Onboard + FiiO E17
PSU: 1000 W
Default Windows: Line-Based vs. Message Signaled-Based Interrupts ... - 05-07-2013, 16:30 | posts: 3,534 | Location: Moscow, Russia

... or another attempt to improve latencies

Little bit of theory:
From "Windows Internals" by Mark Russinovich, David A. Solomon, Alex Ionescu
Line-Based vs. Message Signaled-Based Interrupts
Shared interrupts are often the cause of high interrupt latency and can also cause stability issues. They are typically undesirable and a side effect of the limited number of physical interrupt lines on a computer. For example, in the previous example of the 7-in-1 media card reader, a much better solution is for each device to have its own interrupt and for one driver to manage the different interrupts knowing which device they came from. However, consuming four IRQ lines for a single device quickly leads to IRQ line exhaustion. Additionally, PCI devices are each connected to only one IRQ line anyway, so the media card reader cannot use more than one IRQ in the first place.

Other problems with generating interrupts through an IRQ line is that incorrect management of the IRQ signal can lead to interrupt storms or other kinds of deadlocks on the machine, because the signal is driven “high” or “low” until the ISR acknowledges it. (Furthermore, the interrupt controller must typically receive an EOI signal as well.) If either of these does not happen due to a bug, the system can end up in an interrupt state forever, further interrupts could be masked away, or both. Finally, line-based interrupts provide poor scalability in multiprocessor environments. In many cases, the hardware has the final decision as to which processor will be interrupted out of the possible set that the Plug and Play manager selected for this interrupt, and there is little device drivers can do.

A solution to all these problems is a new interrupt mechanism first introduced in the PCI 2.2 standard called message-signaled interrupts (MSI). Although it remains an optional component of the standard that is seldom found in client machines, an increasing number of servers and workstations implement MSI support, which is fully supported by the all recent versions of Windows. In the MSI model, a device delivers a message to its driver by writing to a specific memory address. This action causes an interrupt, and Windows then calls the ISR with the message content (value) and the address where the message was delivered. A device can also deliver multiple messages (up to 32) to the memory address, delivering different payloads based on the event.

Because communication is based across a memory value, and because the content is delivered with the interrupt, the need for IRQ lines is removed (making the total system limit of MSIs equal to the number of interrupt vectors, not IRQ lines), as is the need for a driver ISR to query the device for data related to the interrupt, decreasing latency. Due to the large number of device interrupts available through this model, this effectively nullifies any benefit of sharing interrupts, decreasing latency further by directly delivering the interrupt data to the concerned ISR.

Finally, MSI-X, an extension to the MSI model, which is introduced in PCI 3.0, adds support for 32-bit messages (instead of 16-bit), a maximum of 2048 different messages (instead of just 32), and more importantly, the ability to use a different address (which can be dynamically determined) for each of the MSI payloads. Using a different address allows the MSI payload to be written to a different physical address range that belongs to a different processor, or a different set of target processors, effectively enabling nonuniform memory access (NUMA)-aware interrupt delivery by sending the interrupt to the processor that initiated the related device request. This improves latency and scalability by monitoring both load and closest NUMA node during interrupt completion.


Now practice.
Checking for PCI devices working in MSI-mode.
Go to Device Manager. Click in menu "View -> Resources by type". Expand "Interrupt request (IRQ)" node of the tree. Scroll down to "(PCI) 0x... (...) device name" device nodes. Devices with positive number for IRQ (like "(PCI) 0x00000011 (17) ...") are in Line-based interrupts-mode. Devices with negative number for IRQ (like "(PCI) 0xFFFFFFFA (-6) ...") are in Message Signaled-based Interrupts-mode.

Trying to switch device to MSI-mode.
You must locate device`s registry key. Invoke device properties dialog. Switch to "Details" tab. Select "Device Instance Path" in "Property" combo-box. Write down "Value" (for example "PCI\VEN_1002&DEV_4397&SUBSYS_1609103C&REV_00\3&11 583659&0&B0"). This is relative registry path under the key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ ".

Go to that device`s registry key ("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum \PCI\VEN_1002&DEV_4397&SUBSYS_1609103C&REV_00\3&11 583659&0&B0") and locate down the subkey "Device Parameters\Interrupt Management". For devices working in MSI-mode there will be subkey "Device Parameters\Interrupt Management\MessageSignaledInterruptProperties" and in that subkey there will be DWORD value "MSISupported" equals to "0x00000001". To switch device from legacy- to MSI-mode just add these subkey and value.

Before adding these key and value (or changing "MSISupported" to "0x00000001" in case subkey and value already exist) you have to perform safety steps like doing backup (creating system restore point at least).

Do tweak one device -> reboot and check (1) if it is displayed in Device Manager as correctly working device; (2) if its IRQ became negative -> if no (1) and no (2) then either remove subkey "MessageSignaledInterruptProperties" (if you added it) or change "MSISupported" to "0x00000000" and reboot.

Theoretically if device driver (and platform = chipset) unable to perform in MSI-mode it should ignore mentioned subkey and value. But who knows...

Afaik most intensive/active IRQ devices are network controller, SATA controller and USB controller.

I have found that network controller is already working in MSI-mode (both at work and at home). I have successfully switched SATA controllers, video- and sound-cards into MSI-mode (both at work and at home). USB 2 controllers ignored "MSISupported" (both at ...), but USB 3 controllers at parents` PC switched to MSI-mode. And Intel MEI device at home rig became incorrect after adding "MSISupported", so I reverted it. And most important is that at work rig (which is old and weak) LatencyMon showed stable level of latencies (at heavy load) which is almost twice lower then before these tweaks, and usual stutters at heavy loads (VisualStudio + VMWare + SmartSVN + Skype + mp3-player) are gone.

Edit: If you have old rig and there are no devices working in MSI-mode, then may be you should not experiment with this tweak.
As this tweak is risky then you probably should not tweak devices which can prevent Windows to boot (by their failure) - SATA controllers, videocards. Especially if they do not share their IRQ with another devices.

Edit: Troubleshooting topic with info from "Windows Internals":
 Click to show spoiler

So if you choose to try and switch PCI device into the message-mode, you better do add "MSISupproted" registry value to one device and reboot. If Windows failed to boot you restart and press F8 and choose boot option "last known good configuration" (which must be the configuration without "MSISupported").

Edit: Improper Propagation of SATA Message Signaled Interrupts on AMD SB950
 Click to show spoiler



Edit: Here is Intel`s paper (thanks to n1hilist):
http://www.intel.co.za/content/dam/w...upts-paper.pdf

Edit: PCI Express overview

Edit: Here is utility for switching MSI-mode
http://www.mediafire.com/download/hr...i/MSI_util.zip

Edit: MSI utility v2.
http://www.mediafire.com/file/2kkkvk...SI_util_v2.zip
Change log:
- New devices grid layout with 4 columns - name, irq, msi, limit, where msi is checkbox column (for MsiSupported value), limit is textbox column (for MessageNumberLimit value) which accepts either empty string or integer value in range of 0..2048 (where 0 has the same meaning as empty string - no limit).

Edit: Here is the script for switching MSI-mode
http://www.mediafire.com/download/rc...mode_utils.zip

Open it in text editor to read the help or execute in PowerShell:
get-help .\MSI_mode_utils.ps1 -full

Remind you that to be able to execute PowerShell scripts you should specify execution policy by:
Set-ExecutionPolicy -ExecutionPolicy Unrestricted
or
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

And I strongly recommend to use script with argument 'reg' first to make the backup reg-file before turning MSI-mode on.

Last edited by mbk1969; 07-31-2017 at 20:23.
   
Reply With Quote
 
Old
  (#2)
thatguy91
Ancient Guru
 
Videocard: XFX RX 480 RS 4 GB
Processor: Ryzen 1700X
Mainboard: MSI X370Gaming Pro Carbon
Memory: DDR3-3733@3333 C15 16 GB
Soundcard: Onboard ALC1220 Nahimic 2
PSU: Enermax Platimax 750W
Default 05-07-2013, 17:19 | posts: 6,448 | Location: Australia

So this has no effect on the IRQ's for the Numeric Data Processor and System CMOS/Real time clock? Both of these use IRQ's.
   
Reply With Quote
Old
  (#3)
mbk1969
Ancient Guru
 
mbk1969's Avatar
 
Videocard: GeForce GTX 970
Processor: I7-4930
Mainboard: Asus p9x79
Memory: G Skill RipjawZ, 16GB
Soundcard: Onboard + FiiO E17
PSU: 1000 W
Default 05-07-2013, 17:38 | posts: 3,534 | Location: Moscow, Russia

Quote:
Originally Posted by thatguy91 View Post
So this has no effect on the IRQ's for the Numeric Data Processor and System CMOS/Real time clock? Both of these use IRQ's.
Are these the PCI devices in your rig? At mine they are ISA ones.
   
Reply With Quote
Old
  (#4)
Nurse13
Newbie
 
Videocard: Gskill 8gig
Processor: Core i5 2500k
Mainboard:
Memory:
Soundcard:
PSU: Corsair
Default 05-14-2013, 04:08 | posts: 6

Great write up, although i found it somewhat difficult to follow and re-read it many times as i was confused to what the main "wanted" goal was and what was to be created.

This worked for my video card but not asus xonar essence stx audio device. I have the latest xonar software with no addons. I have always believed some of my problems (latency, DPC, etc.) has been related to his.. or maybe im just that stupid to think so i dont know. However, i'd thought i'd try. I had initially messed up by not creating the "MessageSignaledInterruptProperties" subkey first before adding "MSIsupported". I went back and re-read the post and seen the mistake which then after a reboot showed that this worked for my video card.

IS there something that prevents the change to MSIsupported mode or a software conflict/reason this wont work as like the USB 2 controllers you tried?
   
Reply With Quote
 
Old
  (#5)
mbk1969
Ancient Guru
 
mbk1969's Avatar
 
Videocard: GeForce GTX 970
Processor: I7-4930
Mainboard: Asus p9x79
Memory: G Skill RipjawZ, 16GB
Soundcard: Onboard + FiiO E17
PSU: 1000 W
Default 05-14-2013, 08:32 | posts: 3,534 | Location: Moscow, Russia

Quote:
Originally Posted by Nurse13 View Post
Great write up, although i found it somewhat difficult to follow and re-read it many times as i was confused to what the main "wanted" goal was and what was to be created.

IS there something that prevents the change to MSIsupported mode or a software conflict/reason this wont work as like the USB 2 controllers you tried?
It`s my clumsy english. Sorry.

As for MSI-mode, device itself has to use (implement) MSI capability, and its driver too.

And what about network card and SATA controller in your rig? I suspect that video card is not the source of mass interrupt bursts...

Last edited by mbk1969; 05-14-2013 at 08:42.
   
Reply With Quote
Old
  (#6)
Nurse13
Newbie
 
Videocard: Gskill 8gig
Processor: Core i5 2500k
Mainboard:
Memory:
Soundcard:
PSU: Corsair
Default 05-14-2013, 20:25 | posts: 6

Quote:
Originally Posted by mbk1969 View Post
It`s my clumsy english. Sorry.

As for MSI-mode, device itself has to use (implement) MSI capability, and its driver too.

And what about network card and SATA controller in your rig? I suspect that video card is not the source of mass interrupt bursts...
Network adapter is Intel 82579V. It is already at a -2 IRQ. On a side note if audio wasn't the problem then either this is or maybe usb. I notice that if i mess with the performance settings or interruption/filter settings my net has extreme amount of drops. Youtube videos stop loading, my games freeze periodically as if i lose my connection and regain it. I have read so much into it and have not found the cause still after 6 months. My net is good, my modem is fine as well (just got firmware update i think yesterday even).

TBH i havent even looked at my SATA controller. Its in Line-based mode.
I will look at it tonight when i get time to mess with things again.
   
Reply With Quote
Old
  (#7)
mbk1969
Ancient Guru
 
mbk1969's Avatar
 
Videocard: GeForce GTX 970
Processor: I7-4930
Mainboard: Asus p9x79
Memory: G Skill RipjawZ, 16GB
Soundcard: Onboard + FiiO E17
PSU: 1000 W
Default 05-14-2013, 23:31 | posts: 3,534 | Location: Moscow, Russia

Quote:
Originally Posted by Nurse13 View Post
Network adapter is Intel 82579V. It is already at a -2 IRQ. On a side note if audio wasn't the problem then either this is or maybe usb. I notice that if i mess with the performance settings or interruption/filter settings my net has extreme amount of drops. Youtube videos stop loading, my games freeze periodically as if i lose my connection and regain it. I have read so much into it and have not found the cause still after 6 months. My net is good, my modem is fine as well (just got firmware update i think yesterday even).
Have you tried:
- tweaking NetworkThrottlingIndex;
- tweaking TCP/IP (there is recommendation to enable TCP RSS when NIC is working in MSI-mode);
- disabling CPU core parking;
- this thread
???
   
Reply With Quote
Old
  (#8)
Nurse13
Newbie
 
Videocard: Gskill 8gig
Processor: Core i5 2500k
Mainboard:
Memory:
Soundcard:
PSU: Corsair
Default 05-15-2013, 01:17 | posts: 6

Quote:
Originally Posted by mbk1969 View Post
Have you tried:
- tweaking NetworkThrottlingIndex;
- tweaking TCP/IP (there is recommendation to enable TCP RSS when NIC is working in MSI-mode);
- disabling CPU core parking;
- this thread
???
I have slowly got into Von's page on performance tweaks. Many i've done before and or found else where so i found myself either repeating or skipping.


I monkeyed with tonight with the IRQ and upon reboot i got a blue screened before windows could log in. I ended up just reinstalling windows because i did not have system restore on that partition as i do with this one; why i dont remember.

And with a new fresh install i can hopefully nail what is causing my problems by introducing 1 thing at a time.

I did core parking and the network throttling i put to 0.

This maybe unheard off but by god i believe its keyboard or mouse related but there is no way to really test.No way mean i dont have replacements or software that i know of to find problems. I have g100 keyboard and g500 mouse.
It seems that my disconnects only happen during me actually using my hardware. Example me spectating in call of duty or bf3 or tf2i have yet to see this same phenomenon happen. My disconnects and by this i mean my game freezes and connection drops and returns are made worse by excessive input from me. So putting the peices together makes me rule out internet issues however it acts just like an internet issue. Hell it reminds of the House episode where they believe its cancer but every test shows that is not cancer. Strange.

I have no idea gentlemen. I am ready to slap this on ebay, all of it, and say the hell with it. I'll build from the ground up when i have time.

In vons thread he goes into device manager to disable stuff, so i did to. Looking under device manager i see x4 HID complaint keyboard and same for mouse. I see "virtual keyboard" and "virtual mouse". Which makes me wonder, but that about it.

I dont know. I would seriously pay someone to sit at my computer and do all that is necessary to find out why i can't use it.

Last edited by Nurse13; 05-15-2013 at 01:20.
   
Reply With Quote
Old
  (#9)
mbk1969
Ancient Guru
 
mbk1969's Avatar
 
Videocard: GeForce GTX 970
Processor: I7-4930
Mainboard: Asus p9x79
Memory: G Skill RipjawZ, 16GB
Soundcard: Onboard + FiiO E17
PSU: 1000 W
Default 05-15-2013, 07:48 | posts: 3,534 | Location: Moscow, Russia

Definitely you need network troubleshooting guru. May be from your internet provider.
   
Reply With Quote
Old
  (#10)
Nurse13
Newbie
 
Videocard: Gskill 8gig
Processor: Core i5 2500k
Mainboard:
Memory:
Soundcard:
PSU: Corsair
Default 05-15-2013, 16:52 | posts: 6

Quote:
Originally Posted by mbk1969 View Post
Definitely you need network troubleshooting guru. May be from your internet provider.
Yea but im not sure if they would find anything. I'm at the point now i dont care anymore-i've given up.

To make my day even better my keyboard decided not to work today in its current usb slot, so i had to change usb slots t type this messsage. Why?...
   
Reply With Quote
Old
  (#11)
mbk1969
Ancient Guru
 
mbk1969's Avatar
 
Videocard: GeForce GTX 970
Processor: I7-4930
Mainboard: Asus p9x79
Memory: G Skill RipjawZ, 16GB
Soundcard: Onboard + FiiO E17
PSU: 1000 W
Default 05-15-2013, 17:21 | posts: 3,534 | Location: Moscow, Russia

Quote:
Originally Posted by Nurse13 View Post
Yea but im not sure if they would find anything. I'm at the point now i dont care anymore-i've given up.

To make my day even better my keyboard decided not to work today in its current usb slot, so i had to change usb slots t type this messsage. Why?...
Generic recommendation for not working USB ports is to shutdown PC, remove power cable for 5-10 minutes. Or try powered USB hub.

As for network, imo troubles are 20% of internal hardware-software and 80% of external network protocol ones. Especially when xDSL modem involved.
Btw, you can try discrete NIC, if you suspect your (most probably integrated) one is culprit.
   
Reply With Quote
Old
  (#12)
Nurse13
Newbie
 
Videocard: Gskill 8gig
Processor: Core i5 2500k
Mainboard:
Memory:
Soundcard:
PSU: Corsair
Default 05-16-2013, 06:33 | posts: 6

Quote:
Originally Posted by mbk1969 View Post
Generic recommendation for not working USB ports is to shutdown PC, remove power cable for 5-10 minutes. Or try powered USB hub.

As for network, imo troubles are 20% of internal hardware-software and 80% of external network protocol ones. Especially when xDSL modem involved.
Btw, you can try discrete NIC, if you suspect your (most probably integrated) one is culprit.
I believe that i might have fixed the issue, fingers are crossed. If it isn't then i truly will just take a 12 gauge and light this whole thing up.

Two issues: 1) turned modem into a bridge via NAPT mode disabled; known issue with my modem (surfboard from motorola).
2) Keep getting usb3 power surge message. Switched 1 input to FP usb and the other to the back. So far working.

The strangest thing happened to me as well. I went through the bios to see if maybe it was power related, turned everything to stock voltages as i had been using part of an OC profile but had de-clocked my cpu long ago just never returned the voltages. Log into windows to find that my mouse is super laggy, my cpu usage is 80 percent, my ram is almost maxed at 8gigs. Logitech gaming software was using over 2 gigs of ram... all hell broke loose. I went back and re did an overlock on my system said why the hell not after i couldn't fix the damn thing lets fry it.
Well it works now.

Uhm sorry i have derailed this thread. I believe i noticed some* maybe some improvement with these tweaks. I will re-do them on my fresh install of windows.But the SATA controller is off limits.
Thanks
   
Reply With Quote
Old
  (#13)
mbk1969
Ancient Guru
 
mbk1969's Avatar
 
Videocard: GeForce GTX 970
Processor: I7-4930
Mainboard: Asus p9x79
Memory: G Skill RipjawZ, 16GB
Soundcard: Onboard + FiiO E17
PSU: 1000 W
Default 05-16-2013, 07:59 | posts: 3,534 | Location: Moscow, Russia

Yeah, that was USB troubleshoot # 1 - use back panel ports instead front panel ones.
   
Reply With Quote
Old
  (#14)
Cyberdyne
Ancient Guru
 
Cyberdyne's Avatar
 
Videocard: GTX1080 Arctic Hybrid III
Processor: i7 4770K @ 4.4GHz
Mainboard: MSI Z87-G45 Gaming
Memory: 4x8GB @ 2GHz
Soundcard: HyperX Cloud + FiiO E6
PSU: EVGA SuperNOVA 1000 P2
Default 05-23-2013, 13:25 | posts: 2,927 | Location: USA, Pennsylvania

http://i.imgur.com/khBUUqp.png
Am I doing this correctly? Because if I am, I can't even get this to work on my Audigy. Ah well, no harm done.
   
Reply With Quote
Old
  (#15)
mbk1969
Ancient Guru
 
mbk1969's Avatar
 
Videocard: GeForce GTX 970
Processor: I7-4930
Mainboard: Asus p9x79
Memory: G Skill RipjawZ, 16GB
Soundcard: Onboard + FiiO E17
PSU: 1000 W
Default 05-23-2013, 15:10 | posts: 3,534 | Location: Moscow, Russia

Yeah, seems correctly. Audio-card is not the source interrupts bursts, I assume. SATA controllers, USB-controllers, NICs are...
   
Reply With Quote
Old
  (#16)
pipes
Master Guru
 
pipes's Avatar
 
Videocard: 2X R9 290x
Processor: Core i7 5930K
Mainboard: EVGA X99 classified
Memory: DDR4 16 GB 2400 MHZ
Soundcard: Hdmi P2770HD
PSU: 1200 WATT
Default 05-23-2013, 20:16 | posts: 156 | Location: Italy

Quote:
Originally Posted by mbk1969 View Post
... or another attempt to improve latencies

Little bit of theory:
From "Windows Internals" by Mark Russinovich, David A. Solomon, Alex Ionescu
Line-Based vs. Message Signaled-Based Interrupts
Shared interrupts are often the cause of high interrupt latency and can also cause stability issues. They are typically undesirable and a side effect of the limited number of physical interrupt lines on a computer. For example, in the previous example of the 7-in-1 media card reader, a much better solution is for each device to have its own interrupt and for one driver to manage the different interrupts knowing which device they came from. However, consuming four IRQ lines for a single device quickly leads to IRQ line exhaustion. Additionally, PCI devices are each connected to only one IRQ line anyway, so the media card reader cannot use more than one IRQ in the first place.

Other problems with generating interrupts through an IRQ line is that incorrect management of the IRQ signal can lead to interrupt storms or other kinds of deadlocks on the machine, because the signal is driven “high” or “low” until the ISR acknowledges it. (Furthermore, the interrupt controller must typically receive an EOI signal as well.) If either of these does not happen due to a bug, the system can end up in an interrupt state forever, further interrupts could be masked away, or both. Finally, line-based interrupts provide poor scalability in multiprocessor environments. In many cases, the hardware has the final decision as to which processor will be interrupted out of the possible set that the Plug and Play manager selected for this interrupt, and there is little device drivers can do.

A solution to all these problems is a new interrupt mechanism first introduced in the PCI 2.2 standard called message-signaled interrupts (MSI). Although it remains an optional component of the standard that is seldom found in client machines, an increasing number of servers and workstations implement MSI support, which is fully supported by the all recent versions of Windows. In the MSI model, a device delivers a message to its driver by writing to a specific memory address. This action causes an interrupt, and Windows then calls the ISR with the message content (value) and the address where the message was delivered. A device can also deliver multiple messages (up to 32) to the memory address, delivering different payloads based on the event.

Because communication is based across a memory value, and because the content is delivered with the interrupt, the need for IRQ lines is removed (making the total system limit of MSIs equal to the number of interrupt vectors, not IRQ lines), as is the need for a driver ISR to query the device for data related to the interrupt, decreasing latency. Due to the large number of device interrupts available through this model, this effectively nullifies any benefit of sharing interrupts, decreasing latency further by directly delivering the interrupt data to the concerned ISR.

Finally, MSI-X, an extension to the MSI model, which is introduced in PCI 3.0, adds support for 32-bit messages (instead of 16-bit), a maximum of 2048 different messages (instead of just 32), and more importantly, the ability to use a different address (which can be dynamically determined) for each of the MSI payloads. Using a different address allows the MSI payload to be written to a different physical address range that belongs to a different processor, or a different set of target processors, effectively enabling nonuniform memory access (NUMA)-aware interrupt delivery by sending the interrupt to the processor that initiated the related device request. This improves latency and scalability by monitoring both load and closest NUMA node during interrupt completion.


Now practice.
Checking for PCI devices working in MSI-mode.
Go to Device Manager. Click in menu "View -> Resources by type". Expand "Interrupt request (IRQ)" node of the tree. Scroll down to "(PCI) 0x... (...) device name" device nodes. Devices with positive number for IRQ (like "(PCI) 0x00000011 (17) ...") are in Line-based interrupts-mode. Devices with negative number for IRQ (like "(PCI) 0xFFFFFFFA (-6) ...") are in Message Signaled-based Interrupts-mode.

Trying to switch device to MSI-mode.
You must locate device`s registry key. Invoke device properties dialog. Switch to "Details" tab. Select "Device Instance Path" in "Property" combo-box. Write down "Value" (for example "PCI\VEN_1002&DEV_4397&SUBSYS_1609103C&REV_00\3&11 583659&0&B0"). This is relative registry path under the key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ ".

Go to that device`s registry key ("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum \PCI\VEN_1002&DEV_4397&SUBSYS_1609103C&REV_00\3&11 583659&0&B0") and locate down the subkey "Device Parameters\Interrupt Management". For devices working in MSI-mode there will be subkey "Device Parameters\Interrupt Management\MessageSignaledInterruptProperties" and in that subkey there will be DWORD value "MSISupported" equals to "0x00000001". To switch device from legacy- to MSI-mode just add these subkey and value.

Before adding these key and value (or changing "MSISupported" to "0x00000001" in case subkey and value already exist) you have to perform safety steps like doing backup (creating system restore point at least).

Do tweak one device -> reboot and check (1) if it is displayed in Device Manager as correctly working device; (2) if its IRQ became negative -> if no (1) and no (2) then either remove subkey "MessageSignaledInterruptProperties" (if you added it) or change "MSISupported" to "0x00000000" and reboot.

Theoretically if device driver (and platform = chipset) unable to perform in MSI-mode it should ignore mentioned subkey and value. But who knows...

Afaik most intensive/active IRQ devices are network controller, SATA controller and USB controller.

I have found that network controller is already working in MSI-mode (both at work and at home). I have successfully switched SATA controllers, video- and sound-cards into MSI-mode (both at work and at home). USB 2 controllers ignored "MSISupported" (both at ...), but USB 3 controllers at parents` PC switched to MSI-mode. And Intel MEI device at home rig became incorrect after adding "MSISupported", so I reverted it. And most important is that at work rig (which is old and weak) LatencyMon showed stable level of latencies (at heavy load) which is almost twice lower then before these tweaks, and usual stutters at heavy loads (VisualStudio + VMWare + SmartSVN + Skype + mp3-player) are gone.

Edit: If you have old rig and there are no devices working in MSI-mode, then may be you should not experiment with this tweak.
As this tweak is risky then you probably should not tweak devices which can prevent Windows to boot (by their failure) - SATA controllers, videocards. Especially if they do not share their IRQ with another devices.

Edit2: Little editing to reduce ambiguities.
Hi man, I have do all you say in this guide, only 3:
Intel(R) 7500/5520/5500/X58 I/O Hub PCI Express Root Port 1 - 3408
Intel(R) 7500/5520/5500/X58 I/O Hub PCI Express Root Port 7 - 340E - 340e
Intel(R) 7500/5520/5500/X58 I/O Hub PCI Express Root Port 3 - 340A - 340a


I can't make in msi-mode, Why You know?
   
Reply With Quote
Old
  (#17)
Cyberdyne
Ancient Guru
 
Cyberdyne's Avatar
 
Videocard: GTX1080 Arctic Hybrid III
Processor: i7 4770K @ 4.4GHz
Mainboard: MSI Z87-G45 Gaming
Memory: 4x8GB @ 2GHz
Soundcard: HyperX Cloud + FiiO E6
PSU: EVGA SuperNOVA 1000 P2
Default 05-23-2013, 23:15 | posts: 2,927 | Location: USA, Pennsylvania

Probably because of this,
Quote:
Theoretically if device driver (and platform = chipset) unable to perform in MSI-mode it should ignore mentioned subkey and value. But who knows...
   
Reply With Quote
Old
  (#18)
mbk1969
Ancient Guru
 
mbk1969's Avatar
 
Videocard: GeForce GTX 970
Processor: I7-4930
Mainboard: Asus p9x79
Memory: G Skill RipjawZ, 16GB
Soundcard: Onboard + FiiO E17
PSU: 1000 W
Default 05-23-2013, 23:26 | posts: 3,534 | Location: Moscow, Russia

Quote:
Originally Posted by pipes View Post
Hi man, I have do all you say in this guide, only 3:
Intel(R) 7500/5520/5500/X58 I/O Hub PCI Express Root Port 1 - 3408
Intel(R) 7500/5520/5500/X58 I/O Hub PCI Express Root Port 7 - 340E - 340e
Intel(R) 7500/5520/5500/X58 I/O Hub PCI Express Root Port 3 - 340A - 340a


I can't make in msi-mode, Why You know?
Only those 3 were switched into MSI-mode?
You see, for MSI-mode must participate: chipset, device and device drivers.
   
Reply With Quote
Old
  (#19)
pipes
Master Guru
 
pipes's Avatar
 
Videocard: 2X R9 290x
Processor: Core i7 5930K
Mainboard: EVGA X99 classified
Memory: DDR4 16 GB 2400 MHZ
Soundcard: Hdmi P2770HD
PSU: 1200 WATT
Default 05-23-2013, 23:32 | posts: 156 | Location: Italy

Quote:
Originally Posted by Cyberdyne View Post
Probably because of this,
In this photo you can see the hardware is not in msi-mode


[IMG=http://img404.imageshack.us/img404/9222/catturaifv.jpg][/IMG]
   
Reply With Quote
Old
  (#20)
pipes
Master Guru
 
pipes's Avatar
 
Videocard: 2X R9 290x
Processor: Core i7 5930K
Mainboard: EVGA X99 classified
Memory: DDR4 16 GB 2400 MHZ
Soundcard: Hdmi P2770HD
PSU: 1200 WATT
Default 05-23-2013, 23:33 | posts: 156 | Location: Italy

Quote:
Originally Posted by mbk1969 View Post
Only those 3 were switched into MSI-mode?
You see, for MSI-mode must participate: chipset, device and device drivers.
is not in msi-mode and I cant change into msi-mode
   
Reply With Quote
Old
  (#21)
Cyberdyne
Ancient Guru
 
Cyberdyne's Avatar
 
Videocard: GTX1080 Arctic Hybrid III
Processor: i7 4770K @ 4.4GHz
Mainboard: MSI Z87-G45 Gaming
Memory: 4x8GB @ 2GHz
Soundcard: HyperX Cloud + FiiO E6
PSU: EVGA SuperNOVA 1000 P2
Default 05-24-2013, 00:51 | posts: 2,927 | Location: USA, Pennsylvania

Lol, you have it the other way around. Read the guide, negative numbers mean it's running in MSI mode. mbk is ironically right when he misunderstood you, those are the only devices in your screen-cap that are in MSI mode.
   
Reply With Quote
Old
  (#22)
Cyberdyne
Ancient Guru
 
Cyberdyne's Avatar
 
Videocard: GTX1080 Arctic Hybrid III
Processor: i7 4770K @ 4.4GHz
Mainboard: MSI Z87-G45 Gaming
Memory: 4x8GB @ 2GHz
Soundcard: HyperX Cloud + FiiO E6
PSU: EVGA SuperNOVA 1000 P2
Default 05-24-2013, 01:07 | posts: 2,927 | Location: USA, Pennsylvania

Also, just tried applying MSI mode to my USB and SATA controllers. I blue screened. Had to learn how to reg load the registry from the recovery console and fix it from there (which was interesting).
mbk, what did you do when you were doing trial-and-error? Did you really use windows recovery each time? Got to be a better way... because I'm pretty sure I can apply MSI mode to some of the controllers.
   
Reply With Quote
Old
  (#23)
mbk1969
Ancient Guru
 
mbk1969's Avatar
 
Videocard: GeForce GTX 970
Processor: I7-4930
Mainboard: Asus p9x79
Memory: G Skill RipjawZ, 16GB
Soundcard: Onboard + FiiO E17
PSU: 1000 W
Default 05-24-2013, 01:13 | posts: 3,534 | Location: Moscow, Russia

Quote:
Originally Posted by pipes View Post
is not in msi-mode and I cant change into msi-mode
I`ve looked at the picture and can say, that at least your video-cards and SATA controller do not share IRQ with another devices. But your Marvell Yukon NIC does share IRQ (18) with USB controllers 3A44 and 3A3C. In case these particular USB controllers have some USB devices attached to them you better connect USB devices to another ports to try to avoid those USB controllers usage. If no devices connected to them USB controllers you can disable them in Device Manager to provide Marvell NIC with exclusive IRQ.

And line-mode of devices is no reason to bang the wall. It is normal mode but merely less optimal then message-mode.

Last edited by mbk1969; 05-24-2013 at 01:19.
   
Reply With Quote
Old
  (#24)
mbk1969
Ancient Guru
 
mbk1969's Avatar
 
Videocard: GeForce GTX 970
Processor: I7-4930
Mainboard: Asus p9x79
Memory: G Skill RipjawZ, 16GB
Soundcard: Onboard + FiiO E17
PSU: 1000 W
Default 05-24-2013, 01:18 | posts: 3,534 | Location: Moscow, Russia

Quote:
Originally Posted by Cyberdyne View Post
Also, just tried applying MSI mode to my USB and SATA controllers. I blue screened. Had to learn how to reg load the registry from the recovery console and fix it from there (which was interesting).
mbk, what did you do when you were doing trial-and-error? Did you really use windows recovery each time? Got to be a better way... because I'm pretty sure I can apply MSI mode to some of the controllers.
Well, beeing a programmer in the company whose main product line is software for hard disk management, backup and restore, I just use bootable DVD with WinPE and our software to backup internal HDD to the external HDD. Imo this is the best protection against any possible damage.

But I was sure that if you fail to boot you always have boot option "last known good configuration"....

And once again - better try one device per attempt (attempt per device?).

Last edited by mbk1969; 05-24-2013 at 01:29.
   
Reply With Quote
Old
  (#25)
Cyberdyne
Ancient Guru
 
Cyberdyne's Avatar
 
Videocard: GTX1080 Arctic Hybrid III
Processor: i7 4770K @ 4.4GHz
Mainboard: MSI Z87-G45 Gaming
Memory: 4x8GB @ 2GHz
Soundcard: HyperX Cloud + FiiO E6
PSU: EVGA SuperNOVA 1000 P2
Default 05-24-2013, 01:27 | posts: 2,927 | Location: USA, Pennsylvania

Isn't WinPE a lot like the recovery console?
Problem is, I think the CurrentControlSet key is volatile, because when I used my method it did not exist. I had to change (aka, delete) the MessageSignaledInterruptProperties keys from the ControlSet001, ControlSet002, and ControlSet003 keys instead.

Doesn't "Last Known Good Configuration" just take you back to your most recent windows recovery backup that booted? I mean sure that would work, but even that is more annoying than using the recovery console.

Yeah, when I build up the nerve I'll give it another go another time.

Last edited by Cyberdyne; 05-24-2013 at 01:32.
   
Reply With Quote
Reply

Tags
dpc, irq, latencies, windows

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump



Powered by vBulletin®
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
vBulletin Skin developed by: vBStyles.com
Copyright (c) 2017, All Rights Reserved. The Guru of 3D, the Hardware Guru, and 3D Guru are trademarks owned by Hilbert Hagedoorn.