What causes a 500Hz mouse to sometimes report at 250Hz or 125 Hz?

[TooManyPixels]

you need to change option in latencymoon to check Kernel timer latency, because dpc lat.cheker check it.

Good catch...

2023-09-25 - LatencyMon kernel.png (32.85 KiB) Viewed 4392 times

Dpc lat. use timer call from driver, that is reason why when dpc lat open your kernel timer latency is decrease. Anyway, your problem that be cause by bios, or windows. Im highly reccomended to change your os to ggos, and test it, if same - that 99% about your motherboard (bios/settings/hw issue, etc).

Is there a build of ggos that I can run live off a USB stick or something?

my 8000hz mouse have same problem on 8000hz (it drop to 4000-2000-1000), but if im use 1000, or 2000 - problem is resolved.
you have same behaivor on 1000hz?

All of my higher-end mice can do between 125Hz and 1000Hz and changing the mouse's frequency to 125Hz still results in a "bad" mouse acceleration feeling.

try to disable amd gpu driver.

Have done. No effect observed. Even running with GPU cards removed (using the CPU's on-die GPU with either Intel GPU drivers or the MS Basic Display Driver)

[Slender]

You can try changing your timer resolution, as that should greatly lower your DCP latency.

To do this, download this timer resolution tool and run it.

https://github.com/therealvelo/Timer-Re ... l/releases

I can't test this one at work, but there should be a button you can press that says maximum. Once you press it, run DCPlat again and it should instantly be lower. You need this program to run at all times, so I make it run in the background on windows boot. If the number is not a perfect .500 or something, you need to do the following.

First run cmd as Admin, then Copy paste these commands 1 at a time:

bcdedit /set useplatformtick yes

bcdedit /set disabledynamictick yes

bcdedit /set deletevalue useplatformclock

If the last one says can't find the file, then HPET was disabled before and doesn't matter.

Reset PC and it should Show 0.5ms.

DONT USE RTC TIMER ON NEWER SYSTEM AFTER 1803 PLEASE!!!

[Slender]

you need to change option in latencymoon to check Kernel timer latency, because dpc lat.cheker check it.

Good catch...


2023-09-25 - LatencyMon kernel.png

Dpc lat. use timer call from driver, that is reason why when dpc lat open your kernel timer latency is decrease. Anyway, your problem that be cause by bios, or windows. Im highly reccomended to change your os to ggos, and test it, if same - that 99% about your motherboard (bios/settings/hw issue, etc).

Is there a build of ggos that I can run live off a USB stick or something?

my 8000hz mouse have same problem on 8000hz (it drop to 4000-2000-1000), but if im use 1000, or 2000 - problem is resolved.
you have same behaivor on 1000hz?

All of my higher-end mice can do between 125Hz and 1000Hz and changing the mouse's frequency to 125Hz still results in a "bad" mouse acceleration feeling.

try to disable amd gpu driver.

Have done. No effect observed. Even running with GPU cards removed (using the CPU's on-die GPU with either Intel GPU drivers or the MS Basic Display Driver)

1) I dont know about live-usb, you can try to find guide in google
2) what board you use? Bios is up to date?
3) try to disable all devices in dev.man / or try to reinstall all chipset drivers or delete it.
4) i see you have high ISR latency on your usb controller (i think DPC is highly same), anyway, i dont know how to find ussue if that is your OS, try to repair it with DISM and SFC.
5) Update windows
6) Boot in safe mode and retest

[TooManyPixels]

You can try changing your timer resolution, as that should greatly lower your DCP latency.

To do this, download this timer resolution tool and run it.

https://github.com/therealvelo/Timer-Re ... l/releases

I can't test this one at work, but there should be a button you can press that says maximum. Once you press it, run DCPlat again and it should instantly be lower. You need this program to run at all times, so I make it run in the background on windows boot. If the number is not a perfect .500 or something, you need to do the following.

First run cmd as Admin, then Copy paste these commands 1 at a time:

bcdedit /set useplatformtick yes

bcdedit /set disabledynamictick yes

bcdedit /set deletevalue useplatformclock

If the last one says can't find the file, then HPET was disabled before and doesn't matter.

Reset PC and it should Show 0.5ms.

