Monitors Native Asynchronous Frequency's Plague

Advanced display talk, display hackers, advanced game programmers, scientists, display researchers, display manufacturers, vision researchers & Advanced Display Articles on Blur Busters. The masters on Blur Busters.
Post Reply
User avatar
AddictFPS
Posts: 314
Joined: 15 Jan 2020, 14:13

Monitors Native Asynchronous Frequency's Plague

Post by AddictFPS » 01 Feb 2020, 07:07

Like all know, RefreshRates are calculated in Refresh/Second, but most native RefreshRates can't be calculated during one second at exact time steps :shock: Image there are a plague of infinite decimals Image and obviously sound like is not a good idea use Asynchronous Frequency's if want UFO perfect smooth movements Image

* = infinite decimals = 16.666666666666666666666666666666666666666.............. :!:

60Hz = 1/60s = 16.6* ms
75Hz = 13.3*
85Hz = 11.7647058823529411* Image
120Hz = 8.3*
144Hz = 6.94*
165Hz = 6.06*
240Hz = 4.16*

When synchronize GPU FPS with Monitor Hz (Vsync, Adaptive Sync, GSync), and can maintain the FPS steady "rock solid" at Hz number for best smooth movement, with the above list, unfortunately the GPU can't render FPS at exact frametimes.

240Hz = 4.16* ms Refresh + 4.16* ms frametime

Hardware can't calculate a number with infinite decimals, infinite is a mathematical representation, hardware never can do it, is aproximately. Moreover, i think is a waste of resources compared to easy and fast exact frequency process, less time process = less InputLag, less energy consuption, less heat.

Examples of exact frequencies:

100Hz = 1/100s = 10 ms
200Hz = 20 ms

But only a few monitors use these two natively. People need to make Custom Resolution in order to use them.

Monitor can process exact 10ms refresh, and GPU exact 10ms frametimes = Perfect Sync

Next information is not in BlurBusters Mouse Guide, but can be usefull.

To add Sync in games using mouse, take in account that best current Mouse USB Polling Rate is 1000 Hz for low InputLag, so make sure this 1000 polling rate is exact entire multiple of your current monitor frequency's, or you can't perfect Sync Mouse + GPU + Monitor :!: and allways there are a bit of micro-stuttering.

These micro-stuttering can be see in BlurBusters Mouse Guide, 120Hz monitor is Asynchronous with all mouse polling rates tested (125-500-1000), 1000 Hz is the best, but there are still a bit of micro-stuttering.

Image

(1000 / 120 = 8.3*) (500 / 120 = 4.16*) (125 / 120 = 1,0416*) Is aSync, no entire numbers = impossible avoid micro-stuttering.

But if you make a Custom Resolution with 125Hz, problem solved :mrgreen:

(1000 / 125 = 8) (500 / 125 = 4) (125 / 125 = 1) Is Sync, in all three test no micro-stuttering ;)

Divide 1000 ms by entire numbers up to 20, stick with those that result in entire numbers, and you get the Micro-Stuttering Free Frequency's List to use with steady 1000Hz Mouse Polling Rate Image

/1 = 1000 Hz
/2 = 500
/4 = 250
/5 = 200
/8 = 125
/10 = 100
/16 = 62.5 (not entire, but is limited decimal, can be exactly processed by hardware)
/20 = 50

Image

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Monitors Native Asynchronous Frequency's Plague

Post by Chief Blur Buster » 05 Feb 2020, 13:28

Low-Hz poll rates like 125 Hz and low refresh rates 60 Hz, made harmonics / beat frequency effects much more visible. Today, at 1000Hz mouse, it's much less.

