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

ya ponimay 4to ti ne expert no tviki vsevozmojnie ya pereproboval, problema kak raz kroetsya hdeto sdes mojet hdeto v enersgosberegaashkah)potomu 4to edinojdi polu4ilos nastroit, menya shas vozmut i zabanyat,ya smotry 4elovek ti otziv4ivii vot i hotel hde nibud v drugom meste spisatsya ! ya v dolgu ne ostanus
rgho.st / 7TVG2LQKs
rgho.st / 7GWh5xKvh

 

1. Tebya ne zabanyat, ne boisya. Sozdavay topik s voprosom o pomosh`y spokoino (v razdele pro igry).
2. Try to switch to MSI:
- High Definition Audio - IRQ 44
- GeForce GTX 1050 - IRQ 40
- all PCI Express Root Port - IRQ 16, 26, 40

 

shas mne rx560 prieedet 4erez 4asok esli problema ne budet is4erpana sozdam topic

vot posmotri ya pomenyal kartu input lag menshe stal no mishka kak budto plivet rgho. st / 7Gn42kVNH
pitalysa v msi pomenyat etih dvoih kotorie pod 18 ne menyatsya
topic ya sozdal kstati

 

vse ustroistva, kotorym polojeno, rabotayut v MSI
topic videl

 

Very nice thread, mbk1969. One of the best I've ever saw. It is in my bookmarks for about ~2 years now I think. Can't belive it has only 21 page in total(HPET has thousands of pages with arguments only on this forum, right? ).

So I've been switching MSI and Line-Based modes for my video card, as well as for my other hardware, for these last 2 years. I've come to very mixed results, which actually are potentially exposed to placebo effect because I don't have 1000+ FPS video camera to actually test motion to photon latencies on different versions of drivers and in different modes, so unfortunately I use human benchmark instead.

After switching modes on my video card on about 15 version of different drivers(300+ Nvidia drivers) I came to the conclusion that MSI and Line-Based modes have different latencies on different drives in terms of comparing them to each other. So, it is not always true that MSI mode on video card is always 5 ms faster than Line-Based mode. On some drivers it is much faster and it is easy to distinguish the difference, on other drivers they kinda feel the same in terms of latency, and with some other drivers it feels like Line-Based is even better than MSI. MSI modes of other devices(SATA, xHCI, PCIe Root Ports, etc.) also affect the motion to photon latency. So there's that.

Another thing I did in last few days is: at the start I used MSI_util to switch all of my devices to MSI mode(except for X-Fi sound card, obv):

Spoiler

[IMG]http://i.imgur.com/SoZAoEY.png[/IMG]

Then I went to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\, searched for MSISupported and switched all found DWORDs to 1.

Then after some time of testing 'MSI mode for all devices' and reading this thread again, I decided to change MessageNumberLimit for all of my devices. I searched for MSISupported and whenever I find this DWORD, I would add or edit DWORD MessageNumberLimit and set its value to 2048. Worst case scenario would be BSOD, which can be fixed with last known configuration, safe mode or WinPE in 2 minutes, so it was fine.

The differences between just using MSI_Util and regedit is that there were some devices in the PCI section in the registry that weren't listed in MSI_Util. Another thing is that through registry I switched MessageNumberLimit for all of the devices(and for ones that weren't listed in MSI_Util). Here's a comparison screenshot regedit vs MSI_Util:

Spoiler

[IMG]http://i.imgur.com/jwb0JQP.png[/IMG]

I can swear that difference between no MessageNumberLimit DWORDs and MessageNumberLimit 2048 is very comparable to a difference between Line-Based vs MSI.

My guess is that it's because after adding MessageNumberLimit and setting it to 2048, it switches some of the devices from MSI to MSI-X mode. Why didn't it work in MSI-X mode from the start, then? Because for some reason it didn't have addreg directive in its drivers to set MessageNumberLimit to 2048, it could be 1000 of reasons, one of which was the reason Nvidia didn't switch to MSI in the first place(their mistake). My logic is that the fact that device doesn't have addreg directive to set MessageNumberLimit in its driver doesn't mean it can't support MSI-X mode and can't work with 2048 message limit. But that's just my interpretation and understanding of how it works after reading this thread and articles about it on the internet.

The thing is that IMO setting MessageNumberLimit 2048 for all devices(like xHCI controller, to decrease mouse latency) definitely decreased motion to photon latency because I didn't just switch it for devices themselves(which made a difference too, of course) but for responsible for these devices PCIe Root Ports as well.

Another thing worth mentioning is that hitreg became worse in video game I play nowadays(Squad). I also remember that for pretty much all devices except for my PCIe Intel 82574L Gigabit NIC(VEN_8086&DEV_10D3&SUBSYS_A01F8086&REV_00) there was no DWORD MessageNumberLimit. But my NIC had MessageNumberLimit and it was set to 3. And it sets it to 3 every time I update(install the same driver) my NIC driver in the device manager. But in device manager there are 6 entries for my NIC:

Spoiler

[IMG]http://i.imgur.com/tpN37F1.png[/IMG]

What does it mean? Does it mean actual maximum value of MSIs I can set is 6 and not 3? or what?

My guess is that my hitreg became worse because I set too big number(2048) for my NIC and some kind of overflow of data stream happens. I've writted my whole post for this reason, because it raises another important question:

If switching all devices to MSI mode makes generally positive difference, and then setting MessageNumberLimit for all devices makes generally positive difference but hitreg become worse, does it mean that when you take each particular device by itself, it has its own 'maximum' MessageNumberLimit? Well, of course it is, but the fact that when I install NIC's drivers it sets MessageNumberLimit, doesn't mean it is a holy maximum I should never exceed. In my view this MessageNumberLimit set to 3 for my NIC is just a stock value, which I can exceed to get better performance results.

The reason I write this post is because I have questions needs answering in order to proceed pushing this MSI tweaks. How do I determine in what mode(MSI or MSI-X) my device actually work at the moment and what is the actual limit of messages it allocates simultaneously? Some devices are obviously just ignore MessageNumberLimit DWORD, because technically it's just a flag.

Then there are more questions. What are the actual maximum value of MSIs device can physically and programatically allocate(so if you exceed that value, your devices will perform worse because of overflow of data or whatever)? What physical parameters of the device affect the maximum number of MSIs it can allocate? What programmatic parameters(firmware in the chips on the device itself, Windows drivers) affect the maximum number of MSIs it can allocate?

The reason I ask these questions because in this case you can't just set everything to 1 and see what works best. Now there are 2048 possibilities for every device, so poking method isn't really a viable option. Yes, maybe 2048 for xHCI, SATA, PCIe ports, Video Card and other devices work better than 1 or default. But is 2048 actually better for every single one of these devices than 1628, 1287, 936, 426 or any other random number between 1 and 2048?


mbk1969, please read that wall of text(and anyone else who has something to say on this topic), answer questions you can and correct me on my points because my POV is much more limited than yours. I don't know where to go to answer these questions myself.

 

FWIW, I checked my Onboard NIC 82579V had both set to 1 (MessageNumberLimit an MSISupported )

Some info on max #

https://msdn.microsoft.com/en-us/library/windows/hardware/ff544246(v=vs.85).aspx

 

Kulagin check new version of MSI tool in OP. It now shows IRQs of devices.

MSI tool is for lazy people. True nerds/geeks always work with registry. -)

Note that not all devices listed in registry are actually present in system.

As for message limit number - we have no means to know whether driver uses more than one message. I saw network cards with multiple MSI IRQs, and to me it looks like namely as multiple messages utilized by driver.
According to description of MSI mode developers of device can use multiple messages for whatever reasons they want. In case of network cards multiple messages are used to spread interrupt handling among all CPUs (cores) in the system. These messages are of same type. But developers of device can use several messages of different types - data, error, notification, debug.

As for 2048, I think this limit is dictated by hardware - like some register which can distinguish only 2048 states.

 

Yes, I see now.

Well, when you have 10+ devices and you want to tinker with stuff like MessageNumberLimit, it would be very nice to have MSI_Util, which would support changing MessageNumberLimit for any device you want. I wanted to ask you to add function to change MessageNumberLimit for the devices(1 text box per device, should take about 20 minutes?), so it will become full and complete program, which will make everything faster.

I think I read here in the thread(if I recall correctly) that you didn't implement this feature because you didn't want to cause BSODs for dummies. I say that this is a pretty low-level stuff and if one wants to get into this kind of low-level stuff - one should be ready to crash their system down to deleted partitions on their HDD and be ready that it will not even boot to BIOS after this kind of changes.

ATM I am kinda forced to use registry, because using MSI_Util for changing MSISupported and then using registry to change MessageNumberLimit isn't really faster than using just registry to change everything. But if MSI_Util allowed me to change both parameters, it would definitely be much faster to switch parameters using MSI_Util only. One more function to increase speed of tests is to add a function to stop and then start a device.

Here's how journey of changing something looks like now:
1. Change MSISupported in MSI_Util.
2. Want to change MessageNumberLimit? Launch device manager, look for HWID, copy HWID, open registry, find PCI key manually in HKEY_LOCAL_MAHINE, search for HWID of the device, create MessageNumberLimit manually in the registry, set value manually. It is also error prone. I set hexadecimal 2048 quite a few times by mistake, so it was 8264 decimal. It luckily didn't BSOD and I was able to edit it later when I saw these mistake, still it's pretty bad.
3. Now after doing all of that for one single device, go to device manager, stop and start device to actually apply changed you made in MSI_Util and registry. And that's the fastest unusual way I found, I'm sure most of the people reboot their PCs, which makes it extremely slow.

This thing can take up to 2-4 minutes for a single device when you are handling and remembering HWIDs and keys you changed and what is left to do, etc., instead of focusing on testing results themselves.

Here's how it could be if MSI_Util features I proposed were implemented:
1. Launch MSI_Util.
2. Set device mode(Line/MSI, Number of messages) you want to use.
3. Press Apply Button.
4. Press Restart Device button.

And it would literally take less than 10 seconds to do everything if you know what device and mode you want to use. Instead of using 4 windows(MSI_Util, Device Manager, Device Properties, Registry), you can have 1(MSI_Util). In my opinion tinkering with registry is much more dangerous for both dummies and nerds/geeks than using a program.

I am not lazy, since I do all of that manually atm, but I like automatisation...

 

I will look into it.
There is potential problem with restarting device. If user changes MSI mode and restarts device like SATA controller and receives BSOD due to incompatibility then (1) he can loose some unsaved work/document, and (2) will receive second BSOD at boot time.

 

I've read that article numerous times but now when I am after max MSI number for my Network Card(my hitreg in video games is very good, I don't have any internet connection problems, I have 100 mb/s DHCP twisted pair connection, which goes directly into ISP's commutator, I just want to make my hitreg better than I have now), I noticed(I knew it was like that before) it says for PCIe 2.2 max number is 16, for PCIe 3.0 - 2048. So I went to check what's PCIe version of my NIC(Intel 82574L, VEN_8086&DEV_10D3&SUBSYS_A01F8086):
http://ark.intel.com/products/series/32210/Intel-82574-Gigabit-Ethernet-Controller

And it says it's PCIe 1.1. Which don't make any sense to me. In article it says that you can set MessageNumberLimit more than one for PCIe 2.0+ devices. Then in NIC's properties on the website it says that it's PCIe 1.1 but at the same time when you install a driver for a NIC, it sets MessageNumberLimit to 3 and there are 6 entries in the device manager with 6 NICs in the list:


Why there are 6 NICs in the device manager instead of 1?

Did Intel use some kind of a hack to increase maximum number of MSI's for PCIe 1.1 device(6 devices with different IRQs in the device manager)? If it was 1 MSI per one logical device in the device manager, why set MessageNumberLimit to 3 in the registry? Is it 3 MSIs per 1 logical device, which in total make it 18 MSIs for a phisical NIC? So how many MSIs my NIC is actually using by default: 1, 3 or 18? At this point I am confused and don't know what to think.

Is there a way to check which mode device is working in(1.1 or 2.0)?

Should I just go and confront Intel's technical support(or something) with these questions?

What does 0x00000010 value mean?


mbk1969, need your help .

 

That`s in hexadecimal notation. It equals to 16 in decimal notation.

