500hz Mouse on 240hz monitor

[mulz]

I heard finalmouse will release a tool at some point where you can upgrade your finalmouse ultralight pro from 500hz to 1000hz. Btw, It seems very interesting mouse!

[lexlazootin]

I heard finalmouse will release a tool at some point where you can upgrade your finalmouse ultralight pro from 500hz to 1000hz. Btw, It seems very interesting mouse!

That is so stupid... They probably want it to seem like a "free upgrade" that they are giving you. Not a big fan of manipulative companies.

It does seem interesting as a mouse, i would like to try it but it does look a little big.

[InBetweenNames]

...

TL;DR: Your mileage will vary with 500 Hz mice on 240 Hz displays. But why do mouse manufacturers stay that low?

Chief, I've gotta say I've been giving your post quite a bit of thought over the last little while and I wanted to throw in a few more pieces to the puzzle. The situation is even less clear in-game.

It is true that, assuming a fixed framerate = refreshrate scenario (240hz monitor with 500hz mouse), every 25 frames will produce an extra poll that will cause a cursor skip, even in a mouse gliding at constant velocity across a surface (perfect tracking assumed). In fact, this is easily observable on your desktop by switching your mouse to a 500hz mode and moving the cursor across a dark background -- the gaps will be very apparent and concerning.

