Anyone measured frametime variance w/ Gsync Ultimate?

[Noel]

I'm thinking about picking up this a Gsync Ultimate Certified Alienware display but before going there would love to know what kind of frametime variance happens when CPU and GPU aren't overloaded.  If you have a true Gsync display if you could do a test flight and let me know what you're seeing for VARIANCE in frametime.  Let me know what vertical refresh rate you're at as well as what the range of frametime is for the first 5 or 10 minutes of a flight.  I use a Vsync method that delivers frametimes that just hardly change at all, they are super stable and consistent at exactly what they should be and will fluctuate by 0.1ms only pretty much, again provided the CPU/GPU aren't overtaxed affecting this.  If you do this test please be sure your simulator is running unlimited, unlocked, and you don't have any other form of frame lock or vsync/freesync active while testing.

Here is a video to this ultra-stable frametime using this method.  Look at the OSD in the bottom center, D3D12 value (33.3 is the exact target frametime at 30fps).  Since it was recorded in HD while flying it may suffer from some stutter but there were no stutters in the actual flight.  This method delivers the smoothest animation possible at this frame rate and is remarkably smooth and fluid, perfect in a word.  It unfortunately comes w/ a migrating "tear line" of mild horizontal linear line that can be visible when you are panning horizontally.

https://www.youtube.com/watch?v=znEgRDLD8EE

Thanks in advance!

[Cpt_Piett]

18 hours ago, Noel said:

If you do this test please be sure your simulator is running unlimited, unlocked, and you don't have any other form of frame lock or vsync/freesync active while testing.

I'll make a video with G-Sync. Hopefully I understand your criteria. I've got a 77" OLED running at 3840x2160 and 120Hz (native resolution and refresh rate). I've also set RTSS to limit fps at 119 (so as not to exceed the monitor Hz) using front edge sync. 

Is there anything else I should be aware of before making the video?

[Noel]

Can you dial back your refresh to 60Hz?  Then set RTSS to 30.  I may look horrible on that size screen but it would be great to see CapFrameX's analysis of frametime variability w/ Gsync.  

[Cpt_Piett]

3 minutes ago, Noel said:

Can you dial back your refresh to 60Hz?  Then set RTSS to 30.  I may look horrible on that size screen but it would be great to see CapFrameX's analysis of frametime variability w/ Gsync.  

Ok I'll do that. I'll use a saved flight in the PMDG -700 I've been using earlier today for testing purposes. Takeoff from EGBB. I'll keep the PMDG in community folder, nothing else. To make sure nothing is putting a load on the main thread. 

Anything else to keep in mind?

[Noel]

18 minutes ago, Cpt_Piett said:

Ok I'll do that. I'll use a saved flight in the PMDG -700 I've been using earlier today for testing purposes. Takeoff from EGBB. I'll keep the PMDG in community folder, nothing else. To make sure nothing is putting a load on the main thread. 

Anything else to keep in mind?

Wow fabulous thanks for that!  I really appreciate it!

How about reducing T-LOD to 120 or so.  I stopped when I had a significant stutter event just a mile or two from touchdown I forget from the capture below.  I am not concerned about the issue of stutters upon arrival I know I can get a few but fortunately it's still mostly just a very few, presumably because everything is running clean and I have T-LOD low enough.  Flew out of FT's KLAX this morning and really only had one or two brief hiccoughs.  Just another 30% more CPU power is all I ask and should get even w/ 13900K.

Last mile or two may have had a stutter so I just stopped the capture right before touchdown so that is what this capture covers:  25m to about 2m before TD:

My guess is that in order to get rid of the tear line one would be best served by NVCP Vsync to 1/2 refresh, and using more power to overcome the modest increase in frametime variance from using it over RTSS Frame Limit w/ Front Edge Sync.

[Cpt_Piett]

30 minutes ago, Noel said:

Wow fabulous thanks for that!  I really appreciate it!

How about reducing T-LOD to 120 or so.