Update: When you edit numeric value in regedit you can switch the view between hexadecimal and decimal formats.



Bus is (most probably) PCI Express v3. Device can be any range from v1 to v3.
All PCI Express bus versions support 2048 messages.

 

Yes, I should've said first time. I meant what does that value mean in this context:

Spoiler

It's a part about my NIC and it has this 0x00000010 REG_SZ. So I wonder what is it for there.

Yes, I understand that, but you still have to switch from hex to dec every single time you open that message box:

Spoiler

Which is very error prone.

Well, yes, on the website it says my NIC is PCIe 1.1 but it still creates MessageNumberLimit DWORD and sets it to 3.


So I changed MessageNumberLimit from 3 to dec 16 and now my internet started randomly to disconnect(it disconnected twice in last ~3 hours). I still have LAN in my internet connections showing as working properly:

Spoiler

But in fact it doesn't work. I have to disable and enable my NIC(there in connections or in device manager which is the same thing pretty much). I can't know for sure, it could be my ISP, but what are the chances of having problems with connection when I test this thing, that's very-very unusual for me(last time I had problems with my internet connection in 2009 or something and it was different ISP).

So 2048 works but worse than 3, 16 makes my NIC to stop working after ~1 hour of use.
I'll try value 6 next.

But that's my point. How do I find 'the best' value even just for my NIC? I can't really just randomly change values 3>2048>16>6>8>x>y>z>etc, and hope for best. It should be possible to calculate it somehow, I just don't know how to do that and I don't even know what to search for(like what to read to understand this topic) in order to be able to do that. There should be some way to benchmark MSI-X...

 

