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

Oh yes thank you. I'm actually a long time lurker there and have tried his modified drivers. Just wanted to try the stock drivers to see if they are up to par and so far it's been fine.

 

Chipset drivers are not actual drivers. They are just inf-files with proper names and may be more detailed. Windows comes with generic SATA drivers (of its own and of SATA controller OEMs).

 

I'm using the ASUS Maximus VII Ranger, which one of these Fernando drivers do I download and what benefit is there to using them over stock?

 

You are asking a wrong guru - Fernando is guru in AHCI/RAID things. You can test SATA performance with your current drivers, then download bundle(s) from Fernando`s forum and test SATA performance on them - to decide which one gives you better performance. This is only way to be sure for 100% - to test on your rig.

PS As I take it, not so much of a difference for AHCI mode, but for RAID mode there can be significant difference between drivers.

 

For Z97, use v14.8.18.1066. They do not require modding. Anything later (v15, etc.) requires modding and might have lower performance and/or compatiblity issues.

 

Latencymon have issues with 1809 for any of you guys? It starts and does its thing normally but if I press stop and then start it again, it gives an access denied error and crashes.

 

http://www.resplendence.com/support

 

Hi MBK1969, i have questions on if you'd understand how MSI-X truly works regarding drivers.
I have a G1 Sniper M5 socket 1150 Z87 mATX board for my rig and the killer e2200 is a rebranded Qualcomm Atheros AR8161 NDIS 6.30, i used new drivers from https://www.ath-drivers.eu/ and got 2.1.0.27 for my AR8161 and MSI-X works i get negative IRQ values when enabled with MSI utility after reboot but for some reason my Asus G46VW does not accept MSI-X as the normal interrupts for my Qualcomm Atheros AR8151 NDIS 6.30, uses 2.1.0.27 too from the 3rd party site. I've also tried oem drivers from ASUS which is 2.1.0.7 which is odd thats dated back to 2013... while the 2.1.0.27 is dated oct 2017. So bottom line is my notebook will not accept MSI-X after reboot and still at IRQ value of 19 after pressing [X] box.

Also I got a message from Killer Networking and they told me they were misinformed that their killer E2*00 is MSI-X without having it enabled, they sent me a email, i then went to nvidia forums because at the time i was having problems with system instability and later found out my psu was the problem. Sora told me to update using Qualcomm's drivers rather than Killer's because of the problems i listed below, unfortunately i can't test the below complaint because my internet connection is not that fast, only 3mbps down and seems to be no problems even when using killer 9.0.0.48 drivers and enabling to MSI-X, it still shows it can have a negative IRQ value but that is a negative below though.
I only went with Qualcomm's drivers because Sora says MSi-X works well with these drivers apparently but killers doesn't >_> Killer states that their drivers are practically the drivers from Qualcomm based drivers and just modified or something.
https://forums.geforce.com/default/...cy-due-to-nvidia-drivers-ndis-sys-usb-2-0-/3/

"Unfortunately, I was misinformed.

After doing some in-depth investigation and testing last night, I have found that our Ethernet devices do not use MSI mode. Furthermore, when I changed the registry to force it, it did not handle it well. The connection was somewhat reliable, but very slowed, bringing my normally smooth 230+ Mbps down to a choppy 90 Mbps. I tested quite a few configurations and was unable to find any parameters where having MSI enabled did not dramatically affect the adapter's performance.

In my testing, it seems the best performance from our adapters comes from leaving them in the default line-based mode.

You Wrote:
Sorry, its been one month but, its weird that using "MSI Util v2" does not show it already listed using MSI-X... Just curious. Thanks
On Monday, September 10, 2018, 11:43:03 AM PDT, Killer Support wrote:"

Question: how does MSI-X work, is it coded into the .inf file or something and you can modify it or is it a hardware problem? I'm trying to figure out how i can enable it on something that cannot be enabled.
Like i said on top, my AR8161 can have a negative IRQ which is a mATX board and my AR8151 for my notebook cannot? it doesn't seem to be that different over all. Could you explain? THANKS!

Check this link and press 64 bit and see the code. it says messagedsignaledinterrupts in the lines at mid way and i'm trying to figure out why its a value of 10? its the same for my ar8161.
https://www.ath-drivers.eu/download-driver-for-Atheros-chipset-with-id-87-and-Windows10-64bit.html

 

Two extra quotes from Killer:

"Unfortunately, the current driver is not compatible with MSI, and is not likely to be re-coded. The base driver that we use is the Qualcomm Atheros driver, just with our hardware ID, and a bit of extra coding in the package for the Killer Control Center. The base driver is provided to us by Qualcomm.

I do not suggest force installing the driver in that link as it was not intended for your adapter, and the actual date on it is very old and not intended for use with Windows 10. Even if that driver does work, you can see here -https://www.catalog.update.microsoft.com/Search.aspx?q=Atheros+AR8161+PCI-E - that any 2.x driver is extremely dated. Using this driver will very likely cause system instability.

If there is a Qualcomm driver that matches the drivers they provide us, they will use the same driver version numbering, and the current version is 9.0.0.48. As far as I am aware, there is no Qualcomm-labeled driver that will work correctly with the E2200, E2400, and E2500 in Windows 10.

You Wrote:
Sorry Anthony Davis,
Was wondering is it possible to get the engineers at Killer networking to maybe change the drivers to MSI-X? Like recoding it maybe, or is it just best left alone. I had a reply from Sora in geforce.com
Sora

https://www.station-drivers.com/ind...tory&Itemid=353&func=fileinfo&id=3398&lang=en"

______________________________________________________________________________________________________________________

"The Killer Control Center was, at one time, causing some additional DPC latency. This has been corrected. Our drivers have also been optimized to be as low latency as possible.

Keep in mind that, because your networking adapter is responsible for sending and receiving data to and from remote computers, NDIS.SYS will always be at or near the top of your DPC latency results in Latencymon in drivers under "Highest Execution Time." This is how it should be. The more data you transfer at once, the higher the "Highest Execution Time" will be, as that simply indicates that data was sent or received. Other devices should have a lower execution time because they only deal with local devices.

The current Killer Control Center installer should install driver 9.0.0.48. Decreased latency was not mentioned in the notes from our driver developers, so you are unlikely to see any difference.

There is no reason to use the .INF package unless you wish to uninstall the Killer Control Center and manually install the drivers in Device Manager.

You Wrote:
An email has been received from the Killer Networks website. The content follows:

Your Name:
Email Address:

Department: General

Subject: Driver questions

MESSAGE:
Hi i have questions about the INF style drivers and the software type "Killer Software Package - for Windows 10 1803+" & Killer Drivers Installation - 64bit.

The software specifically describes info on DPC problems back then and how they solved it now correct in the software?

The Killer driver installation drivers and INF drivers however i have no clue on. Is there any different between using a 9.0.0.46 driver from 2016 to 9.0.0.48 driver date in 9/2018? I was having DPC issues and found out Chipset drivers were the problem and since i was so far in to trying to solve this problem with latencymon.exe i might as well figure out how something nvidia's drivers and ndis.sys is also causing it from time to time."

 

@limeay
Interrupt is the way for peripheral devices (not in CPU) to communicate with CPU. Handling the interrupt (raised by device) involves hardware level (device, CPU, bus), firmware level (BIOS and firmware of device and chipset controllers), and software level (OS kernel and device`s drivers).
Developer of device decides whether it will work with interrupts in MSI mode. As I take it MSI mode is native mode for PCI-Express bus and devices. So on hardware and firmware level Line mode is kinda emulated. But on the software level handling interrupt is not that different for MSI and Line modes - OS kernel should launch so called Interrupt Service Routine registered for that specific device (which in turn should schedule the actual routine through so called Deferred Procedure Call). It`s just that ISR for MSI mode has less work to do before scheduling DPC.
So if developer has not implemented MSI mode in software level nothing we mere users can do.

Do not bother too much with MSI mode tweak. It can help only with ISR stage of interrupt handling. It can be substantial for server usage (with multiple network cards, storage devices and heavy network and data load). But for home usage the improvement is little. Sure, some gurus were able to solve little glitches with this tweak, but no one gained huge performance.

PS Killer NICs are famous for its bad impact on system.

 

@mbk1969 Thank you for the reply, hard to understand that fully. I've seen some of those terms, DPC/ISR from Latencymon as i was having problems with instability with my PSU when trying to solve my DPC problems, Sora mentioned to go with newer Drivers that might solve the problems themselves. So far, i'm not sure whether 2.1.0.27 drivers from ath-drivers.eu is wise to install since they are Qualcomm's drivers and killer uses their based drivers so in essence regardless if i leave it in MSI-X mode it should be the same overall i guess because the drivers themselves should probably of not been implemented properly for that type of interrupt i'm guessing. If some day i can upgrade my connection speed down and up, i've gotta check that out and check out my latencymon dpc/isr readings when i get back my new psu probably next week as its in RMA stage right now.

Q: If MSI utility shows IRQ value of negative numbers it should be able to enabled correct? but for some unexplained reasons one nic controller can be enabled while the other cannot. i felt confused after reading the emails killer replied back with that MSI-X was enabled by default and had to do more digging to find out it wasn't and also causes performance hits too. MSI-X should give better performance but instead give worse maybe because of bad coding or nonintentional by default. I understand that Killer has bad reputation overall. So what i really wanted to ask was when your title page says "Line-based vs. MSI-X" it states negative IRQ means its enabled but now i see more questions arise now telling me that MSI-X must also be implemented right in "firmware, drivers and so forth".. This kind of is like a tree trunk that has branches coming out of it and the branches are questions arising from a main article is how i'm describing it. When i first read all you had to pretty much do was enable everything but maybe HD Audio, EHCI, i was like "OOH hidden performance tweaks" now i'm questioning some of my tweaks and since i never checked to see what defaults i had with MSI utility, i'm kinda screwed in that sense lol. It's alright though, i still believe 90-95% i have benefitted with it enabled.
^This question above is confusing AF

Also during my testings, i was turning off certain devices, off and on and trying to see lowest DPC's i can attain, majority required to be turned on. I believe when i was testing when my AR8161 was tweaked no MSI-X, it cause DPCs to go up but my testings were not very precise because like i said, my computer had problems with instability too so not a great environment to check.

Note:** who knew that a bad psu can cause instability of frames from 200FPS to as little as 70-90FPS after cold reboots and the FPS and smoothness of games feel like 10-15FPS.

 

@limeay
1. In Windows we can instruct device/drivers (at PCI-Express bus) either to work in MSI mode or to ignore MIS mode with the help of certain registry keys and values.
2. But device/drivers can ignore our registry instructions in all senses - they can ignore MSI mode and they can ignore Line mode.
3. Also drivers can BSOD after we switch the mode - worst case.
4. When device has negative IRQ number it means it works in MSI mode.
5. I saw devices working in MSI mode even without registry keys and values.

I.e. there are two aspects - the setting for device and actual mode.

So utility can show turned on MSI checkbox - meaning that device has proper registry keys and values. And utility can show positive IRQ number - meaning that device doesn`t work in MSI mode. And vice versa.

