I have the new Razer 8000 Hz prototype gaming mouse on my desk.

[lyrill]

What actually matters is the distribution of time between two consecutive reports.

The one second average doesn't matter, the only utility that has is for marketing to put on the box. It's like advertising the reliability of a car based on the number of times it was driven last year. It's a nice big number, but what the buyer actually cares about is how many times the car broke down, and how big a problem it was each time.

Yup, you are absolutely spot on, 125us reporting interval is the primary metric. "Hz" is a pretty meaningless derivative number, but that's what everyone (even most enthusiasts) and their dogs have been using in their discussions every day.

I've been trying to relay the same message as you, but trying to convince people that they've been using the Hz-number all wrong is not something that can be done overnight. Hell, I tried explaining the same thing in this very thread 4 months ago and yet the discussion drifts to polling rate tools that report "Hz" numbers, and those don't capture data fast enough, painting the incorrect picture of the performance - which is why we had to make our internal tool public.

The "Hz" number is very misleading because people use it as a primary metric when it's actually not. The primary metric is the polling interval. You get 0.125ms polling intervals regardless of how fast or slow your mouse is moving. In other words, the total reports you generate in 1 second doesn't dictate the responsiveness of the mouse, it's the polling interval.

As a simplified example, let's say you only move your mouse 4000 pixels in 1 second - that would amount to "only" 4000 reports in one second, which any polling rate testing software will read as "4000Hz". It doesn't mean that your mouse is suddenly less responsive - your polling interval was still 0.125ms; just that some of the reports were "null" because you didn't generate 1-pixel equivalent of motion in the last tick.

Using so called "static" polling rate - the "no report" ticks will still be polled as "+0" and count as a poll in a polling rate software, giving you a higher "Hz" number, but it doesn't actually translate to anything actionable for your PC. The cursor only moves when the PC gets a non-0 count.

what's the fps on 3399? if i read it somewhere since 2019, I don't remember it now(haven't re-read old posts obviously because most people don't even read newer ones) posts but I certainly do now remember about all that being read previously. it certainly is higher than 8k even on the lowest stage, yes? to accomendate potential high dpi users?

[lyrill]

So, just my perspective regarding some of these tests/metrics regarding the misleading "avg polling rate".

If by design the mouse only sends movement data as necessary up to the maximum rate of 8kHz, why are people concerned that not moving the mouse enough results in a non-constant 8kHz rate of data packets?

That's just the way it currently works.
You should be happy that what you're getting now is a higher maximum report / "sample" rate, effectively mitigating this old bottleneck.

