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.
User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

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

Post by Chief Blur Buster » 28 Jul 2022, 21:34

billbishere wrote:
28 Jul 2022, 10:55
I am trying to figure out if all USB C cables are capable of 8k polling or if there is something I should be looking for? I am replacing the USB cable on my Corsair K65 - 60% keyboard. Looking to change to an Aviator style coiled cable but wasn't sure if they are all capable of 8k as this keyboard has an 8k polling rate. Not saying it's good or bad just didn't want to screw up the polling rate.
All USB-C cables are capable of 8KHz. The cable is not the limiting factor on pollrate.

Hubs can be, and USB chips can be, so make sure you test all your USB ports, or use a PCIe USB card (to bypass crappy motherboard USB ports in a situation where you don't want to replace motherboard, or if motherboard is overloaded with lots of plugged-in USB devices).
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

billbishere
Posts: 2
Joined: 28 Jul 2022, 10:50

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

Post by billbishere » 28 Jul 2022, 21:53

thank you very much sir!

styhk
Posts: 9
Joined: 23 May 2022, 16:55

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

Post by styhk » 06 Dec 2022, 05:02

Chief Blur Buster wrote:
28 Jul 2022, 21:34
billbishere wrote:
28 Jul 2022, 10:55
I am trying to figure out if all USB C cables are capable of 8k polling or if there is something I should be looking for? I am replacing the USB cable on my Corsair K65 - 60% keyboard. Looking to change to an Aviator style coiled cable but wasn't sure if they are all capable of 8k as this keyboard has an 8k polling rate. Not saying it's good or bad just didn't want to screw up the polling rate.
All USB-C cables are capable of 8KHz. The cable is not the limiting factor on pollrate.

Hubs can be, and USB chips can be, so make sure you test all your USB ports, or use a PCIe USB card (to bypass crappy motherboard USB ports in a situation where you don't want to replace motherboard, or if motherboard is overloaded with lots of plugged-in USB devices).
This isn't true, cable with high impedence could malfunction when running at high polling rate.

sherifmagdy32
Posts: 121
Joined: 08 Jan 2022, 23:43

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

Post by sherifmagdy32 » 06 Dec 2022, 15:20

schizobeyondpills wrote:
29 Oct 2020, 10:07
O_O wrote:
27 Oct 2020, 07:51
schizobeyondpills wrote:
17 Oct 2020, 08:32
Windows kernel timer has a limit of 0.5 ms interrupt intervals.
What does that have to do with 8K polling rate?
its an indicator that windows is not engineered for such high performance devices, its not hard to see or figure out, where do you have problems with? do you need further help? RTC and HPET allow far lower interrupt intervals than 0.5ms but Windows does not implement them intentionally due to being very badly engineered outdated kernel which is not optimized to handle such high freq interrupts.

look at https://forums.guru3d.com/threads/windo ... ng.377790/

then at https://www.compuphase.com/int70.txt which is RTC clock freq, for example, windows is limited to 0.4992ms interrupt interval however any RTC clock can do 8kHz interrupt intervals, but windows doesnt allow u to do this unless you patch it (yes i did it, yes it feels amazing vs 0.5ms cripple limit)

Code: Select all

Periodic Interrupt
==================
The frequency of this interrupt is programmable from 2 to 8192 per
second. To use this type of interrupt first set RS (Rate Select)
bits in Status Register A to the required value:

  RS    Int/sec         Period
 3210      -              -
 0000   none            none
 0001    256            3.90625 ms
 0010    128            7.8125  ms
 0011   8192            122.070 Micros
 0100   4096            244.141 Micros
 0101   2048            488.281 Micros
 0110   1024            976.562 Micros
 0111    512            1.93125 ms
 1000    256            3.90625 ms
 1001    128            7.8125  ms
 1010     64            15.625  ms
 1011     32            31.25   ms
 1100     16            62.50   ms
 1101      8            125.0   ms
 1110      4            250.0   ms
 1111      2            500.0   ms
 
 
notice the 488.281 micros, which is exactly what u will get if u disable HPET and use windows API to set timer to 0.5ms, or 0.488ms =)
windows is not engineered for high performance computers operating on constant clock at 4GHz+ per core so they dont allow you to set it all the way up to 8kHz.

same goes for HPET and other sources, https://wiki.osdev.org/Timer_Interrupt_Sources#HPET they are all crippled within windows being targeted at laptop users and casual desktop.
"Rate" is the divider setting. If you select a rate of 1 or 2, the RTC will have problems and "roll over" so that it generates interrupts of .81 mS and 3.91 mS, rather than the expected interrupts of 61.0 uS or 30.5 uS. So, the fastest rate you can select is 3. This will generate interrupts of 8 kHz or 122 uS.
>Percentage is going to be lower than that I think but just like you generally wouldn't pair a top end graphics card with a low end CPU, 8K isn't for everyone and some programs may choke.

not programs but systems, big difference. only top 0.000001% of PCs will have actual stable 8000Hz (that means looking at few digits past the decimal seperator )


>No, 40C is maximum recommended ambient temperature, the temperature of the air near the sensor while absolute ambient temperature is likely 15C higher than that. USB polling will be taken care of by the MCU which might be a LPC11U3... which has an ambient specification of -40C to 85C and a maximum junction temperature of 150C.

Thats just the "recommended" spec which does not reveal real life measures of usage under closed shell on a nanosecond/ps scale graph of performance, something "working" doesnt mean its working properly, just as a human being can run but it starts to fall apart, doesnt mean its working optimally. just "working"


>Temperature is a result of power dissipation and dynamic power is proportional as voltage is constant.

yeah but u forgot the biggest two factors of power dissipation, scaling of frequency and size of both transistors/IC in nanometers, COMBINED.


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


its very sad that so many of you are very attached to marketing buzzwords rather than verifying those claims yourself.

reality has more depth than what you can perceive, it is not a single layer of "good" or "bad". the layers are infinite in depth, and reasoning about them absolutely does NOT start at a single layer. only a blind fool would do that.

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.

@Chief
15 years of Moore’s Law on USB processing.
Moore's Law has nothing to do with whats implemented in reality, just as Intel is selling same cores for 10 years (Ivy Bridge CORE). Sure, moore's law has atom sized transistors, but Intel bounced off 10nm into 14nm, after being there for +++++ generations :cry: :cry: :cry:
Can you please share how did you get windows patched to allow RTC clock do 8kHz interrupt intervals.

User avatar
schizobeyondpills
Posts: 103
Joined: 06 Jun 2020, 04:00

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

Post by schizobeyondpills » 08 Dec 2022, 06:48

in windows 7:
- find "HalRTCTimeIncrements" table
- figure out its relative offset to kernel image
- load driver either signed with leaked cert or in dev mode(test sign enabled - in dev mode w test signing enabled most anticheat games wont launch so you either need a leaked cert to sign your driver or buy a legitimate code/driver signing ceritficate )
in your driver code:
- find kernel base address
- add relative offset of HalRTCTimeIncrements to base addr(use MmGetSystemRoutineAddress to find HalSetTimeIncrement function which references HalRTCTimeIncrements )
- patch the *whole* table interrupt values with value you get from formula below
- re-arm the RTC timer by calling ExpUpdateTimerConfiguration or usermode functions NtSetTimerResolution etc ..with lowest values you want(kernel will scan this table to find value that is below or equal to interrupt interval you requested)

The formula to calculate the interrupt rate is:

freq. = 32768 >> (rate-1)
where *rate* is the value of the lower four bits of status register A. This value must be between 1 and 15 (selecting 0 stops the periodic interrupt). The interrupt frequency you can choose is thus always a power of 2 between 2 Hz and 32768 Hz. There is a caveat, however. With an input signal of 32768 Hz, the timer output 'rolls over' if you set the value *rate* to 2 or 1. Instead of producing periodic interrupts of 61.0 uS or 30.5 uS respectively, they produce 7.81 mS and 3.91 mS interrupts. The fastest interrupt rate you can generate is 8 kHz (122 uS interrupts), by setting *rate* to 3. Higher frequencies requires a higher base frequency, and this would require a different crystal than is installed in the IBM PC-AT.

you need to verify what you are doing with windbg and look at the memory of what you are modifying, dump the original table from memory first to figure out how it looks and its structure, then figure out first element of this array, then patch that, patch the whole table afterwards

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

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

Post by flood » 09 Dec 2022, 14:00

styhk wrote:
06 Dec 2022, 05:02
Chief Blur Buster wrote:
28 Jul 2022, 21:34
billbishere wrote:
28 Jul 2022, 10:55
I am trying to figure out if all USB C cables are capable of 8k polling or if there is something I should be looking for? I am replacing the USB cable on my Corsair K65 - 60% keyboard. Looking to change to an Aviator style coiled cable but wasn't sure if they are all capable of 8k as this keyboard has an 8k polling rate. Not saying it's good or bad just didn't want to screw up the polling rate.
All USB-C cables are capable of 8KHz. The cable is not the limiting factor on pollrate.

Hubs can be, and USB chips can be, so make sure you test all your USB ports, or use a PCIe USB card (to bypass crappy motherboard USB ports in a situation where you don't want to replace motherboard, or if motherboard is overloaded with lots of plugged-in USB devices).
This isn't true, cable with high impedence could malfunction when running at high polling rate.
for 8khz polling you need high speed usb which means the data in the cable must carry a 480mbps signal.

this is fast enough where many things can go wrong using some cables. this can range from failure to enumerate the device at all, to dropping a few percent of packets. and in general, this behavior can change when using different usb ports - some ports are more robust than others.

basically the issue is noise. you need a sufficiently shielded twisted pair. braided or foil shields work well. spiral shields don't, and generally start performing poorly unless the cable is shorter than some characteristic length.

source: personal experience helping to develop/debug the zaunkoenig m2k.

zooked
Posts: 2
Joined: 25 Mar 2023, 22:31

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

Post by zooked » 26 Mar 2023, 13:21

schizobeyondpills wrote:
08 Dec 2022, 06:48
in windows 7:
- find "HalRTCTimeIncrements" table
- figure out its relative offset to kernel image
- load driver either signed with leaked cert or in dev mode(test sign enabled - in dev mode w test signing enabled most anticheat games wont launch so you either need a leaked cert to sign your driver or buy a legitimate code/driver signing ceritficate )
in your driver code:
- find kernel base address
- add relative offset of HalRTCTimeIncrements to base addr(use MmGetSystemRoutineAddress to find HalSetTimeIncrement function which references HalRTCTimeIncrements )
- patch the *whole* table interrupt values with value you get from formula below
- re-arm the RTC timer by calling ExpUpdateTimerConfiguration or usermode functions NtSetTimerResolution etc ..with lowest values you want(kernel will scan this table to find value that is below or equal to interrupt interval you requested)

The formula to calculate the interrupt rate is:

freq. = 32768 >> (rate-1)
where *rate* is the value of the lower four bits of status register A. This value must be between 1 and 15 (selecting 0 stops the periodic interrupt). The interrupt frequency you can choose is thus always a power of 2 between 2 Hz and 32768 Hz. There is a caveat, however. With an input signal of 32768 Hz, the timer output 'rolls over' if you set the value *rate* to 2 or 1. Instead of producing periodic interrupts of 61.0 uS or 30.5 uS respectively, they produce 7.81 mS and 3.91 mS interrupts. The fastest interrupt rate you can generate is 8 kHz (122 uS interrupts), by setting *rate* to 3. Higher frequencies requires a higher base frequency, and this would require a different crystal than is installed in the IBM PC-AT.

you need to verify what you are doing with windbg and look at the memory of what you are modifying, dump the original table from memory first to figure out how it looks and its structure, then figure out first element of this array, then patch that, patch the whole table afterwards
Would it not be simpler to find the base address of the global kernel variable nt!KeMinimumIncrement, add the relative offset, turn off write protection and edit it to whatever resolution you want? This variable sets the minimum resolution and I've only tried modifying it with windbg, but it defintely worked. I don't have enough knowledge to code a km driver on my own and you're among one of the few people who have accomplished this. Could you shoot me a pm and give some guidance sometime?

Proof of concept of editing the variable with windbg
Image

Post Reply