As for confusion, when you tweak something you always should compare before and after. Choosing the way of testing sometimes is not an easy task, practically science or art.

Interrupts are handled by two routines - ISR and DPC. ISR is fired first, and since it stalls CPU (core) completely it should be as short as possible. MSI mode allows it to schedule second routine (DPC) practically instantly (providing all needed info about interrupt). But in Line mode ISR should ask device back for additional information, and only after that it can schedule DPC. Also several devices working in Line mode can share same IRQ number - in that case ISRs for both devices should acknowledge which devices raised interrupt. In MSI mode there is no IRQ sharing - additional bonus. But the DPC part of interrupt handling doesn`t depend on MSI/Line modes. DPC routine should do actual work about interrupt. And we can`t influence that part. Only by choosing the version of drivers.
In old days interrupts were handled by one ISR routine which was the reason for a long periods of unresponsiveness/hiccups/stuttering. Then developers split one routine into ISR and DPC parts. ISR part is executed at very high level of priority, while DPC part is executed at lower level of priority, allowing to execute some things in parallel.

https://blogs.msdn.microsoft.com/pigscanfly/2006/10/09/isrs-and-dpcs-the-silent-killers/

 

A bit off topic, but just a heads up

don't take what that Sora guy talks for granted.. he's just some random usually know it all trol. Ok, He knows a thing or two, but most of the time he's full of himself egotripping.