Also, mouse microstutter visibility changes when you change sync technologies (VSYNC ON vs VSYNC OFF vs GSYNC etc). When using variable refresh rate, most of mouse microstutter effectively disappears because the mouse stutter is de-stuttered by a VRR display to an extent. Not perfectly (as it's not always a gametime:photontime sync).

Sheer refresh rates combined with sheer frame rates provide essentially a motion anti-aliasing effect -- and makes divisible frequencies less necessary.

Long-term, ultra high mouse poll rates (>1000Hz) will make stutter effects far less visible at lower Hz.

In many situations what you say is not the weak link -- it's dirty mouse feet or a low-DPI setting or mouse pad adding more microstutter than any of this. But once you eliminate all other weak links, the harmonics/beat-frequency stuff becomes far more visible, especially with motion blur reduction modes (ULMB, LightBoost, DyAc, etc) that works better locked to Hz (fps=Hz). In this situation, non-divisibles show up easily as visible microstutter even at high Hz. But on the other hand if you're doing 240Hz G-SYNC, most of these tiny microstutters is effective filtered-out by the VRR technology, with good game engines, especially if the sensor is pretty accurate in its polls.
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!

User avatar
AddictFPS
Posts: 314
Joined: 15 Jan 2020, 14:13

Re: Monitors Native Asynchronous Frequency's Plague

Post by AddictFPS » 06 Feb 2020, 03:57

Chief Blur Buster wrote:
05 Feb 2020, 13:28
When using variable refresh rate, most of mouse microstutter effectively disappears because the mouse stutter is de-stuttered by a VRR display to an extent. Not perfectly (as it's not always a gametime:photontime sync).

Sheer refresh rates combined with sheer frame rates provide essentially a motion anti-aliasing effect -- and makes divisible frequencies less necessary.

...if you're doing 240Hz G-SYNC, most of these tiny microstutters is effective filtered-out by the VRR technology, with good game engines, especially if the sensor is pretty accurate in its polls.
I think VRR only sync Frametime-Refreshrate, and disappears all GPU-Monitor related sync issues, but can't avoid micro-stuttering caused by aSync polling by itself.

The sync Polling-Frametime, as you said, is API/GameEngine level. Engine will try to soften 1000Hz polling at 120FPS/Hz, but never perfect sync due to infinite decimals 8.3* , so allways there are a small residual micro-stuttering. With CRT or good strobed LCD can be noted, with non-strobed LCD this small micro-stuttering is very hard to see, is MotionBlur disguised.

Increasing mouse polling beyond 1000Hz (2K-4K-8K USB3.0 specs), and increasing game engine decimals to process polling (long floating point), result in more aproximate sync with 120FPS/Hz, but never perfect (but enought sync quality for the vast majority of players of course), and CPU usage "context switch" would be greatly increased.

So, i think is better solution just change monitor to 125Hz, and make things more easy in all levels with exact 8ms steps. And if increasing polling beyond 1000 is especifically for reduce input-lag, not to try hide the aSync with brute force.

To test/confirm that VRR not fix aSync polling by itself, let's exaggerate low polling to make micro-stuttering visible even in LCD non-strobed. With VRR monitor, set framerate cap 120 with "Nvidia driver" or "RTSS", mouse polling set 125Hz, and move mouse pointer in 3D accelerated current desktop operating systems, with all App's and games closed to avoid interferences. The pointer don't move smooth and there are input-lag. Now set cap 125, the pointer is perfect smooth but there are input-lag. Now set polling 1000, pointer is smooth and low input-lag. Occurs the same in FPS game properly configured.

The most used PC LCD monitor frequency is fixed 60Hz, aSync by itself at infinite decimals steps/s , and aSync with all mouse polling rates (125-250-500-1000), so the vast majority of PC users are being pushed towards this default pointer asynchrony, most of them with cheap 125Hz mouses. Only the ones that increase polling can smooth the pointer, and only the ones that set a proper frequency can perfect sync the pointer. I guess someone should do something about, this punishment must end :lol:

I propose that future monitors include 125Hz frequency stored in EDID, and can be selectable in the list of availables in the OS resolution/frequency settings, and marked (recommended) for Operating System Desktop for perfect Sync Mouse+GPU+Monitor, in the same way the native resolution is marked as (native) for perfect sharpness.

To fix the problem with future 60Hz monitors, one EDID resolution with 62.5Hz solve the problem, pointer micro-stuttering disappears with all mouse polling rates, i've tested it and works perfect, these 62.5Hz should be a "must be" in all new low Hz monitors frequencies list.
Last edited by AddictFPS on 07 Feb 2020, 07:41, edited 2 times in total.

User avatar
RealNC
Site Admin
Posts: 3740
Joined: 24 Dec 2013, 18:32
Contact:

Re: Monitors Native Asynchronous Frequency's Plague

Post by RealNC » 06 Feb 2020, 17:15

AddictFPS wrote:
01 Feb 2020, 07:07
Like all know, RefreshRates are calculated in Refresh/Second, but most native RefreshRates can't be calculated during one second at exact time steps :shock: Image there are a plague of infinite decimals Image and obviously sound like is not a good idea use Asynchronous Frequency's if want UFO perfect smooth movements Image

* = infinite decimals = 16.666666666666666666666666666666666666666.............. :!:
That's not how it actually works. These are idealized numbers. The hardware will use discreet ("quantized") values based on the pixel clock. Each pixel clock tick is the smallest unit of accuracy. However, this accuracy is much higher than anything software running on a non-realtime, multitasking OS (like Windows, macOS and Linux) is able to do. There will always be jitter.

So 125Hz vs 120 vs 144 vs anything else does not matter at all. 1000/125 is just as accurate as 1000/120.
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

User avatar
AddictFPS
Posts: 314
Joined: 15 Jan 2020, 14:13

Re: Monitors Native Asynchronous Frequency's Plague

Post by AddictFPS » 07 Feb 2020, 06:30

Thx for info,

but MHz PixelClock precision is not a inpediment to perfect Sync Mouse+GPU+Monitor, if the proper config is set at all steps in x64 OS with BIOS level HPET 64bits, only need set resolutions with PixelClock exact multiple of default USB mouse polling rate 125Hz.

125Hz with 600MHz Sync at exact 1:4,800,000 rate
250Hz 2,400,000
500Hz 1,200,000
1000Hz 600,000

With Custom Resolution Utility v1.4.2 Detailed Resol. Auto LCD Native 1920x1080@240 result:

VFreq: 240.000 Hz
HFreq: 270.000 KHz
PClock: 594.00 MHz

CRU PClock not show more decimals to confirm if is exact multiple of 125Hz (0.000125), how can be calculated seeing all timings ? If is exact 594 MHz / 0.000125 = Perfect Sync at 1:4,752,000 rate.

But in GameEngine polling rate is sinchronized with frametime, in the render stage, to indicate where is the current crosshair position, and this is what players can see in-game, if a constant horizontal speed mouse movement, is translated to a constant view turn, without any micro-stuttering.

So with VRR Sync, Frametime = VFrequency, and this is what players see in-game. If VFreq is not entire multiple of polling rate, there are micro-stuttering. So need change this 240 Hz to 200 or 250 if monitor can support this small overclock, and problem solved.

Detailed Resol. Auto LCD Native 1920x1080@200 result:

VFreq: 200.000 Hz
HFreq: 225.000 KHz
PClock: 495.00 MHz

Detailed Resol. Auto LCD Native 1920x1080@250 result:

VFreq: 250.000 Hz
HFreq: 281.250 KHz
PClock: 618.75 MHz

With these two new frequencies, both PixelClock and VFreq are exact multiple of 125Hz polling, and also 250, 500, 1000, and future pollings, that USB standard stablished that always is x2 over the last polling.

And with each upper polling stage, appears new frequencies 100% free micro-stuttering, so 2000Hz add to the above list 80 and 400 ;)

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Monitors Native Asynchronous Frequency's Plague

Post by Chief Blur Buster » 09 Feb 2020, 16:19

Another consideration.

The CPU clock and GPU clock won't be in perfect lockstep, so there'll be microscopic slewing between the two. That can also cause a slow sawtooth latency-slew effect as the refreshtimes (controlled by GPU clock) beat-frequencies against poll times (often controlled by CPU clock). Sometimes frame rate caps on fixed-Hz have that sawtooth lag effect.

Image
(GeDoSaTo, beat-frequency sawtooth effect from slew between VSYNC ON refresh rate combined with framerate cap)

One method of solving this is to run a renderer & VRR monitor synchronized to the poll instead. It would be neaat to have frame rate cap software that can monitor the polls & synchronize frame rate to the poll timings, and then the rest of the software chain (if programmed properly) hopefully would follow.

In the real world, you have 3 or 4 frequencies to try to synchronize simultaneously, not two. Like frame rate, refresh rate, and poll rate. VRR refresh rate solves the sync to frame rate, and in theory both can sync to the poll rate.

Whac-a-mole those millisecond microstutters are not easy. Single-millisecond microstutters are human-visible in low-persistence virtual reality in my experience, and that's where it's much more important to keep gametime:photontime sync to the sub-millisecond level (while keeping latency fixed and non-varying as possible). Smoothing algorithms become critically necessary for sensor tracking and head tracking. Fixing stutter at 60fps at 60Hz is easy in comparison.
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!

Stitch7
Posts: 86
Joined: 27 Mar 2019, 08:26

Re: Monitors Native Asynchronous Frequency's Plague

Post by Stitch7 » 13 Feb 2020, 14:37

So is it better to run 200hz / 250hz instead of 240?
(Would it even work if one overclocked to say 253hz and used VRR with a 250fps cap?)

User avatar
AddictFPS
Posts: 314
Joined: 15 Jan 2020, 14:13

Re: Monitors Native Asynchronous Frequency's Plague

Post by AddictFPS » 13 Feb 2020, 15:57

With CRU LCD native timings FHD@253Hz cap exact 250 Hz, the micro-stuttering due to polling-frametime sync solved, 4:1 ratio entire divisor. Also PixelClock 626.18 MHz is multiple of 1000Hz polling, if this can help in some way.

Compare this config Vs default 240Hz, and say if you note difference. Unfortunately motion blur will be there preventing you from seeing clearly :(

When FPS drop from 250, Polling-Frametime Async again, so maintain rock solid 250 FPS, and exact framerate cap.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Monitors Native Asynchronous Frequency's Plague

Post by Chief Blur Buster » 13 Feb 2020, 18:55

Stitch7 wrote:
13 Feb 2020, 14:37
So is it better to run 200hz / 250hz instead of 240?
(Would it even work if one overclocked to say 253hz and used VRR with a 250fps cap?)
Depends. Understand why you cap. And caps are different for different sync technologies.

- Capping to Prioritize For Latency
- Capping to Prioritize For Smoothness
~~~ Do Not Blindly Cap Without Knowing Your Priorities ~~~

Rheoretical questions (to ask oneself): Are you more worried about absolute lag or more worried about lag consistency (less volatile lag)? Or more worried about smoothness? Sometimes you can only choose one or the other with certain sync technologies. Read the above links to understand capping better.

That said, with some sync technologies (VSYNC OFF), capping far away from Hz can create blended regular stutter (tiny jitteriness at dozens of tiny microstutters per second) that looks better than cyclic stutter (like 2 or 3 big stutters per second). That's why VSYNC OFF 300fps CS:GO at 144Hz looks reasonably good for many people. It's an old low-lag favourite, even if not as smooth as VRR or VSYNC ON.

Massive overkill frame rates well above refresh rate, has several advantages too. But it's not ideal for smoothness-priority situations if you're ultra-sensitive to stutters or tearing.

Right tool for the right job. A hammer is not a screwdriver. Make sure you understand the capping tools in your toolbox.
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!

Post Reply