I don`t know what these values are and what they do. I`ve seen these too.

That`s my point - only developers of hardware (and its drivers) know what to do with MessageNumberLimit value. Some device drivers just ignores them. And some as you saw could break from incorrect values.
I guess namely network cards usually utilize that MessageNumberLimit because it is known feature - multiple MSIs to spread them among CPUs/cores.
There can not be calculator in such conditions.

I guess when device has this MessageNumberLimit in registry after installation of drivers then it is bad idea to play with it. And problem for MSI util is we don`t know whether this value came from installation. There is a chance to get info about inf-files and look for them but I will never implement such feature - it is too troublesome.

So I can re-vamp UI of utility to give user possibility to change MessageNumberLimit value, but calculator - never.

 

When I said 'calculate', I didn't mean it as 'write an MSI calculator for us, please, so we can effortlessly launch a program, press apply and be done with it'. When I said 'calculate', I meant something as opening INF file or even stealing firmware from a chip on a piece of hardware, then taking value #1 and multiplying it by value #2.

Hardware developers should know where to look to determine maximum number of messages device can transfer, right?

I guess I'll start writing emails to Intel's, Nvidia's and AsRock's tech support teams, then.IMG]http://smiles.kolobanga.ru/standart_koloboks/standart_light_skin/crazy.gif[/IMG]

