Native (plug-and-play) 8000hz mouse

[NDUS]

https://atompalm.com/



• due for release in fall 2020
• uses a USB Hi-speed microcontroller to allow for native (non-overclocked) 8000hz polling
• uses some kind of special debouncing circuit to remove debounce delay from switches. Should have the lowest input delay of any mouse (perhaps on par with the Zaunkoenig M1K, which has 3-pin debounce)
• 45 grams
• corded
• PMW3360
• Japanese gold-cladded omrons (D2F-01F) - big-company mice use Chinese brass-cladded omrons
• anodized aluminum scroll wheel

This is the only mouse of its kind, there are zero other USB Hi-speed mice.
Should immediately work at 8000hz after plugging it in. No overclocking needed.

For information on above-1000hz mouse polling (does it make a difference etc.,) see:
Chief Blur Buster's article on the matter
Chief Blur Buster's post on the matter
my thread on the matter

[Chief Blur Buster]

This is fantastic to see official 8000 Hz mice.

Thanks for posting this.

[PixelDuck87]

What's the reason going above 1000hz?

[jorimt]

What's the reason going above 1000hz?

So we can go "Over 9000!"...sorry, had to

In all seriousness, more frequent polling rate = smaller "gaps" = more granular control. It's the same principle as higher framerates and higher refresh rates. Ultimately, we want to achieve 1:1 input/feedback. Mouse polling rate is one of the factors necessary for that.

It will reduce this effect, even at currently achievable refresh rate:
https://blurbusters.com/faq/mouse-guide/



Everyone seems to have a really hard time understanding that input lag at any level is not intended, and is instead an artificial limitation of current technological capability. Diminishing returns or no, it doesn't mean we should just stop at 1000Hz polling rate, or 240Hz refresh rate just because it's "good" enough for some. Finite polling rate isn't necessary, finite refresh rate isn't necessary, we're just stuck there until we aren't.

That said, if 8000Hz is done badly, it's worse that 1000Hz done well, so that will depend on their implementation.

[Conan]

i saw that mouse and i'm eager to see the quality of implementation.
sort of sceptical.

[DukeDice929]

Nice info!
I think if it gets enough hype, brand manufacturers will implement that feature too. Or modding guys will replace mice guts with 8k polling rate sensor from post.

[AddictFPS]

Very interesting, but even with a good implementation, is needed a powerful CPU to manage the massive jump in Context Switches.

8K is the native, but i'm reading in atompalm.com we can change betwhen profiles to choice also lower polling rate, perfect for test each level ingame, and better fine tune for players without the best CPU, or high end CPU/GPU or even two GPU, but with modern games where the bottleneck is the CPU, to get the best stability, plain polling ingame. With test tool at idle in desktop, sure is easy do it. Ingame is not the same !

For reference, Intel 6600K at 4Ghz, at desktop in idle, 1000Hz, Windows 7 SP1 with SetTimerResolutionService forcing 0.5ms OS granularity, ~8500 CS 1% CPU usage without moving the mouse, moving mouse fast in circle 12.100 1.9%

If the CPU usage with 2K 4K 8K is a plain vertical line, and not parabolic, if 1K increase 1% CPU in quadcore CPU, is 4% of one 4Ghz Skylake core.

1K 4% / 2K 8% / 4K 16% / 8K 32%

And this is without game, with the CPU free of hell CS caused with modern games. Increase polling x8 can cause lower FPS in games with CPU bottleneck, and more unstable polling rate that 1K ?

Very good news, thanks atompalm, finally over 1K

[NDUS]

...

I have an overclocked 8khz mouse and I get strange results regarding CPU usage.
On the desktop, moving the mouse consumes 20-25% of a 5ghz 9700K core. But in a game, moving the mouse consumes only ~5%.
I confirmed this by affinity-forbidding everything from the core responsible for polling, then observing the core activity as I moused around in games. Only 5% utilization at max, but MouseTester confirms it's still running at 8khz.

I guess there is potentially something inefficient in how DWM handles mouse input, while games do it more efficiently.

[Chief Blur Buster]

I'd also add that 1000Hz is not the final frontier either:

This was photographed at 120 Hz refresh rate. Right now, it is worse as refresh rates gets closer to poll rates.

Beat-frequency / harmonic effects become more visible when display Hz and poll Hz gets very close. So 360 Hz monitors show more 1000 Hz limitations than 144 Hz monitors do.

Also, for higher poll rates we need really good high native DPI/CPI. I like that they use 2000dpi (cpi) fully natively because I've long been recommending 1600dpi for a well-optimized gaming mouse.

[AddictFPS]

From my experience testing mouse smoothness with CRT monitor, from desktop pointer to fast paced FPS games, these microstutters of the image occurs because the polling rate is not equal or multiple of 120 FPS 120Hz VSync On, is one asynchronous chain. Is needed one "fix" at a constant rate, the infinite float part is the cause.

125polling / 120FPS = 1.0416* (polling samples per frame)
500 / 120 = 4.16*
1000 / 120 = 8.33*
2000 / 120 = 16.6*

But if this test is done with for example 125 FPS 125Hz VSync On, microstutter disappears. If the mouse is moving at a constant speed, all pointers are at the same distance. Same in-game turns, perfectly smooth.

125 / 125 = 1
250 / 125 = 2
500 / 125 = 4
1000 / 125 = 8
2000 / 125 = 16

Now the chain is Sync, bye bye infinite floats. With more polling, less input lag. With more FPS more toguether pointers for the same mouse speed, completely free of microstutters, at least the microstutter caused by this polling ASync. There are others sources of microstutter like FPS drops, CPU overload.

USB mouse can only work at 125Hz or doubled number from it 250, 500, 1000, etc..., can't set polling at 120, 240, 480, 960. This result in no way get 120FPS/Hz VSync On with pointer perfectly sync

With mouse at 1000Hz, the rule is 1000 / n = entire o finite float multiple of 1000

There are a long list, from 62.5 FPS/Hz up to 1000 FPS/Hz, some examples:

1000 / 1000 = 1
1000 / 960 = 1.0416*
1000 / 800 = 1.25
1000 / 360 = 2.77*
1000 / 250 = 4
1000 / 240 = 4.16*
1000 / 200 = 5
1000 / 165 = 6.06*
1000 / 144 = 6.94*
1000 / 100 = 10
1000 / 75 = 13.3*
1000 / 62.5 = 16
1000 / 60 = 16.6*

Sadly, the current most common LCD frequencies are not Sync, is nedded a custom resolution. Polling increment reduce microstutter distance, but there is always, no matter if up to 2K 4K 8K. CRT or strobed LCD highlights inaccuracies much more, if player is very sensitive to microstutters, the only way i know to remove it is Sync the chain Mouse + GPU + Monitor

Games locked at 60FPS is one double error, motion smoothness limited, by FPS and ASync polling. Developers should take note of this issue. TV also work native at 60 or 120Hz, same issue, is a plague.