This has no effect on Windows 10 Version 2004 or later according to MS' documentation. I also wrote my own program quickly just-now to poll-and-reset NtQueryTimerResolution and NtSetTimerResolution - and it has zero effect on the numbers reported by LatencyMon - nor does it stop my mouse from reporting at 250 Hz when I move it at-just-the-right-speed.

2023-09-25 - NtSetTimerResolution does nothing.png (464.99 KiB) Viewed 4282 times

(Where it says "5,000μs" it should say "500μs" - I forgot to divide by 10 when I took that screenshot).

[TooManyPixels]

I have an Arduino that I've programmed to play-back HID reports based on actual real-life mouse movement data - but also entirely synthetic data, so I took a recording of my real-life mouse movement but played it back at fixed report rates of 250 Hz, 333 Hz, 500 Hz and 1000 Hz and re-ran my movement recorder (that uses Win32 Raw Input) and plotted the results... and it's weird, natch.

At first I thought the delayed samples were such that their equivalent delay was half the intended report-rate, but after looking at the data what we see is that (at a regular interval) many reports are delayed by exactly 1ms, which just-has-the-apparent-effect of halfing the report rate, but it isn't the same thing once you try different rates (e.g. 333 Hz):

• At 250 Hz (sent at a 4ms interval) most reports are received with ~4ms between them, but some reports are delayed by an additional 1ms (for 5ms total), hence the second cluster of data with "200 Hz equivalent".
• At 333 Hz (sent at a 3ms interval), again, most reports are received with ~3ms between them, but others (at regular intervals) are received (again) with an additional 1ms delay (for 4ms total), hence why the line appears at 250 Hz and not 166 Hz.
• At 500 Hz (2ms interval), most reports are recieved with ~2ms between them, but the others have almost exactly 3ms between them.
• At 1000 Hz (1ms interval) there's a lot of jitter, but I believe that's due to the (comparatively limited) timer resolution on my Arduino - so I'm not concerned by it - but we see how the extra 1ms to the subset of reports causes their "equivalent hz" to be 500 Hz.

So this is... interesting. The fact that the reports are being delayed by almost-exactly 1ms is surprising and unexpected.

...but it's nice that I no-longer have to rely on my vague "feelings" about how my mouse is because I can now produce consistent USB inputs and get raw data back from the OS which allows me to actually see what's changed.

However I haven't yet fully validated my approach yet: I need to verify that the HID reports are in-fact being sent at regular intervals, I will be able to do that within a few days.

All data was gathered while I ran a program that set `NtSetTimerResolution` to 500us (0.5ms).

[TooManyPixels]

I can only post 3 attachments per post - here's the 1000 Hz one.

[TooManyPixels]

So I disabled my NtSetTimerResolution program and let the timer "naturally" float (it settled on 0.997ms instead of the 0.496ms I was forcing it to) and then I re-ran the 1000 Hz input.

I wasn't expecting there to be any difference compared to before (because I'm skeptical that NtSetTimerResolution has any influence over Win32 Raw Input - to my knowledge it only impacts specific (and legacy) userspace timers, not kernel-mode stuff anymore), but I observed roughly 3x more outliers where reports were seemingly periodically received at a higher rate briefly, then under-reported, then back to 1000 Hz again. So I'll concede that my data does suggest that NtSetTimerResolution has an impact on these (few) outliers, but at the same time it didn't impact the "+1ms" data... weird.

The first chart below shows the data with the outliers filtered out so the chart is easier to see, and we see the exact same +1ms behavior as before, while he second chart has those outliers (above "2000 Hz") so you can see what I saw.

[TooManyPixels]

Relating to LatencyMon, the authors of that program told me that the "kernel timer latency" numbers are meaningless now:

Thanks for your message.

Since Windows 8, "kernel timer latency" does not give any meaningful result regarding the real-time capabilities of a system. For battery saving purposes, Windows timers nowadays fire when deemed appropriate.

Kind Regards,

Daniel Terhell
Resplendence Software Projects

I had a feeling that was the case - so if anyone harps on about LatencyMon's kernel-timer-latency numbers on Windows 10, point them to this screenshot.

2023-09-29.png (73.64 KiB) Viewed 3968 times

[sherifmagdy32]