He got banned here and now continues to spam gefroce forums.. well for quite some time now. A lot of users left that forum because of him, myself included.

 

@mbk1969, thank you for explaining more thoroughly. Still all these ifs and buts. At least the water is not as muddy as before

@TJ thanks. I've seen posts about users complaining back firing off back at him when he tells people that it's their faults for pc related problems. I've been told one time that after a geforce driver update that my sound settings for hdmi were being used and this never happened before until I updated and he told me to change the setting itself to off and said nvidia wasnt at fault for the complaint. Really wished he wouldn't just turn others down like that and blame faults.

 

"If there is a Qualcomm driver that matches the drivers they provide us, they will use the same driver version numbering, and the current version is 9.0.0.48. As far as I am aware, there is no Qualcomm-labeled driver that will work correctly with the E2200, E2400, and E2500 in Windows 10. "

This is false, this support representative is lying blatantly.

Killer is the only vendor that uses a versioning system completely separate to the chipset creator.

And you can't rely on killer drivers to be kept in line with windows 10's fast evolving re-work of the network stack.

 

Just in case
https://forums.guru3d.com/threads/simple-way-to-trace-dpcs-and-isrs.423884/

 

So I got sick of doing this every time there was a graphics driver update and made an application that does it automatically for anyone who wants a copy of this I uploaded the binary and source to github here:

https://github.com/TechtonicSoftware/MSIInturruptEnabler

Please note that I have not tested this out on AMD cards but should in theory work..

 

@Doctorzeus

You can add filtering of the devices (Win32_PnPSignedDriver) by fields "Started" (=TRUE) or "Status" (= 'OK' or <> 'Error') either into "objectSearcher = new ManagementObjectSearcher(" or into "foreach (ManagementObject obj in objectSearcher.Get())"

 

Can get from here
https://github.com/CHEF-KOCH/MSI-utility/releases/tag/2.0

 

Little tease: update for MSI utility is coming; but this update will benefit for Win10 users only, alas.