USb 3/4+ Future USB 8,000Hz -to- 24,000Hz polling rate

Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
howiec
Posts: 144
Joined: 17 Jun 2014, 15:36

Re: USb 3/4+ Future USB 8,000Hz -to- 24,000Hz polling rate

Post by howiec » 30 Oct 2020, 04:46

O_O wrote:
29 Oct 2020, 21:10
howiec wrote:
27 Oct 2020, 14:10
The IMOD register/mechanism is specific to Intel's implementation AFAIK.
Also, I remembered why I can't plug in my kb into the ASMedia controller.... it's cuz it uses 2 ports which I guess I could get around if I can use some sort of 2-to-1 adapter or something.
No problem finding IMOD registers for my Asmedia USB3.1. Has one type C and one type A port and no problem running low speed USB mouse directly on Type A connector however I usually have the device disabled via BIOS setup.
I see, guess I'll just have to try editing it for that controller too.

UPDATE:
Apparently my mb has the ASM3142 chip and I just tried editing the IMODI value assuming it's using the same offset as the ASM1142 controller (the only datasheet I could find online) but for some reason it doesn't seem to have any effect. Maybe I'm at the wrong address.

Did modifying the IMODI value work for yours?
If so, how did you find the IMOD register (e.g. what's your BAR and what offset did you use?) and which ASMedia chip do you have?

Thx!

O_O
Posts: 19
Joined: 26 Oct 2020, 06:19

Re: USb 3/4+ Future USB 8,000Hz -to- 24,000Hz polling rate

Post by O_O » 30 Oct 2020, 21:27

schizobeyondpills wrote:
29 Oct 2020, 10:07
where do you have problems with?
The system timer (TimerResolution) has nothing to do with USB host controller interrupts. You could run the timer resolution at 15.6ms and the USB interrupts would still be serviced as usual at 8k.
schizobeyondpills wrote:
29 Oct 2020, 10:07
notice the 488.281 micros
The system timer value is responsible for scheduling, if you constantly swap threads out then there's extra overhead with context switching and cache pollution.
schizobeyondpills wrote:
29 Oct 2020, 10:07
not programs but systems
Some programs too.
schizobeyondpills wrote:
29 Oct 2020, 10:07
yeah but u forgot the biggest two factors of power dissipation, scaling of frequency and size of both transistors/IC in nanometers, COMBINED.
We are talking about frequency scaling at the same voltage and ambient temperature. While smaller transistors can have higher power densities they usually are more power efficient but this doesn't matter. The devices quoted at 40C ambient are spec'd to work at that temperature.
schizobeyondpills wrote:
29 Oct 2020, 10:07
>This is the system timer and operates from around 0.5ms to 15.6ms, it is not windows time.
it is literally the source of time within the whole OS.

The system’s clock interval timer is probably the most important device on a Windows machine, as evidenced by its high IRQL value (CLOCK_LEVEL) and due to the critical nature of the work it is responsible for. Without this interrupt, Windows would lose track of time, causing erroneous results in calculations of uptime and clock time—and worse, causing timers not to expire anymore and threads never to lose their quantum anymore. Windows would also not be a preemptive operating system, and unless the current running thread yielded the CPU, critical background tasks and scheduling could never occur on a given processor.

^ from Windows Internals. try again please :lol:
No problem with the WI quote but windows time itself is typically the value loaded at startup offset by QPC count. That time may be updated via NTP if enabled and a network connection available which will then depending on the difference gradually or instantly update the time which is why it's not so good for measuring performance. QPC is called a performance counter for a reason although personally I prefer RDTSC(P). Does Windows still update a leap second in 2 seconds?
schizobeyondpills wrote:
29 Oct 2020, 10:07
also,please, PLEASE, stop mixing up timers and clock. its a big difference, timers are events at certain periodic intervals, clock is the source of time, tyvm.
Timers and counters!

@howiec
Didn't think about looking for an Asmedia datasheet, the similarities were enough to go by. I have the older 1142 and use microsofts driver on W10. Needed to have a device connected or the driver would disable memory space so no BAR1 data in that case. BAR values are not usually hard coded so lets just say BAR1 instead of giving it a value. At BAR1+18h is the runtime register offset which for me was 0x1000. It has 8 interrupters which are located at BAR1+0x1000+0x24, BAR1+0x1000+0x44, BAR1+0x1000+0x64... up to BAR1+0x1000+0x104. Value(s) set by the driver is/are 0xc8 but appears based on 200ns counts, not 250ns so 0xc8 would be 200ns x 200 = 40us. If using legacy interrupt then the driver just programs/uses the first interrupter, if MSI mode then all interrupts are programmed and more than one interrupter can be used. Yes, it works if modified. If you are still having trouble maybe you would post what you get for Asmedia PCI registers, BAR1 memory and runtime memory.

EDIT: Missed a / and could not fix it until after post approved. Sorry for the mess it caused. Unfortunately I have a habit of posting then editing if necessary, guess I need to remember the preview option in future :/

howiec
Posts: 144
Joined: 17 Jun 2014, 15:36

Re: USb 3/4+ Future USB 8,000Hz -to- 24,000Hz polling rate

Post by howiec » 01 Nov 2020, 00:03

O_O wrote:
30 Oct 2020, 21:27
BAR values are not usually hard coded so lets just say BAR1 instead of giving it a value. At BAR1+18h is the runtime register offset which for me was 0x1000. It has 8 interrupters which are located at BAR1+0x1000+0x24, BAR1+0x1000+0x44, BAR1+0x1000+0x64... up to BAR1+0x1000+0x104. Value(s) set by the driver is/are 0xc8 but appears based on 200ns counts, not 250ns so 0xc8 would be 200ns x 200 = 40us. If using legacy interrupt then the driver just programs/uses the first interrupter, if MSI mode then all interrupts are programmed and more than one interrupter can be used. Yes, it works if modified. If you are still having trouble maybe you would post what you get for Asmedia PCI registers, BAR1 memory and runtime memory.
Yeah, I was asking for your BAR1 as an example.

I have the exact same offset value (0x1000) but for some reason BAR1+0x1000+0x24 contains zero. The subsequent ones contain 0xFA0.
Strange but maybe it's something specific to the ASM3142 I have. I went thru the same process for the Intel controller with no issues.

I'll post values some time later after checking (disabled in BIOS atm).

Thanks for checking values on yours!

O_O
Posts: 19
Joined: 26 Oct 2020, 06:19

Re: USb 3/4+ Future USB 8,000Hz -to- 24,000Hz polling rate

Post by O_O » 01 Nov 2020, 18:31

If I had to guess I'd say your using legacy interrupt (MSI disabled) and an Amsedia driver which has set your moderation to 0.

My Asmedia with Microsoft driver sets the first interrupter (offset runtime + 0x24) to 0xc8 (200) if using legacy interrupt, or all interrupters to 0xc8 if using message signaled interrupts.

gunner7
Posts: 10
Joined: 15 Oct 2020, 14:48

Re: USb 3/4+ Future USB 8,000Hz -to- 24,000Hz polling rate

Post by gunner7 » 14 Nov 2020, 19:12

Chief Blur Buster wrote:
25 Oct 2020, 21:54
Oh and it's Blur Busters was one of the many itty-bitty contributor stakeholders that made VRR appear in the XBox one console generation earlier than planned. Their team (including Brad Rosetti) compliments Blur Busters in really popularizing the VRR and 120Hz stuff that paved the way for bosses being convinced about practical inclusion in XBox.
Hi Chief,

I was hoping you could help shed some knowledge regarding VRR with 120hz on the xbox series X. Myself and many others on Reddit are having the same problem - enabling VRR can only be done if you keep the console display settings on "auto-detect", which seems to put it to 60hz, and as soon as you manually change it to HDMI (which let's you enable 120hz), the VRR option becomes greyed out. Some people I spoke to said they CAN enable both, and they seem to have a 1440p, HDMI 2.0 monitor. In your opinion, is there a reasoning to why this may be happening? It's so frustrating not finding a solution to this. I'm starting to think my monitor's (XG240R) HDMI 1.4 port could be a problem - do you think that could be the case? Or possibly it's an issue with Xbox itself.

Post Reply