No worries. It'll be interesting to see how it is with these settings. Just a minor hiccup - I couldn't load the sim - stuck a the "checking for updates" screen. Always something, right? I'm now back in business, just have to set it up. Fresh SU10 install (don't worry, I had a backup of the Official folder).  

[Noel]

Yep it happens!  Fortunately, not very often ;o)

[Cpt_Piett]

@Noel here are the results. I'll upload the video once it's done processing. 

Settings: SU10 4K SDR DX12 TAA TLOD130 rest mostly ultra

Sim: 737-700 with livery, otherwise empty community folder, live weather and time, no AI traffic

Situation: Takeoff from KPSP 31L then CATH1.PSP departure up to cruise altitude

Display: 3840x2160 @ 60Hz

RTSS: fps limited to 30 using front edge sync

nVIdia control panel: G-Sync enabled (TV reports steady 60Hz during the entire session)

EDIT: Here's the video (4K processing not finished)

 

[Cpt_Piett]

While I was at it I also recorded and benchmarked the final approach into KLAX. As I had a flight plan in the FMC I did the whole flight. This is without Asobo's KLAX. Again, I'll post a link to the video once it's ready. 

It felt... different than running fps unlocked. Not necessarily worse. Just noticed whilst doing panning in the cockpit that the movements seemed a bit different. 

EDIT: Video (4K processing not finished)

 

[CO2Neutral]

22 hours ago, Noel said:

It unfortunately comes w/ a migrating "tear line" of mild horizontal linear line that can be visible when you are panning horizontally.

I didn't see a "tear line", but at 3:38 there's clearly a rendering sync problem with the HUD.  Not sure how anyone is recording the G-Sync, both nVidia tools and OBS will disable G-sync for recording (if you run OBS on an external PC using a capture card via HDMI splitter, the G-sync signal will not record either).  As you can see from YouTube videos the FPS recording is either 30 or 60.

