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: 167
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: 167
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.

User avatar
Kamen Rider Blade
Posts: 23
Joined: 19 Feb 2021, 22:56

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

Post by Kamen Rider Blade » 26 Feb 2021, 15:05

Again, trying to go past 8 kHz is largely pointless because the smallest transmission size of data packets is down to 125μs (micro-seconds) for USB 2.0 by way of the USB 2.0 standard and it's smallest amount of data to be sent is in micro-frames that are of a temporal resolution of 125μs between micro-frames.
USB 2.0 transmits SOF/uSOF at fixed 1 ms/125 μs intervals. A device driver may change the interval with small finite adjustments depending on the implementation of host and system software. USB 3.0 adds mechanism for devices to send a Bus Interval Adjustment Message that is used by the host to adjust its 125 μs bus interval up to +/-13.333 μs.
USB 3.0 doesn't allow much adjustment past 125 μs for the tiny micro-frame, they probably only allows that +/- to have easy adjustment or time correction.

And I REALLY doubt that the USB forum that works on the USB standard cares, understands, or thinks about the low latency implications like we do. Those normies probably think 1 ms is good enough for us and 8 kHz is extreme. We think 8 kHz is barely enough, we want lower latency! The Road to 1000 FPS displays will need lower latency protocols for our input devices.

This is why I think we have a impending bottle neck / log jam at the Protocol level
Impending Input Bottle Neck in Wired Communications Protocols (USB)

And we as enthusiasts of low latency need to take control of IEEE 1394 (Popularly known as FireWire) and use that technology to lower latency.

The only way we can do that is via Open Source & Common standards and built on IEEE 1394's connections legacy / past.

ThunderBolt focused only on Bandwidth, we care only about latency.

And from everything I can understand about FireWire (I'm using Apple's label for ease of understanding instead of IEEE 1394), they were always at 8 kHz with it's packet's temporal resolution set around 125 μs.

When we can take ahold of the standard and force the temporal resolution to scale to ever smaller sizes via halving, we can get what we want in terms of latency and smoothness. The last of the FireWire patents has recently expired and that opens up opportunities for Open Source & Common Standards to itterate on it for our purposes. The issue is gathering enough engineering talent and like minded folks to work on it and improve on it while maintaining backwards compatibility with existing IEEE 1394 devices or deciding on things like scrapping backwards compatibility.

We'll eventually push from:
125.0000000 µs
_65.5000000 µs
_31.2500000 µs
_15.6250000 µs
__7.8125000 µs
__3.9062500 µs
__1.9531250 µs
__0.9765625 µs

That'll be a realistic road to lower latency past USB's 8 kHz barrier IMO.

We'll want our packet's temporal resolution to get into the nano-second range.

And I don't think 1000 fps displays should be the limit, that should be a minimum standard and we'll eventually push past that for even smoother displays. It'll be a long term project passed down from generation to generation.

empleat
Posts: 79
Joined: 28 Feb 2020, 21:06

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

Post by empleat » 26 Feb 2021, 20:10

Kamen Rider Blade wrote:
26 Feb 2021, 15:05
d
Well said! Yeah it is funny, even average tweaker, which reads these forums probably knows how important these things are!

Yeah even DPC latency is still underestimated! Even 500$ Asus mobos for example suffer from 1ms+ DPC latency. And manufacturers don't care much. Never heard any manufacturer to say anything about DPC latency EVER!

For what they care, they can sell you this and it won't work properly, or be maybe even worse than 500/1000hz. Same like 16k+ DPI. Classical marketing...

I Am not an expert and this is already pretty esoteric, like timers. And I know nothing about timer resolution, or when we can expect update to 125us and less - I wonder. Because problem is: it has no way to know: when you move your mouse and when polls from USB controller will happen and how quickly interrupts will be handled by OS, so I doubt this could be ever synced! So even with 125us timer, there could be 124us additional delay! Depending how you hit this window! Not to even mention DPC latency. Which is like 90us max. in-game for USB3 driver, on one of better mobos - ASUS z390-i gaming. My mobo has average 100us interrupt to user process latency, if ntoskrnl.sys won't fuck it! Tho some are getting better, saw even 45-55 one on Anadtech - z490. Still these are rare and you already have to pick from other 100 parameters, hard to find!

a. no one tests mobos for DPC latency except Anadtech some (because it differs per HW configurations greatly) (mainly because drivers, which are determined by hardware present) seems manufacturers still don't care!
b. Windows update can cause huge DPC latency spikes for ntoskrnl.sys and worse other drivers responsiveness probably. And we know Windows update is worst thing and may not be fixed long time! Can break 8khz polling for long time!
c. For some reason ASUS thinks, it is not necessary for gamers to have control of HPET in BIOS. Maybe can be accessed with mod...
d. Timers affect mouse feel greatly, also consistency and precision, even 0.051~ and I can tell that on mouse precision! I guess it affects when interrupts are handled and other operations, like when perform some rendering operation on GPU. AS it plans time sensitive operations, when they should be performed. Useplatformtick makes mouse more accurate (uses 0.5ms round timer), but increases input lag and in microsoft docs is: that it should be used only for a debugging!
e. USB 3 is not optimized for latency and before it goes through USB Chipset OMG
f. Even more important than DPC latency for input lag:are features in BIOS and who knows what bottlenecks these can create!
g. AMD has bad USB chipset currently and it is just pain, hope it gets better for gaming!

I expect ESPORTS could bring more attention to this, in 1-2 years 500hz is expected. So pro players will have problems with consistency. And maybe manufacturers address this! Finally we can play without lag? :D Even 144hz is lagged :D I can tell 6ms input lag from Input lag AB blur busters test and I Am extremely sensitive to it! Hate input lag!!! :x I want 1ms :D

BTW VR suprised me, even 60fps with some projection and it has lowest input lag I ever saw! I expected it to be meh 60fps gameplay. As input from controllers can be updated to interpolated frames, but still! As 60fps I can see tearing and dynamic input lag, it is for me like 24 fps now... I don't even know, how it is possible. I have Index and it has 0 input lag almost I would say! Also smoothness is amazing no blur, or tearing only at 120 interpolated fps with reprojection...

BTW other thread says Firewire is good, but I have no idea, if this could be used. It was dead long time and now it is pretty much Apple niche...

viewtopic.php?f=10&t=8290&p=64190#p64190

NDUS
Posts: 38
Joined: 12 Aug 2019, 16:05

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

Post by NDUS » 26 Feb 2021, 20:58

schizobeyondpills wrote:
17 Oct 2020, 08:32
pixart sensors per their specsheets have a temperature operating temp of 40deg c
i guess the reason for this is because they're infrared sensors and hot objects radiate in that spectrum.

i think that in 10 or 20 years, mouse sensors might be using UV light. no heat contamination, superior imaging resolution, and you can use glass lenses (impossible with infrared sans very expensive fluorite)

User avatar
Kamen Rider Blade
Posts: 23
Joined: 19 Feb 2021, 22:56

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

Post by Kamen Rider Blade » 27 Feb 2021, 00:35

Don't even get me started on HPET timer precision.

The HPET standard needs a minimum Frequency resolution of 10 MHz

But Intel & AMD implement wonky resolution choices for each tick of time.

Intel has thier HPET @ 24.00 MHz, that gives you a temporal resolution of ~41⅔ nano-seconds
AMD has their HPET @ 14.32 MHz, that gives you a temporal resolution of ~69.832402234636871508379888268156 nano-seconds

Why couldn't both of them agree on 25 MHz which would give you a temporal resolution of 40 nano-seconds.

A nice clean & even number, argh!!!

Post Reply