Yeah it's a bit weird.. But all 3 monitors have the same very tiny microstutter. 1x genuine gsync module, 2x gsync compatible certified.
It's not bad, I use gsync all the time as you say: gsync+vsync+limiter.
But when I disable all limiters and let the fps sit in the vsync with the nice and massive input lag that comes with it, the tiny microstutters are completely gone and it's 101% silky smooth.
And although I love gsync and there aren't many 21:9 (or similar) monitors with 165 Hz or more, it's a lot less annoying to play on my 165 Hz monitor without any sync.
With gsync, it either disengages, when the game becomes "borderless" due to the volume overlay, a pop-up etc.
Or it disengages, when you alt-tab out and go back in, because the game isn't in true fullscreen anymore without pressing alt+enter etc.
Or you set gsync to be also active for windowed applications, then you start the fun adventure of having spotify, content manager, office etc. to trigger gsync but at 0-10 fps, meaning your mouse cursor will stutter like crazy and all that fun.
So I'm having gsync active for windowed applications and quite a long list in the nvidia control panel with apps set to "Monitor Technology" -> "Fixed Refresh".
WHY is there no setting to disable gsync globally and activate it for specific applications?
I have more profiles to disable it, than applications where I actually use it...
Anyway:
About games not behaving like they should:
There's also a little crux that I can't find a real explanation on, but it's mentioned by blur busters:
When using gsync without vsync, you might get single frames being ready within a shorter time than the maximum refresh rate of the monitor.
Like 100 Hz = 10 ms per frame, you have between 50-80 fps (20 ms to 12.5 ms) and everything is fine. But then one of the frames is ready to be displayed within 8 ms. In this case, you'll get tearing for a single frame.
Vsync holds back that frame until the 10 ms are over and only then displays that frame.
My question: Does a limiter restrict this to happen too? I guess it depends on how the limiter is limiting.
If you restrict the CPU from starting the next frame before 10 ms have past, then it seems impossible to get a frame ready in a shorter period of time.
But if frame 1 takes 15 ms to be done and the next frame starts after 10 ms, but only takes 12 ms to be done, then the second frame is ready after only 8 ms have past.
That's why in-game limiters often show such varying frame times. They often restrict the next frame to start.
So it's all quite a mess