Timeframe is certainly the most important "smoothness" metric but when you add G-sync (VRR) by definition timeframe will vary more (assuming you don't cap and Vsync off) so it's impossible to show "G-sync" working unless you use high capture rate external physical cameras.  If you want the most consistent timeframe then disable G-sync and pick a target (30Hz, 60Hz and Vsync On) and adjust your scenario and graphics setting so that you never drop below target FPS.  Most G-sync displays will have a VRR range, to prevent tearing you must keep FPS within it's VRR range.

G-sync is a process to reduce tearing (i.e. GPU renders another image to display before the monitor finishes showing the prior image) it does NOT make frametime more consistent.

23 hours ago, Noel said:

Let me know what vertical refresh rate you're at as well as what the range of frametime is for the first 5 or 10 minutes of a flight.  I use a Vsync method that delivers frametimes that just hardly change at all, they are super stable and consistent at exactly what they should be and will fluctuate by 0.1ms only pretty much,

In order to accurately measure timeframe for 30Hz or 60Hz you need to sample at 33ms or less or 16ms or less.  Unfortunately in your video, you're sample rate seems to be about 1000ms or 500ms (common default) which is why you get the impression of "hardly change".

 

[Noel]

Ok it looks like when locked it's behaving exactly as in my scenario except thru a Gsync display.   Is it safe to say the 'tear line' is still there?  I assume so unless Gsync had an impact on this which might be possible.  It would be absolutely fabulous it it did lose the tear line!

I wonder if you could now do another one, same exact MSFS configuration, except this time go fully unlocked and then see how frametime variability, stuttering and framerate is.  I would love to see what happens to frametime variance using Gsync unlocked, even though from reading articles it seems Gsync is intended to run alongside Vsync but 'covers' the deficit when the GPU is unable  keep up with the Vsync target frame rate.  

Thanks!

[Noel]

12 minutes ago, CO2Neutral said:

In order to accurately measure timeframe for 30Hz or 60Hz you need to sample at 33ms or less or 16ms or less.  Unfortunately in your video, you're sample rate seems to be about 1000ms or 500ms (common default) which is why you get the impression of "hardly change".

I see what you mean!  Even so, the other Vsync locking options are definitely worse, even with 1000ms sampling--how would you explain that?  I will rerun the test  at 10ms or so for my 30FPS sync thanks for the education.

Not sure what the capture rate was for CapFrameX, but this is the analysis.  One would think/hope they would make this very clear if one needed to change the capture rate:

Moreover, I noticed this method of Vsync was more 'smooth' than any other method employed.  It was only later I learned about frametime variance and began to believe this is the source of the perception of ultimate smoothness.

[CO2Neutral]

4 minutes ago, Noel said:

Even so, the other Vsync locking options are definitely worse, even with 1000ms sampling--how would you explain that?

My statement was in reference to the data sample rate as shown in the OSD you have in your video (which I believe is from RTSS and MSI Afterburner).  I think most data logging tools don't log below 100ms sample due to the data demands which might adversely affect system performance reducing your FPS slightly (depends on your hardware).  The data sample rate isn't related to Vsync On/Off, it's your OSD update rate (how often data points are sampled and displayed in your OSD).  RTSS allows you to drop this value to low of 100ms (lowest it will go).

Vsync will rely on what you have your monitor refresh rate set to ... so if you disable G-Sync and the monitor is set to 60Hz and your FPS drops below 60 at any point, it will be less smooth (longer timeframe).  G-sync can work well when you're within your monitors VRR range and that range is above 30 FPS (30Hz).  I don't see any OSD FPS or timeframe data in your video, are you logging to file also?

From visual only perspective (ignoring data), I find my monitor at 60Hz or 120Hz with G-sync enabled and if I stay 40 FPS or higher (in game) works well for my hardware (LG C2 OLED via HDMI 2.1 to GPU which supports HDMI 2.1 in my case 3090 and a 4090), timeframe will be less consistent, but overall timeframe average is lower, only when I drop below my monitors VRR range does it get distracting.  If my case, TAA and render scaling 100 provides a more smooth experience, anything above RS 100 combine with my other graphics settings/add-ons and I drop below my FPS threshold and less smooth.

 

[Noel]

41 minutes ago, CO2Neutral said:

Vsync will rely on what you have your monitor refresh rate set to ... so if you disable G-Sync and the monitor is set to 60Hz and your FPS drops below 60 at any point, it will be less smooth (longer timeframe).  G-sync can work well when you're within your monitors VRR range and that range is above 30 FPS (30Hz).  I don't see any OSD FPS or timeframe data in your video, are you logging to file also?

From visual only perspective (ignoring data), I find my monitor at 60Hz or 120Hz with G-sync enabled and if I stay 40 FPS or higher (in game) works well for my hardware (LG C2 OLED via HDMI 2.1 to GPU which supports HDMI 2.1 in my case 3090 and a 4090), timeframe will be less consistent, but overall timeframe average is lower, only when I drop below my monitors VRR range does it get distracting.  If my case, TAA and render scaling 100 provides a more smooth experience, anything above RS 100 combine with my other graphics settings/add-ons and I drop below my FPS threshold and less smooth.

Tell me if you know :  if main thread saturation is the source of inability to maintain the vsync maximum frame rate, does Gsync 'cover' the deficit somehow?  Or is this limited to when the GPU is the source of inability to maintain the vsync target?  This is what I most care about now because I'm never GPU-limited, always if setup too aggressively it's main thread impact that threatens maintaining 30FPS vsync lock.

Best to look at the screenshot I provided coming from CapFrameX:  since this is what this software does, capture frametime no matter what the interval length, that will be more useful than my video which was also using RTSS and CapframeX, but may have been limited by RTSS 1 second capture rate.  Again, this is what I see using RTSS Frame Limit w/ Front Edge Vsync.  Note the nearly nil frametime variance--other forms of Vsync do not produce this level of near zero variance: