Seems like your system is running pretty sweet! Well done.

 

But anyway, to conclude all you can try with regards to Affinity Masks and HT, there's still something else you can try if you are not completely worn out, although I'm not certain it can help with your AI count:

By using the Affinity Mask 11,11,11,11,11,01 = AM 4093 = 6 cores with 11 LPs.

Bear in mind you don't want to share with the time sensitive task on LP0 so LP1 looks unused. AM 4093 will throw everything your 6 core HT enabled PC has to loading scenery but will still avoid LP1 to leave the main task on LP0 alone on core 0.

Your addon exe's could then go on, I think will work out to be LP3 and LP5, but look at the Task Manager graphs for the two LPs with the low and steady loads, rather than the jagged terrain loading.

This will change the way the loads look on all those LPs, but with this type of hyperthreading affinity you are using the HT pairs to extract the most from those HT cores. This increases processing capacity to the terrain loaded a bit by using more of the throughput available to those cores, so it may help with your AI count a little, but I'm not sure. However, the CPU may get hotter and the total of all LPs running together can detract from the main task on LP0 so will need to see if the LP goes up to 100%.

@SteveW, thanks, I’ll try that in a few days. It’s been a busy week.

My first concern was heat which you touched on. But nothing ventured, nothing gained. I’ll report back in due course.

Time has flown this week more than us! 😄

 

 

I would like to ask something simple and logical:  If you run P3D with all kinds of goodies and eye candy (AI traffic, PMDG airplane, ORBX scenery), why should P3D not utilize CPU1 to the full extent?  I mean, if I see anything less than 100% (provided that we have a situation where the GPU is not the limiting factor), it means that the performance (FPS) is lower than the maximum possible performance, is that correct?  Therefore, 100% CPU1 load means that the processor works hardest to achieve the highest possible frame rate. If you reduce scenery settings or switch to a less complex airplane, the CPU will work as hard as before, but the result will be a higher frame rate, since the reduced scenery/airplane complexity can be processed quicker, but why should CPU1 work less hard?  In this regard, I don't understand the attempt by some users to reduce CPU1 load to below 100% by reducing graphics settings. You end up getting higher FPS, yes, but if the current FPS is 45, and I only need 30 to have a smooth flight, I can increase the settings and have the FPS still above 30.

What about the so-frequently mentioned smoothness?  Isn't smoothness provided when the FPS is stable and the monitor refresh rate exactly matches the frames per second of the game?  If there is a mismatch between the two, you inevitably get stutters (or tearing) depending on the difference between the refresh rate and FPS. If I limit the FPS internally, the CPU1 load remains at 100% in P3D regardless of what target FPS I set - this seems to be a P3D thing. However, I can still achieve smooth flights under the said condition, so why should I worry about CPU1 running at 100% (or near that figure for that matter)?  Yes, there are microstutters every now and then, especially if you use complex scenery, but most games have them (including MSFS, and FSX was the worst). But that's OK if they happen only sporadically, isn't it?

Sorry if these questions sound nooby, but I am wondering why some people make things more complicated when they are rather simple. Or is there something wrong with my thinking process?

@Afterburner, in the days before I bought a monitor capable of 30Hz I was obsessed getting fps as high as possible. Affinity Mask was a mystery to me. The refresh rate on my displays was 60Hz. But fps rarely reached that number so each time the monitor refreshed the display the same info was being displayed. Occasionally it caused tearing unless VSync was enabled.

But VSync means you’re demanding 60fps from the hardware and generally that isn’t possible so stutters result as you are demanding more than the hardware could deliver.

The key is to lower the monitor refresh rate to 30Hz. If you have no Ai you can set your autogen and scenery complexity at your most demanding airport and all should be well in the sim. The 3rd party addons you mention will also impact on performance so compromise is essential. If you set your scenery settings for a quiet airport it cannot cope when you approach a large one.

It may be that those settings will push core 0 over 100% should the weather be bad. In better weather the demand will be lower.

But if you then add an Ai package where you have an unknown number of aircraft at any airport the demand on core 0 will probably exceed 100% at the large airports thereby causing stutters.

The solution to that problem is to allow FSUIPC to reduce the number of Ai until 30 fps is achieved. You can’t adjust scenery settings on the fly like that nor adjust the weather. Ai is the only thing available to you.

I’ve never used the internal limiter in P3D as it uses CPU cycles to do the calculation and performance suffers. VSync linked to a suitable monitor refresh rate is the best way to achieve smoothness and a constant NN fps where NN is the current refresh rate.

For monitors with a variable refresh rate they provide the ultimate solution since they’re not locked to 30Hz or 60Hz like conventional monitors are. You can set 42, 35 or 27 or whatever. But they’re expensive and locked to the graphics card manufacturer.

Nothing wrong with your thinking. Things become more complex when you have a big Ai package and want to see more aircraft at the expense of fewer buildings. It’s all about getting the balance right for each user’s priorities.