However, in a game, it is rarely the case that the framerate is permanently fixed at the refresh rate -- even if a framerate cap is introduced (and enforced by a mechanism such as yield, sleep, etc), sudden dips can occur as a result of changes occurring within the game itself. This may only manifest for a fraction of a second, but it will still impact the number of input loop iterations per second. Perhaps it might take an extra 2 milliseconds to run the input polling section of the game loop in a single threaded game, for example -- it may be within the ~4.16 millisecond window that a 240hz monitor demands, but these small variances in timing can eventually add up to collect that extra mousepoll even when things appear to be timed right at the high level (i.e. looking at your FPS counter and seeing a locked 240 frames per second isn't enough). Even if you were running a multiple of the refreshrate as the polling rate (for example 960hz USB polling rate with a 240hz monitor, which AFAIK is not possible on Windows and maybe not even at the hardware level), you would still observe these "jumps" with otherwise constant velocity from the mouse (which are multiple poll results added together), and this would be more noticeable in a vsync-on setup (adaptive sync or not), since the entire frame is visible.

Now, in an FPS uncapped scenario, the game loop may be running far in excess of what the monitor is capable of displaying and instead the graphics driver is permitting screen tearing to occur in order to ensure the absolute latest information is present on the display at any given moment. In such a case, I argue that the mouse movement will be smoother relative to a locked framerate and will not display the same "jumping" or "skipping" behavior as observed in the previous paragraph. Why? To start, the game engine loop is running at significantly faster than the monitor refresh rate and part of that loop is polling the mouse information being accumulated by the OS (which is accumulated at the polling rate of the mouse). (*greatly*) Simplified Diagram:

Game engine polling <=> Operating system <=> Mouse

(where <=> indicates bidirectional communication)

The game engine polls the operating system at it's own fluctuating framerate. The operating system itself is polling the USB bus for changes at the specified USB polling rate and accumulating in a buffer the sum total of all changes made. When the game engine polls the operating system, that buffer is reset to zero and the changes are sent to the receiving entity (the game engine), which includes but is not limited to the changes in X, Y, scroll wheel, and the changes in button states.

Hence, the game engine itself is able to receive information from the mouse at a higher rate than the display's refreshrate and is able to respond to those changes accordingly. Since the framerate is uncapped and screen tearing is in place, you'll see these changes happening on your monitor directly, although at possibly different regions of the screen. Yes is is true -- you will have a varying number of mousepolls per game loop iteration -- likely more than the locked framerate approach, but your overall input latency will be lower too (the input buffer is getting read more frequently than it would otherwise and the curve of motion will be more accurately reproduced on screen).

So it seems that no matter what you do, your frames may be receiving a varying number of mousepolls-worth of information on each update of the input loop. You may receive 5 one iteration and 3 the next. If you're locked at a certain framerate, it will help even it out, but still can't entirely eliminate it -- and then you get more latency anyway.

So, I argue the following:

• that this situation is actually happening already, and frequently
• we're already very accustomed to these variances in the number of mousepolls per perceived frame
• more USB polling hz can't eliminate this problem -- but it can help with other things like latency at least, when the number of frames per second is high enough to take advantage of it

And finally, I argue:

• 500hz on a 240hz monitor won't be significantly worse than 1000hz on the same monitor in-game, so long as the framerate is uncapped and you are getting sufficient frames per second to reproduce the motion of the mouse accurately (rough estimate, 300).
• The benefit from increased USB polling rates is only realized when there is sufficient corresponding frames (or input/game loop polls) per second to realize the smoother motion on screen

So how can we get consistent AND low latency input across a fluctuating framerate in game? It almost seems like we need something like Adaptive Sync for input devices...

[holiday]

But why 500hz should not be enough?

On a 60hz Monitor 125hz polling rate was also enough?

125hz/60hz=2.083333

500hz/240hz= 2.083333

so it should be the same

[Slender]

500 good if u dont know how to setup ur bios and system

[andrelip]

There's an additional 0.5ms of average input lag an 1ms of variation in input lag, compared to 1000hz. In game it's probably only noticeable statistically, though you may be able to notice the beat frequency effect on cursor movement. Every 25 refreshes there will be two refreshes with an extra poll worth of motion thrown in, instead of 4 refreshes with the extra poll at 1khz(though half as severe)

Thank you, so from a scale from 1 to 10, how much am I cucking myself for getting 500hz only?

Its mind boggling in 2018 they don't release all mice with 1000hz, high end mice that is.

It's really hard to say.

500 Hz can have extremely good positional accuracy.

The best 500 Hz mice can outperform a common 1000 Hz gaming mouse.

But we've got a problem: Refresh rates converging on mouse poll rates.
It's just not always enough positions-per-second for 240Hz monitors especially when you're playing games that can blast-out more frames than mouse polls per second -- e.g. CS:GO will have some frametimes less than 1/500sec.

What you will need to do is try out all the favourite gaming mice and figure out if the quality of the 500 Hz sufficiently outweighs the lack of 1000 Hz. Also, some 500 Hz mice can be overclocked to 1000 Hz with no problems so in theory you could try doing the same with this mouse, too.

Also, in Windows desktop use, you will notice a very noticeable 10 full-jump mouse-skips per seconds when doing things like dragging around a window (e.g. 10 microstutters per second during VSYNC ON operation) since 500 MOD 240 = 10. 250 is a harmonic frequency of 500, and 250 MOD 240 is 10 beats a second on the harmonic. So for a specific mouse movement speed, if your mouse cursor moves at 10 pixels per refresh cycle during window dragging, you'll see about ten times a second that the window dragging jumps forward a few extra pixels (e.g. 15 or 20 pixels) instead of 10. Which means 10 microstutters a second.

This matters less for VSYNC OFF gaming, but as we know, CS:GO runs at really high framerates. As CS:GO modulates through the harmonic framerates (e.g. 166fps, 250fps, 333fps) of the mouse poll rate, there might be mousefeel variances. If your framerate is consistent, then 500 Hz may not matter much but if your framerate fluctuates all over the place, you don't want harmonic-frequency and beat-frequency effects affecting your aim.

Look at the divisor framerates (harmonics) that you typically fluctuate through. Distant harmonics like fifth-order harmonics (e.g. 100fps with 500Hz mice) will have no noticeable effects, but close harmonics such as second-order harmonics definitely has mousefeel problems (e.g. 250fps with 500Hz mice).

As your VSYNC OFF game varies in framerates, you're fluctuating through those second-order, third-order and fourth-order harmonic framerates when playing CS:GO which can easily achieve 166fps (third-order harmonic of 500Hz) and 250fps (second-order harmonic of 500Hz) and you will have amplified beat-frequency microstutter effects from the mouse poll rate. Worst at beat-frequency (e.g. 498fps @ 500Hz poll, since 500/2 = 250), bad at second-order harmonic (252 fps @ 500 Hz poll), tolerable at third-order harmonic (e.g. 165fps @ 500 Hz poll since 500/3=166.6), etc, etc.

At 10 pixels per frame mouse movement speed, framerate slightly different from a given harmonic:
Beating near full frequency (500), microstutter amplitude is full frame-jump (e.g. 10-10-10-20-10-10-10 pixels)
Beating near second order harmonic (250), microstutter amplitude is half frame-jump (e.g. 10-10-10-15-10-10-10 pixels)
Beating near third order harmonic (166), microstutter amplitude is third frame-jump (e.g. 10-10-10-13-10-10-10 pixels)
etc.

I also saw a similar effect with 1000 Hz mice on my 480 Hz monitor tests. The closer a mousepoll gets to refreshrate, the bigger the mouse microstutters become on the harmonic-effects and beat-frequency effects.

That's why you need overkill mouse Hz. You prefer a 2000 Hz mouse (if it has great positional accuracy) with 240 Hz monitors, ideally. But sensors do degrade in positional accuracy at higher mouse Hz. That's why some eSports mouse manufacturers prefer to do 500 Hz, because of the insanely good positional accuracy. But that doesn't help us 240 Hz monitor users too much! And such mice will be crap for 480 Hz monitors.

So, you gotta keep mouse Hz well above display Hz, especially if you're dealing with precision (e.g. strobing, VSYNC ON) or dealing with massive framerate fluctuation (e.g. VSYNC OFF causing framerates to go towards/away from harmonic frequencies)

I wonder if this is an additional factor why very certain eSports players have reported mousefeel problems with 240Hz monitors too (lag is part of it, but not the whole story -- it's a very complex and multilayered apparently -- with many causes layering upon each other)

TL;DR: Your mileage will vary with 500 Hz mice on 240 Hz displays. But why do mouse manufacturers stay that low?

What if I create a custom resolution with 250hz?
Should I use 250hz at the mouse frequency or it's okay to use 500 or even 1000hz?

[Chief Blur Buster]

What if I create a custom resolution with 250hz?
Should I use 250hz at the mouse frequency or it's okay to use 500 or even 1000hz?

250Hz actually has very good motion dynamics when relatively pollrate-synchronized to gaming mice.

So does 500Hz (which is why the BOE 500Hz display is fairly exciting, as a divisor of 1000Hz, 2000Hz, 4000hz and 8000Hz gaming mice).

Very few 240Hz displays not advertised as overclockable (i.e. 280Hz) can do 250Hz. However, give it a try with reduced porches and see if you can get that far.

Most of the time you need a "280Hz+ overclockable" to get the 250Hz mode.

Pollrate, refreshrate, and framerate mismatches can add mouse jitter. As we push the refresh rate race to retina refresh rates, tiny jitter becomes more visible when persistence-blur becomes low (ultra high frame rates at ultra high Hz, or the use of strobing).

[andrelip]

What if I create a custom resolution with 250hz?
Should I use 250hz at the mouse frequency or it's okay to use 500 or even 1000hz?

250Hz actually has very good motion dynamics when relatively pollrate-synchronized to gaming mice.

So does 500Hz (which is why the BOE 500Hz display is fairly exciting, as a divisor of 1000Hz, 2000Hz, 4000hz and 8000Hz gaming mice).

Very few 240Hz displays not advertised as overclockable (i.e. 280Hz) can do 250Hz. However, give it a try with reduced porches and see if you can get that far.

Most of the time you need a "280Hz+ overclockable" to get the 250Hz mode.

Pollrate, refreshrate, and framerate mismatches can add mouse jitter. As we push the refresh rate race to retina refresh rates, tiny jitter becomes more visible when persistence-blur becomes low (ultra high frame rates at ultra high Hz, or the use of strobing).

I have the 390hz monitor from Acer.

Tried this with vsync at 250hz but didn’t find it any different in game smoothness. In fact I can only notice the difference doing circles in the desktop as it does not generates the skip. Maybe I'm more tolerable to this.

[Chief Blur Buster]

Tried this with vsync at 250hz but didn’t find it any different in game smoothness. In fact I can only notice the difference doing circles in the desktop as it does not generates the skip. Maybe I'm more tolerable to this.

You however, have to use VSYNC ON or RTSS Scanline Sync and/or a microsecond-accurate framerate capper to notice (e.g. RTSS capping instead of in-game capping).

VSYNC OFF combined with less accurate in-game framerate caps will not produce the necessary benefits that you see in Desktop.

Windows Desktop is VSYNC ON, so you will only see the major jitterless improvements when using VSYNC ON or a technology that simulates VSYNC ON (with lower lag)

There's a lot of competing frequencies to jitter against each other:

- Display Hz
- Mouse Hz
- Frame rate
- Server tick rate
- Other behaviours (e.g. animation timers)
- Etc

I wish server tick rate (64, 128) was more in sync with mouse (125 multiples) and refresh rates (120, 144 Hz), but what can ya do...

A synchronous game would be heaven, IMHO. But Internet jitter will always screw around with it, so games can only do their best.

Some esports players have found that syncing the frequencies only works well if you're forcing ultra-accurate sync (e.g. perfect VSYNC ON movement). Right now if you want a ultralowlag VSYNC, use RTSS-capped GSYNC, or if fixed Hz, use RTSS Scanline Sync and Special-K Latent Sync with games that permanently run framerate=Hz -- definitely shows pollrate-vs-framerate-vs-refreshrate sync benefits.

[Boop]

So does 500Hz (which is why the BOE 500Hz display is fairly exciting, as a divisor of 1000Hz, 2000Hz, 4000hz and 8000Hz gaming mice).

If I'm using one of the new BOE/ASUS 500Hz displays, I no longer need to upgrade from a 1000Hz polling mouse to mitigate jitter problems? Awesome!