Blur Busters Forums

I've noticed this in several games, that during a small frametime spike, usually no more than 4-5ms, I notice it much more than I would expect.

SPECS:
GPU: RTX 4070
CPU: i7-13700k
RAM: DDR5 6000mhz
MOBO: Asus PRIME Z790-P WIFI

My monitor is an Alienware AW2724DM and is G-SYNC compatible. I set the monitor refresh rate to 165hz for desktop usage, but I use NVCP and RTSS to cap games to 144 or lower. I have a second monitor, an Acer xv272u vbmiiprx, which I have set to 165hz as well.
For my NVCP settings, I have G-SYNC enabled only on my primary AW2724DM, with VSYNC set to ON in the global profile.

For the frametime spikes, some games I cap to 90fps with RTSS, for a solid 11.11ms. But occasionally, there will be a small spike to around 15-16ms, which becomes a noticeable microstutter.

Even when playing games at 60fps, spikes are less noticeable than at 144, but still noticeable. However, when testing I found that if I disable G-SYNC and use in game vsync, I don't notice the stutters at all.

An example of this is in Mount and Blade Warband, when entering towns there will sometimes be a few 25ms spikes. With g-sync on, they are noticeable microstutters, but with g-sync off and the game's built in v-sync on, I notice no drops.

Is V-SYNC buffering frames which prevents the stutter, whereas G-SYNC just waits for the frame to be completed, showing the stutter? I would obviously prefer to use G-SYNC as the convenience and smoothness just aren't there with v-sync, but is this expected behavior, or have I configured something wrong?

Disconnect your second monitor and see if that fixes it.

Unfortunately, still stuttering with the second monitor disconnected.

brogers wrote: ↑

19 Feb 2025, 19:11

Is V-SYNC buffering frames which prevents the stutter, whereas G-SYNC just waits for the frame to be completed, showing the stutter?

Assuming the framerate is limited by V-SYNC, then yes, it can mask certain levels of stutter because it throttles the framerate to the fixed refresh rate, whereas G-SYNC will reflect the actual moment-to-moment frametime performance as-is.

And while G-SYNC can't cause frametime spikes, it can (but won't always) elongate them (especially at lower physical refresh rates due to the slower scanout speeds), since it has to adhere strictly to the scanout to prevent tearing.

brogers wrote: ↑

19 Feb 2025, 19:11

I would obviously prefer to use G-SYNC as the convenience and smoothness just aren't there with v-sync, but is this expected behavior, or have I configured something wrong?

G-SYNC on + NVCP V-SYNC on + FPS at least 3 frames within the current physical refresh rate; if that's what you're using, there nothing wrong with your configuration.

jorimt wrote: ↑

20 Feb 2025, 21:43

And while G-SYNC can't cause frametime spikes, it can (but won't always) elongate them (especially at lower physical refresh rates due to the slower scanout speeds), since it has to adhere strictly to the scanout to prevent tearing.

That makes sense. I mostly notice this stuff in games I played on my old pc at 60 fps and never seemed to notice spikes. I guess it's just that coupled with having a higher sensitivity to frametimes now that I'm used to 144

brogers wrote: ↑

21 Feb 2025, 11:31

I guess it's just that coupled with having a higher sensitivity to frametimes now that I'm used to 144

The higher the average frame + refresh rate, the more obvious any deviations will be, for sure.

One thing that I have noticed that I forgot to mention, is the Hz of the monitor seems to be erratic during these spikes.
My monitor doesn't have an OSD hz display, so I use RTSS using the internal HAL reading. I feel like maybe the monitor is going to a lower refresh rate than needed during the spikes.

Is the internal HAL refresh rate reading known to be accurate, or should I take it with a grain of salt?

brogers wrote: ↑

21 Feb 2025, 14:06

Is the internal HAL refresh rate reading known to be accurate, or should I take it with a grain of salt?

Grain of salt. I believe it also reflects LFC multiples in the readout. That, and the Hz reading are bound be erratic during frametime spikes since the framerate is dropping to an effective 0 in each instance, and the readout's reporting isn't instantaneous or in real-time either (I think the default refresh period for statistics in RTSS is 0.5 seconds).

Gotcha. The only other thing that bothers me with G-SYNC is that in certain games, it sometimes seems to change the refresh rate when there are no stutters. Although, this has only happened twice.

In Like A Dragon Infinite Wealth, when I use the ingame limiter to 60, it will hitch upon exiting menus/conversations with a frametime spike. If I cap with RTSS, there is no frametime spike, but oddly G-SYNC lowers the HZ as if there was.

I had a similar issue in Dragon Quest Builders, where viewing the map would show a flat frametime graph with no spikes, but G-SYNC would stutter. I was able to solve this one by changing the RTSS frame limiter to "back-edge sync" instead of "async"

Not sure if these are just rare cases of game specific bugs, or if RTSS's frame limiter could somehow be interfering with G-SYNC, albeit only in these specific games.

brogers wrote: ↑

21 Feb 2025, 16:33

Gotcha. The only other thing that bothers me with G-SYNC is that in certain games, it sometimes seems to change the refresh rate when there are no stutters. Although, this has only happened twice.

In Like A Dragon Infinite Wealth, when I use the ingame limiter to 60, it will hitch upon exiting menus/conversations with a frametime spike. If I cap with RTSS, there is no frametime spike, but oddly G-SYNC lowers the HZ as if there was.

You can also try the Nvidia limiter. The most accurate limiter I've used so far is the "Normal" limiter in SpecialK. Even the normally very erratic VRR Hz indicator in my monitor's OSD becomes very stable with that.