@Ray Proudfoot Point taken!  In the past, I remember having set 30 FPS internally in P3Dv3 with VSync and triple buffering enabled while running a screen refresh rate of 60 Hz, and I got sporadic stutters on a regular basis (even if the sim could reach much higher fps in unlimited mode). I couldn't understand why. After all, if your screen refresh rate is a multiple of the frame rate, it should be smooth. (We saw that with 100 Hz TVs in the past that displayed 50 Hz PAL signals in a smooth fashion). Then I came across this thread, which helped me achieve smoothness.

Since I switched to Windows 10 and P3Dv4 after building a new computer, I can say that VSync has been working quite well on P3D and MSFS with the current Nvidia drivers, and I saw much fewer occasional stutters than in the past (which are unavoidable, I guess). In combination with a monitor featuring AMD FreeSync (which my Nvidia GPU can use), smoothness has not been a problem, provided that the computer can keep up with the target FPS. From what I have read, a lot of Nvidia cards can work together with AMD FreeSync these days, and the latter feature requires no license fees like Nvidia Gsync, making the monitors cheaper.

As far as locking FPS internally vs. externally, it is true that locking internally comes with an fps penalty unless you reduce the FFTF value to 0.01 - and I have documented that in one of my videos. However, on the positive side, you are much less likely to see blurries or delayed or missing autogen loading if you use higher values. And I use the tool "FFTF Dynamic" by FPS store, which gives you the best of both worlds by adjusting the value automatically en route.

23 minutes ago, Afterburner said:

As far as locking FPS internally vs. externally, it is true that locking internally comes with an fps penalty unless you reduce the FFTF value to 0.01 - and I have documented that in one of my videos.

Soon as I touch FPS slider from Unlimited to anything else I can see the performance penalty immediately. Yes you can smooth it with very low FFTF to some extent, but I still prefer Unlimited with FFTF Dynamic in AGL mode.

And btw a 30Hz-capable monitor is not the key anymore after nVidia introduced frame rate limiter in it's drivers. Just use it in conjunction with half refresh sync option (if a 60Hz monitor), Ulta low latency and Vsync in P3D. I don't care switching my monitor back and forth 30/60Hz anymore which may also extend monitor's health.

Does Vsync make a real difference? I have tested with on and off and on MY system (I emphasise that), RTSS doing the half refresh rate only, unlimited in P3D, it makes no discernable difference at all.

47 minutes ago, IanHarrison said:

Does Vsync make a real difference? I have tested with on and off and on MY system (I emphasise that), RTSS doing the half refresh rate only, unlimited in P3D, it makes no discernable difference at all.

It does if you run in windowed mode at times. And even in full screen it does synchronization job better here. But after using RTSS for some time I thought it worked somewhat better than NVPI, anyway I don't bother using it anymore, unless I'm curious about some benchmarks. My combination of settings and FFTF Dynamic work well here.

7 hours ago, Dirk98 said:

And btw a 30Hz-capable monitor is not the key anymore after nVidia introduced frame rate limiter in it's drivers. Just use it in conjunction with half refresh sync option (if a 60Hz monitor), Ulta low latency and Vsync in P3D. I don't care switching my monitor back and forth 30/60Hz anymore which may also extend monitor's health.

I may experiment with this compared to using 30Hz to see if it’s as smooth.

Can you point me to any manufacturers warnings about switching frequencies liable to cause damage?

@Dirk98

Hallo Dirk,

can you post your Nvidia, FFTF Dynamic Settings.

What CPU and GPU are you use.

 

Thanks Frank from EDDM

 

Edited June 25, 20214 yr by f.skywalker

1 hour ago, Ray Proudfoot said:

Can you point me to any manufacturers warnings about switching frequencies liable to cause damage?

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. 

38 minutes ago, f.skywalker said:

@Dirk98

Hallo Dirk,

can you post your Nvidia, FFTF Dynamic Settings.

What CPU and GPU are you use.

 

Thanks Frank from EDDM

 

I will give a full rundown of my hardware and software components and settings later on if you want when I'm back at the computer.

9 hours ago, Afterburner said:

After all, if your screen refresh rate is a multiple of the frame rate, it should be smooth.

I used the same logic when I had to run my 3840*2160 monitor at 1920*1080. It has minimal remapping to do so should provide a quality image. Sadly it doesn’t even though it’s a quality monitor. Native resolution is a must.

9 hours ago, Afterburner said:

As far as locking FPS internally vs. externally, it is true that locking internally comes with an fps penalty unless you reduce the FFTF value to 0.01 - and I have documented that in one of my videos. However, on the positive side, you are much less likely to see blurries or delayed or missing autogen loading if you use higher values.

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.

11 hours ago, Afterburner said:

I don't understand the attempt by some users to reduce CPU1 load to below 100% by reducing graphics settings. You end up getting higher FPS, yes, but if the current FPS is 45, and I only need 30 to have a smooth flight, I can increase the settings and have the FPS still above 30.

so why should I worry about CPU1 running at 100% (or near that figure for that matter)? 

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.

The "internal limiter" is actually not a limit at all. Instead it produces frames output at a constant interval (if the system can handle it). If there is more time available per frame then it starts work on a look-ahead frame or frames. This is more demanding an a system but ensures the time between frames is very stable if the settings allow it to complete frames within the specified interval.