2 minutes ago, SteveW said:

After setting up for a vsync to monitor refresh or external limit with Unlimited on the slider, we have a stable framerate limited down to that frequency.

Set up for the main task on the first core (CPU core zero or LP0) just below 100% and set up so the available framerate (tested without a limit would be above the vsync or the limit desired).

Now, any changes of the scene, perhaps the aircraft turns to view more buildings (for example) that requires slightly more throughput or time to complete the frame, this can be accommodated with core zero load moving closer to 100% and the framerate can still reach above the vsync frequency.

If the core reaches 100% or the available framerate reduces to less than the vsync frequency and the demand is actually more than 100%, that demand cannot be met and the framerate cannot reach the vsync frequency or limit desired.

The settings are set up to allow less than 100% on the main task, and available fps reaches higher than the vsync or desired limit. This allows for an additional throughput available in the main task on the first core, and the fps can drop with the demand but continue to be more than the fps limit. Then stability is maintained and less stutter is the result. If the fps available drops below the limit and the main task reaches more than 100% demanded then the desired fps cannot be maintained.

Or in English (sorry @SteveW), give it a bit of  performance headroom so you don't get stutters if the scene gets more complex.

16 minutes ago, Ray Proudfoot said:

I’ve never experimented with FFTF. I suppose having a 30Hz monitor makes it unnecessary. I don’t see blurries perhaps because the GPU is not being pushed that hard.

FFTF and a 30 Hz monitor are different things - if you are at a big airport and the FPS drops below 30 fps when you limit the fps internally (and this happens often), then it is a good idea to lower FFTF to mitigate the drop. If you use unlimited FPS, then you don't need to worry about it. To my knowledge, blurries show up when the CPU can't cope with the scenery load - the GPU is not to blame because scenery loading is a CPU intensive feature (while weather depiction is GPU intensive, so bad weather on approach should stress the GPU more than the CPU).

You are going up hill in your van at 30mph and your throttle is on the floor. If the hill steepens the van slows down because the throttle can't be increased.

34 minutes ago, Dirk98 said:

No Ray, it's rather like my own experience with PC hardware telling me so (switch less!) , and I think I've seen some frequency change warnings too, but the useful part in my method is that it is a legitimate feature of recent nVidia drivers vs frequency switching work around suggested by some sage here time out if mind. 

OKay Dirk, thanks.

When you get nearer the ground you can't see so far around you, the distant scenery becomes less important to view, but the nearer objects demand more time to render. If the FFTF can be reduced nearer the ground, less time is allocated per frame to all that scenery gathering and more time is made available to render the frame and maintain fps.

Thank you for your thorough explanation, @SteveW. It may take some time for beginners to digest it, but I have understood the information and tried it out myself. I set my monitor refresh rate to 45Hz and started with unlimited FPS in P3D with Vsync off. I saw 58 FPS and 100% core0 load, which is obviously expected. Then I activated Vsync (internally), and I saw very smooth 45 fps with core0 being loaded at something like 80%. Yes, in this case, why should the CPU work harder than necessary?

In the past, I never used that method; I always used the internal target FPS, and regardless of what I set (even just 10 fps), I see 100% core0 load. Does it mean that if core0 is fully loaded and you use the internal "limiter" that it's impossible to achieve smoothness?  No - at least in my experience. But I am wondering why you almost always get 100% core0 load if you limit internally. Does it require so much work to generate the look-ahead frames?

Now I understand why Ray saw the 100% load as a problem. He runs at 30Hz refresh rate with Vsync on and unlimited fps. Under these circumstances, the CPU load should obviously be lower. A situation like this affects people whose screen refresh rate is low enough to be below the achievable fps in a given situation. People who use the internal limiter may not understand this problem at all because they have been accustomed to see 100% core0 load.

22 minutes ago, Afterburner said:

Thank you for your thorough explanation, @SteveW. 

In the past, I never used that method; I always used the internal target FPS, and regardless of what I set (even just 10 fps), I see 100% core0 load. Does it mean that if core0 is fully loaded and you use the internal "limiter" that it's impossible to achieve smoothness?  No - at least in my experience. But I am wondering why you almost always get 100% core0 load if you limit internally. Does it require so much work to generate the look-ahead frames?