What causes a 500Hz mouse to sometimes report at 250Hz or 125 Hz?

Annotated.png

This particular kind of mouse "lag" is the same one I've been dealing with for the past 4 years.

I don't want to call it "lag" because, strictly-speaking, this isn't a latency issue, but it seems to be a variable sensitivity and/or variable movement report-time. This happens with a variety of mice too, and on a variety of computers (all affected machines have Intel CPUs, I have an unaffected machine with an AMD processor; all machines are running Windows 10 22H2).

I know that moving the mouse very slowly (e.g. 1 mouse-unit per second) will result in MouseTester reporting very slow frequencies - but I get this 250Hz and 125Hz (and oddly, ~167Hz too) when I move my mouse at a reasonable natural speed which should always be reported at 500Hz.

I am aware of XHCI moderation, but the minimum moderation interval is 250ns - but 250Hz is 4ms (quite a few orders of magnitude higher!) - but also because I purchased a StarTech USB 2.0 PCI-Express card (USB 2.0 is EHCI, not XHCI) and I can reproduce the issue when my mouse is plugged into either the USB 2.0 card or my motherboard's USB 3.0 ports.

I cannot reliably reproduce this on-demand, but it tends to happen throughout the day, then be fine for a few days, then reappear again.

----

Obligatory list of things to mention:

• Issue started affecting me around October 2019
• It happens regardless of the mouse model I'm using (Razer Basilisk V2, Logitech G400, Logitech MX518, some random no-name mice, and interestingly, also it feels like the PS/2 touchpad in my laptop is affected too)
• Affected computers of mine:
  • Intel NUC 11 (with Intel i7-1165G7) built in 2021
  • ASUS Z490-E (with Intel i7-10700K) built in 2020
  • ASUS X99 (with Intel i7-6850K) built in 2016
  • Dell XPS 9560 (with Intel i7-7700HQ) built in 2017
• Unaffected computers of mine:
  
  • ASUS X570-E (with AMD Ryzen 7 2700X)
• Issue is reproducible in both USB 2.0 ports in a USB 2.0-only card (this card from StarTech) and in USB 3.0 and USB 3.1 ports on all affected machines.
• Issue happens with Intel CPU-integrated graphics, and with NVIDIA GeForce, AMD Radeon, and AMD Radeon Pro GPUs.
• It definitely is not EMI or anything like that (because it also happens on my XPS laptop when I'm in the outdoors, or anywhere)
• LatencyMon Pro 7.31 shows nothing unusual even when I can reproduce the issue
• The older dpclat.exe seems to think there's a 1000us latency, but given the age of the program ("DPC Latency Checker V1.4.0" is from 2015) it predates Windows 10 entirely and I understand MS made changes to how applications can access system timers since then.
• I have fiddled with EFI and Windows boot settings (e.g. HPET, UsePlatformTick, DisableDynamicTick, and the rest, to no effect, and I'm familiar with this article too).
• Disabling/removing all networking hardware made no difference (so the first person to say "bufferbloat" unironically gets a stabbing).

I highly recommend following AMIT guide this is my personal opinion but i think it is one of the best guides out there if not the best right now with this guide and bios optimizing you should lower the chances that it is a windows problem if the results are the same after optimizing i would think it is probably hardware or electricity problem.
after you optimize your system report back with your testing i hope you will see a huge improvements.

Guide link: https://github.com/amitxv/PC-Tuning

[TooManyPixels]

I've been spending time doing more Windows ETW traces in the kernel and USB stack, including using a USB protocol analyzer I purchased and comparing the traces with the final data I captured from the (Win32 Raw Input) WM_INPUT messages, and I believe I've found evidence that the problem relates to how Windows controls USB controllers.

The periodic "+1ms" that happens to incoming HID reports seems to be because Windows is sending out two USB SOF token packets when it should only be sending out only one (the traces also show my USB devices returning NAK more often that I'd expect). I'm still trying to find out why Windows is doing that. This seems to happen whenever a computer has at least 1 USB 3.0 (XHCI) controller, even if the device is connected to a USB 2.0-only controller.

However, I still haven't yet absolutely positively confirmed that the periodically delayed USB transactions with the HID reports are the reason for the "floaty mouse" problem.