Well, just as with overclocking in BIOS. You're free to set high voltage but you should be ready to burn your PC. Same here, if a person downloads MSI_Util, they should understand that they can destroy their PC.

It just feels very natural to me to have a function to set MSISupported, just as well as to have a function to set MessageNumberLimit.

 

You are kidding about stealing firmware and reading values there, right?

There always will be users who don`t know what are they doing (with tools). Who heard vaguely about some magic tweaking tool which can improve their OS. So it should be carefully designed to prevent such users from harm. BIOS diesn`t jump into user`s face. Many noobs even do not know about it.

 

I meant it as something as this:
http://dangerousprototypes.com/docs/Flashing_a_BIOS_chip_with_Bus_Pirate

I understand your point but in my view analog of this kind of tools in real life is a chainsaw. When you use it the right way everything is fine. But once you sawed off your own legs with it, well, it's your own fault, so deal with it. Nowadays you can't really create a security system, so people will not be able to dismember their own body or bodies of other people with a chainsaw:


PS I changed MessageNumberLimit from 16 to 6, it stopped disconnecting me from the internet and I also believe it is better than value 3(could be placebo). Gonna write to Intel and confront them with these questions and why they don't share this kind of parameters in the appropriate documents for every device they release...

 

How do you estimate whether it is better with particular setting?

 

Just promoting new utility pushed to existence by user tappingbowl
http://forums.guru3d.com/showthread.php?t=415848

 

http://www.mediafire.com/file/2kkkvko7e75opce/MSI_util_v2.zip

MSI utility v2.
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).

 

What do you recommend we do with the MessageNumberLimit values? The program works just fine. I took all my devices out of MSI and then put them back in and all is well. Is there something to be gained here or is this just to help Kulagin? Here is a screenshot of what my devices look like without touching any of the MNL values.

Spoiler

Any clue if I could benefit by changing my NIC MNL to something other than 5, seeing as I have 1Gb Google Fiber? Thanks for the update to this tool and all the help and advice you give out.