You're welcome.

Going back to what I said about the "internal limiter" or rather the "target fps slider", is that it is not actually a limit but rather it outputs frames at a consistent interval, and if there is time left during that interval it immediately starts to build look-ahead frames. So in fact it is nearly always running at unlimited, unless it can complete the amount of look-ahead frames (normally 3) in the time available between frames.

Anyone have success using a 144 Hz monitor recently?

 

Been struggling getting Gsync to work consistently with P3D to achieve smoothness.  Monitor can’t do 30 Hz, and 60 Hz becomes a complete stutter-fest, as well as using an Nvidia limiter.  Best I can seem to do is RTSS at 1/2, P3D limiter set to 37 FPS in windowed mode, Vsync and triple buffering internally off, and Process Lasso with the monitor left at 144 Hz.  Core 0 on my 7700K seems to sit around 80% usage, and 3080 seems to never exceed about 50%.

It seems Gsync (or something) is fighting amongst itself.  My sim will be consistent and smooth for a few minutes, then begin to stutter until I minimize the sim and re-expand it.  Additionally, for whatever reason I can’t explain (and I think I’ve stumped the developer), whenever Chase Plane’s main window is visible or minimized to the task bar, I’ll get stutters. The ONLY way I’ve been able to find to get around that is to minimize the Chase Plane window to the system tray.  Very odd.  So between what seems to be inconsistent Gsync and Chase Plane stutters, I’m definitely struggling.

 

Edited June 25, 20214 yr by CaptKornDog

2 hours ago, CaptKornDog said:

 Very odd.  So between what seems to be inconsistent Gsync and Chase Plane stutters, I’m definitely struggling.

I remember this happening to me in P3D v4.2, my ChasePlane caused stutters after I had enabled the AffinityMask setting in the CFG, and there was autogen lag so the terrain was becoming really blurry after a while;  I fixed it by totally uninstalling the simulator, but I could never find out what was the true culprit. I can't remember if I posted that on AVSIM or not. 

As for G-Sync, I use a FreeSync monitor that's compatible with G-Sync. I never had a problem with it stuttering, so my guess is something with ChasePlane, as I have experienced that before too (but in a different sim).

@CaptKornDog, did you buy the monitor for something other than P3D? If you have games that require a high refresh rate I can understand why such a monitor would be necessary.

The trouble is - as you've alluded to - these displays aren't really cut out for flight simming when 30Hz is very desirable.

But with GSync I would have thought 30-35 was doable. Or are you limited to the minimum refresh rate the monitor can supply? Surely there must be lower settings than 144Hz.

It’s funny because these conversations may become obsolete when the HF is released. 

22 minutes ago, Dreamflight767 said:

It’s funny because these conversations may become obsolete when the HF is released. 

I find it funny that 30hz, Affinity Mask and HyperThreading discussions have been around for sometime yet it's new to some who have been around for awhile. 😉

1 hour ago, Ray Proudfoot said:

@CaptKornDog, did you buy the monitor for something other than P3D? If you have games that require a high refresh rate I can understand why such a monitor would be necessary.

The trouble is - as you've alluded to - these displays aren't really cut out for flight simming when 30Hz is very desirable.

But with GSync I would have thought 30-35 was doable. Or are you limited to the minimum refresh rate the monitor can supply? Surely there must be lower settings than 144Hz.

Yes, I do other high-refresh work on my system.

 

The monitor can go as low as 24 or 60, and higher increments; just not 30.  Anything other than 144 results in some pretty significant stutters.

9 minutes ago, CaptKornDog said:

Yes, I do other high-refresh work on my system.

The monitor can go as low as 24 or 60, and higher increments; just not 30.  Anything other than 144 results in some pretty significant stutters.

Nothing between 24 and 60 is a shame. One is too low and the other too high. How about 36? One quarter of 144.

2 hours ago, Ray Proudfoot said:

Surely there must be lower settings than 144Hz.

Yes, I have mine set to 120Hz and never need to change it - my PC is not restricted to flight simming. I limit FPS to 30 (120/4) using the NCP.

Mike