Clarification re: XHCI IMOD in ReadWriteEverything

[daiplusplus]

https://github.com/djdallmann/GamingPCSetup/tree/master/CONTENT/RESEARCH/PERIPHERALS

Click the value that is in the position 18hex, when selected will be indicated by the numbers in red in the upper left corner of the grid. Make note of this value (Base address offset/Base address space offset)

• The red digits in the top-left corner of the Memory window grid are in Base 10, not Base 16 - so the displayed red "18" is really just 0x12, which is not 0x18.
• The BAR1 address often has 4 at the end, e.g. 0xED190004. When RWE's Memory window opens when you jump to that address the last digit in the Address = button is reset to 0, which throws me off.
  • e.g.: if my BAR1 is 0xED190004 and I double-click on the PCI window cell with that value, the Memory window's Button says Address = 00000000ED190000. If I click the button and add-back the "4" at the end then the Memory window seems to show the original BAR1 address' contents fine (so why does the Memory window initially round-down addresses despite not needing to?).
  • Your screenshots show you adding 0x24 to the 00000000F7310000 instead of adding 0x24 to 00000000F7310004, but Intel's documentation (5.5.2.2, page 426) says the offset is "RuntimeBase + 0x24 + ( 0x20 * Interrupter )" - so what's going on?
  • UPDATE: - I see that Intel's documentation defines RuntimeBase as "The Runtime Base shall be 32-byte aligned and is calculated by adding the value Runtime Register Space Offset register to the Capability Base address" - but your article doesn't show you performing the same calculation.

Double click the address space field. e.g. Address = 000000000000

• You can't double-click that button. Single-clicking it opens the Start Address dialog.

---

• Your article only mentions setting IMOD for the first BAR1, but the Intel documention says there's up to 1,024 interrupters - should we update them all, or not? If so, how can we feasibly update that many?

[dougg0k]

I built a script to disable imod usb.
https://github.com/lowlatencygaming/gaming_os_tweaker/blob/main/scripts/optional_helpers/interrupt_moderation_usb.ps1

[daiplusplus]

@djdallmann Why did you close this as Completed?

[djdallmann]

@daiplusplus take a look at this discussion #12 and @dougg0k powershell script, looks like it handles multiple interrupters. I haven't tried it myself but see if it does what you're looking for.

I'll review your other comments.

[dougg0k]

It handles all interrupters that is available in the controller, it can be from 1 to 1024, but commonly are 8. It's able to find the amount per controller, and act in all of them from the first.
https://github.com/lowlatencygaming/gaming_os_tweaker/blob/main/scripts/optional_helpers/interrupt_moderation_usb.ps1#L279

[djdallmann]

Thanks for the discussion so far, please see below.

https://github.com/djdallmann/GamingPCSetup/tree/master/CONTENT/RESEARCH/PERIPHERALS

• The red digits in the top-left corner of the Memory window grid are in Base 10, not Base 16 - so the displayed red "18" is really just 0x12, which is not 0x18.

• I think you're right about both, I think I clicked on the wrong value in the screenshot for the demonstration, if you look at my images there's another "2000" value at x18 (24 decimal) from my F7310000 address in screenshot which is the appropriate Base Address Offset value.

• The BAR1 address often has 4 at the end, e.g. 0xED190004. When RWE's Memory window opens when you jump to that address the last digit in the Address = button is reset to 0, which throws me off.

• Yea, I didn't look into it very closely but it seems to align in the end. Could be something to do with the number of bits represented vs their actual byte boundaries. You can also see that it does end in zero in Windows Device Manager (not sure if it's always the case but as example/comparison). Open device manager, find your XHCI Controller, right click, go to Properties then Resources. You should then have the starting memory address (Base Address) and range.

• e.g.: if my BAR1 is 0xED190004 and I double-click on the PCI window cell with that value, the Memory window's Button says Address = 00000000ED190000. If I click the button and add-back the "4" at the end then the Memory window seems to show the original BAR1 address' contents fine (so why does the Memory window initially round-down addresses despite not needing to?).

• Looks like double click has different behavior when there's a BAR1 and BAR2 for the USB XHCI Controller, some just have BAR1 like mine did at the time.

If you have BAR1 and BAR2 as follows the actual starting memory address is BAR1+BAR2 = 4410000004 (likely 4410000000 due to above discrepancies, byte boundaries etc)

• BAR1 0x10000004
• BAR2 0x00000044

• Your screenshots show you adding 0x24 to the 00000000F7310000 instead of adding 0x24 to 00000000F7310004, but Intel's documentation (5.5.2.2, page 426) says the offset is "RuntimeBase + 0x24 + ( 0x20 * Interrupter )" - so what's going on?

• Discussed in comment above.

• UPDATE: - I see that Intel's documentation defines RuntimeBase as "The Runtime Base shall be 32-byte aligned and is calculated by adding the value Runtime Register Space Offset register to the Capability Base address" - but your article doesn't show you performing the same calculation.

• Isn't this what RWEverything is providing for us in PCI Devices, Runtime Base = Base Address Register, BAR1/BAR2 etc?

Double click the address space field. e.g. Address = 000000000000

• You can't double-click that button. Single-clicking it opens the Start Address dialog.

• Correct, my guide doesn't account for PCI Runtime Base Address when there's more than one BAR, commented on that above and how to account for it. e.g. BAR1+BAR2

• Your article only mentions setting IMOD for the first BAR1, but the Intel documention says there's up to 1,024 interrupters - should we update them all, or not? If so, how can we feasibly update that many?

• I haven't seen anyone dig into this in depth but @dougg0k made a script to try to account for that , this discussion was in issue persistently disabling interrput moderation on xHCI disabling technique? #12. Windows 8/10 interrupt moderation is already very low 50us (microseconds), Windows 7 was default 1ms (millisecond). From what I've seen in other communities they say that disabling interrupt moderation can improve polling variance for 8khz devices but doesn't seem to have significant impact for 1khz polling devices.

[ghost]

I have also written a script which is significantly less lines, simpler and more transparent than the one above. The source can be found here.

[dougg0k]

It's a nice addition, I suppose I could trim down my implementation, but that would provide less information and functionality, and maybe even less clarity in how I reached each value.

---

It is noticeable, at least in the feeling of the mouse movement, even in 1khz.