The bottom line is that there are clear benefits to be had (that I won't regurgitate here) by using 8kHz even in the lower CPI range.

How much benefit you will see depends on your "sensitivity" (reflexes, dexterity, etc.), your system specs, the game(s) you play, and how well-optimized your entire setup is.

However, for various reasons many have recommended using higher CPI values and lower in-game sensitivity.
Unfortunately, some poorly-coded games like Apex Legends force you to use low CPI (e.g. opening inventory with a high CPI = can't manage shit + cursor off-screen alt+tab death).

I gotta correct myself and you here a bit I think it actually depend on pixel per second moved, so dps/pps, not dpi or edpi or whatever. since we are talking effective reports per second or the Razer_theFiend disapproved "hz" xd.

I still don't know why Mouse Movement Recorder goes above 8k "reads" frequently, what's up with that?

[lyrill]

Is it still optimal to connect the mouse to a USB port that is located on the monitor?

Quick answer: I justed tested, it is capped to 1000 Hz if plugged in the monitor. If plugged in the PC case, it is going up to 8000 Hz as intended.

One of those reflex monitors? They only have a full-speed USB port (mouse is high-speed).

This is also why they aren't fast enough to report the click latency on this mouse.

Edit : Saw your other post just now - that should answer the question.

actually did you mean that literally every single 360hz monitor, that is, those who don't have reflex module can't do such a "monitor/latency reduc" thing anyways, and those who do, force you to use passthrough usb, while somehow it guarantee lowest latency they didn't know you guys would release 8khz nor this early (relatively). so it was basically not on the map for them so they didn't accommodate this? they will for 400hz+ then? because 8khz is not just (or not even mainly) latency reduc, because nvidia reflex works on scale of like 5-10ms differences in terms of advantages over various other/different settings, but we are talking 0.875ms here, relatively small.

if so then I'm assuming that you would basically only benefit from 360hz as a 8khz mouse (that is, viper only now) user, on everything independent of the reflex stuff. the 360hz alone is still a thing superior over sub 360. I just noticed the obvious price difference of qn/qnr so no point in buying qnr at least. The alienware one also has reflex I believe, but it's cheaper, same price as qn. but asus has hdr..but acer has hdr too and is even much cheaper

in any case it seems better to just wait for 8khz hs compatibility on 480hz+......

[Inco^]

Is it still optimal to connect the mouse to a USB port that is located on the monitor?

Quick answer: I justed tested, it is capped to 1000 Hz if plugged in the monitor. If plugged in the PC case, it is going up to 8000 Hz as intended.

One of those reflex monitors? They only have a full-speed USB port (mouse is high-speed).

This is also why they aren't fast enough to report the click latency on this mouse.

Edit : Saw your other post just now - that should answer the question.

damn thx, was considering the qnr......might have to consider other options instead like alienware that also came out within 1-2 months. (manufactured 11th month 2020)

unless u have estimation about when 480+hz monitors come out?

I have the PG259QN monitor, not the PG259QNR.

--

I can't wait for 480 Hz monitors.

[howiec]

I gotta correct myself and you here a bit I think it actually depend on pixel per second moved, so dps/pps, not dpi or edpi or whatever. since we are talking effective reports per second or the Razer_theFiend disapproved "hz" xd.

I still don't know why Mouse Movement Recorder goes above 8k "reads" frequently, what's up with that?

When I said "movement data", that's based on the sensor (CCD?) detecting movement which is based on it detecting changes in pixels/images. I don't believe this contradicts what Razer has stated. A higher CPI obviously means more counts/data reported for the same amount of physical distance moved...

As I said, the 8kHz rate is the maximum report rate.

Whatever the software is that you're referring to, without looking at the source code, I can't say why it reports >8kHz, however, I'm going to guess that it's simply not accurate (especially for those >8kHz data points outside USB tolerance ratings)... and/or perhaps something going on with the Windows non-RTOS with all its imperfections.

[lyrill]

I gotta correct myself and you here a bit I think it actually depend on pixel per second moved, so dps/pps, not dpi or edpi or whatever. since we are talking effective reports per second or the Razer_theFiend disapproved "hz" xd.

I still don't know why Mouse Movement Recorder goes above 8k "reads" frequently, what's up with that?

When I said "movement data", that's based on the sensor (CCD?) detecting movement which is based on it detecting changes in pixels/images. I don't believe this contradicts what Razer has stated. A higher CPI obviously means more counts/data reported for the same amount of physical distance moved...

As I said, the 8kHz rate is the maximum report rate.

Whatever the software is that you're referring to, without looking at the source code, I can't say why it reports >8kHz, however, I'm going to guess that it's simply not accurate (especially for those >8kHz data points outside USB tolerance ratings)... and/or perhaps something going on with the Windows non-RTOS with all its imperfections.

yes I tried 20k dpi later it seems to easily reach 7900 on Razer tool. so yeah maybe something isn't time/speed related.

[Chief Blur Buster]

yes I tried 20k dpi later it seems to easily reach 7900 on Razer tool. so yeah maybe something isn't time/speed related.

Did you configure Windows to this:



I needed to do this to make the pointer speed correctly relative to DPI. At 8000Hz, this setting really screws around with DPI. Games that use rawinput will bypass this, but Windows-GUI-based mouse benchmarking utilities is piped through the Microsoft meatgrinder.

[Chief Blur Buster]

Whatever the software is that you're referring to, without looking at the source code, I can't say why it reports >8kHz, however, I'm going to guess that it's simply not accurate (especially for those >8kHz data points outside USB tolerance ratings)... and/or perhaps something going on with the Windows non-RTOS with all its imperfections.

Definitely Windows non-RTOS.

1. USB is a packetized system with USB jitter that can also push some samples to adjacent seconds, meaning one second may have more polls and the next second may have fewer polls. Some ports on the motherboard will have WAY more USB jitter than others (EXAMPLE) so you should play USB roulette until you plug into your lowest-jitter USB port.

2. The clock used to measure the second may not be the most accurate second, especially when running in some programming languages, since processing time may jitter the benchmarks.

3. Microsoft Windows non-rawinput APIs go through a hell of a lot processing, especially if you use "Enhance Pointer Precision"

4. Memory management events (e.g. garbage collect events in the programming language used to program the mousepoll counter -- I've seen it fudge poll by 10%).

All combined, it's normal to see poll counters vary by about 5-10% because of Windows non-RTOS weak links. Not the mouse' fault.

With excellent benchmark software, running in FSE/rawinput, raised priority, microsecond timers like RTDSC/QueryPerformanceCounter, non-garbagecollected languages, and cherrypicked USB port with all other USB devices unplugged (or a PCIe USB card just for the mouse), the pollcounters can become accurate to 0.1%. However, most pollcounters aren't doing such programming practices.

[lyrill]

yes I tried 20k dpi later it seems to easily reach 7900 on Razer tool. so yeah maybe something isn't time/speed related.

Did you configure Windows to this:



I needed to do this to make the pointer speed correctly relative to DPI. At 8000Hz, this setting really screws around with DPI. Games that use rawinput will bypass this, but Windows-GUI-based mouse benchmarking utilities is piped through the Microsoft meatgrinder.

i was referring to using a workable desktop/game menu/'whatever in game that doesn't use in game sens'-- edpi, which was/is 3/11 for 20k.

with the standard 6/11 maxing wrist swiping gets like 7990 instead of 7900

[lyrill]

Whatever the software is that you're referring to, without looking at the source code, I can't say why it reports >8kHz, however, I'm going to guess that it's simply not accurate (especially for those >8kHz data points outside USB tolerance ratings)... and/or perhaps something going on with the Windows non-RTOS with all its imperfections.

Definitely Windows non-RTOS.

1. USB is a packetized system with USB jitter that can also push some samples to adjacent seconds, meaning one second may have more polls and the next second may have fewer polls. Some ports on the motherboard will have WAY more USB jitter than others (EXAMPLE) so you should play USB roulette until you plug into your lowest-jitter USB port.

2. The clock used to measure the second may not be the most accurate second, especially when running in some programming languages, since processing time may jitter the benchmarks.

3. Microsoft Windows non-rawinput APIs go through a hell of a lot processing, especially if you use "Enhance Pointer Precision"

4. Memory management events (e.g. garbage collect events in the programming language used to program the mousepoll counter -- I've seen it fudge poll by 10%).

All combined, it's normal to see poll counters vary by about 5-10% because of Windows non-RTOS weak links. Not the mouse' fault.

With excellent benchmark software, running in FSE/rawinput, raised priority, microsecond timers like RTDSC/QueryPerformanceCounter, non-garbagecollected languages, and cherrypicked USB port with all other USB devices unplugged (or a PCIe USB card just for the mouse), the pollcounters can become accurate to 0.1%. However, most pollcounters aren't doing such programming practices.

i put real time and high io priority on the thing and still notice 8k+, even a 10k read, but the adjacent number is a 6k, so I guess that evens out lol.