Looking at a fresh setup I would set VSync = Off + Unlimited. Use Shift + Z to see the fps on the sim main screen. Also I can run Task Manager and keep an eye on the graphs. I can start to increase settings from very low and watch what happens. The graphs take up more % of the cores and the fps comes down. We would see fps in the hundreds, even with a GTX680, no need for a ti to see fps.

So we can see that our fps continues above the chosen frequency of the monitor in a given scenario. On my 4k it is selectable from 60Hz, 30Hz, or 24Hz, I chose 60 and can see the output frequency of the simulator is way above 60fps with Shift + Z.

Now I can go to Display Settings and turn on vsync. VSync = On and leave the slider on Unlimited. back in the simulation the fps hovers smoothly around 60fps. This is with a DisplayPort cable.

This is not always the case since there are different interfaces and cables. But mostly we see this behaviour. With fast systems we see a lot of flicker unless VSync = On or Locked is set anyway, forcing the user to hunt for a solution. Some systems may also require the triple buffer enabled as well to stop flickering. In all cases the Locked setting, (for systems around 19-24 fps), do not flicker.

With the proper know-how there's no need to become frustrated with P3D.

 

Edited November 18, 20196 yr by SteveW

Let's look at the HT ON or OFF, AM or no AM situation - this really winds everyone up.

For a test I have set up a [email protected], 2TB M.2, 64GB, NVLink 2080ti pair, 43" 4K DisplayPort, P3D+ v4.

Testing first, with HT enabled I chose no AM, that is no JOBSCHEDULER entry in Prepar3D.cfg. In other words, AM=0.

Next I tested the same P3D settings with JOBSCHEDULER AffinityMask=340.

In the top of the image the AM=340 graphs are shown with P3D started up and settled into a flight. I have demonstrated graphically which are cores, and which are LPs, and those that are in operation by P3D, and those in operation  from resources of the system, some invoked by those P3D tasks.

With two sets showing, the top half AM=-340, the bottom half no AM

We can see the top left pair of LPs are in fact the same core, core zero, and these are Logical Processors zero and one. With HT enabled, it is then using two sets of L1 cache per core and increases the chance of favourable outcome from look ahead and pre ordered memory transactions, and also uses more cycles available to that core rather than having waiting situations in the core with HT disabled.

The lower half shows the result of NO AM. It can be seen that there are two tasks on that first core, LP0 and LP1, both of those are P3D tasks that when loading data are competing for bandwidth of that core.

Although multicore is happening, it has not moved the second task onto another core. When the next bit of scenery loads up, those cores compete for bandwidth of the same core.

With the AM=340 we see that there is no activity on any of the sister LPs of those cores because we have manually asserted the LPs for P3D to use. These tasks are the same but now they have uninterrupted flow of the core bandwidth.

It is also apparent in the lower half of the image, that even though no AM is specified, and 38 LPs are available, there are only four important P3D tasks running as there are with the AM=340.

 

 

 

In the next image we can see that with NO AM, P3D uses every LP to gather data for the scene, before settling into the situation we saw in the first image.

What happens, when fresh scenery is gathered along the way or AI come into operation, is that all those LPs light up, all 36 with HT enabled, all 18 cores with HT disabled, and that saturates the CPU - causing stutter in the main task.

That main task has no longer got the freedom of the bandwidth available within the system, that is between GPU and Memory since it is occupied by all those cores or even worse double that with HT LPs.

 

So it becomes evident that allowing all cores irrespective is not the way to go, an AM is required, even with HT Disabled. On 6 to 18 core HT Disabled, that is AM=30. With a four core no AM is required since P3D will use all four. However with four core and HT enabled an AM = 85 should be used. With six core HT enabled AM=340, no HT AM=30.

As we add cores we see the loading time reduce by a lot. But as we add them, this reduction comes down to maybe only a few seconds. At that point the system is reaching its bandwidth limits. So we want to use less cores than that.

Again with a little know how it is not too hard to understand the principles. The motherboard has a limit of bandwidth, no matter how many cores.

 

Edited November 18, 20196 yr by SteveW

On 11/17/2019 at 4:14 PM, Rob_Ainscough said:

Yes ... all 3 PCs, no issues so far ... what's up?  I guess more accurately I'm on 1909 not 1903.

Cheers, Rob.

Oh the news feed on Google said to stay away from the update.  I'm still on 1903 (Build 18362.418)

Edited November 20, 20196 yr by HUSSAR

2 hours ago, HUSSAR said:

Oh the news feed on Google said to stay away from the update.  I'm still on 1903 (Build 18362.418)

The "funny" thing is: if you have a properly maintained Windows 10, you will have almost 90% of all 1909 updates already installed, even if the system info still tells you 1903. At least for me this was the case, because the final update switching 1903 to 1909 was just some megabytes and installed in seconds...

On 11/10/2019 at 11:29 AM, Vlooi said:

Hi Mark,

On some forums across the web there are complaints about the latest nvidia drivers, from 440 upwards, especially the 441 series. Try an older driver (436 series maybe), and see if that helps.

Regards

Marius

fwiw, and only anecdotally, the 441 series has been the best improvement I have seen in an Nvidia driver. I still have on older card, the FTX760, but even with that, the image sharpener setting in the 441 Control Panel has made an amazing change for the better.

10 hours ago, Rob_Ainscough said:

Any specifics of the issues some encountered?

Cheers, Rob.

It was in the Google news section from Computerworld.com on my smartphone warning people to temporarily disable Windows Update and to wait a few weeks until the bugs had been worked out.  I have updated my client PC which runs a few programs and have not had any issues, going to do the server PC today.  

Probably just fear mongering to get readers to their site.

On 11/18/2019 at 6:08 PM, SteveW said:

So it becomes evident that allowing all cores irrespective is not the way to go, an AM is required, even with HT Disabled. On 6 to 18 core HT Disabled, that is AM=30. With a four core no AM is required since P3D will use all four. However with four core and HT enabled an AM = 85 should be used. With six core HT enabled AM=340, no HT AM=30.

As we add cores we see the loading time reduce by a lot. But as we add them, this reduction comes down to maybe only a few seconds. At that point the system is reaching its bandwidth limits. So we want to use less cores than that.

Again with a little know how it is not too hard to understand the principles. The motherboard has a limit of bandwidth, no matter how many cores.

 

Out of curiosity; whenever you suggest an AM, you often leave out the first core and I understand why in terms of not using a core that might still see OS based activity. However, every time I stop using the first core, without fault, my terrain will stop rendering. It'll just become smooth and textures look extremely low res as the flight progresses. Any reason for this? Had this happen on two completely different machines now but as you're still suggesting it, I feel like I'm the only one seeing this.

Edited November 20, 20196 yr by Sethos

Since it makes no difference which cores are used it remains a fact that you can use any four cores with no changes in behaviour.

Your report suggests some other problem within your setup or a problem with the AMs you try. There should be next to no difference in behaviour at all, whatever four cores you use of six core + CPUs..

 

The number of cores you have and the setting of HT makes a lot of difference to what AMs should be tried..

What AMs you try depends on how many cores you have available and where other programs force their way in. If you have four cores no HT, with no AM you are using AM15=1111. With 6 cores and AM30=011110 is still four cores and the sim behaves no different to 001111 or even 110011.

A difference with individual core throughput can be down to throttling with heat on certain cores, so you may find 111001 works better than 111010.

I leave two cores free in 6 core examples. With four cores you need them all with P3D.. But with four cores and all with P3D on, that means that any addon exe that lights up and fires traffic or weather or whatever at the sim interrupts the bandwidth of those. So with six cores, AM30 or HT enabled AM340 shows the best use of the CPU. However this does not take into account the addons and the possibility of bad OCs or whatever else is happening on the system.

 

Edited November 20, 20196 yr by SteveW

On various six core systems I find that 30 (340 with HT) outperforms no AM every time. Gerard used to contact me all the time about HT enabled 340 outperforming all other configurations he tried for months. There's many more examples I have here, of folk with quick system now alleviated from dodgy stutter. 

Leaving core free at the ends helps where we don't specially corral those other activities away from the sim cores. I use a complex test harness, programmed privately, to ascertain true bandwidth.

On 11/18/2019 at 12:08 PM, SteveW said:

Let's look at the HT ON or OFF, AM or no AM situation - this really winds everyone up.

For a test I have set up a [email protected], 2TB M.2, 64GB, NVLink 2080ti pair, 43" 4K DisplayPort, P3D+ v4.

Testing first, with HT enabled I chose no AM, that is no JOBSCHEDULER entry in Prepar3D.cfg. In other words, AM=0.

Next I tested the same P3D settings with JOBSCHEDULER AffinityMask=340.

In the top of the image the AM=340 graphs are shown with P3D started up and settled into a flight. I have demonstrated graphically which are cores, and which are LPs, and those that are in operation by P3D, and those in operation  from resources of the system, some invoked by those P3D tasks.

With two sets showing, the top half AM=-340, the bottom half no AM

We can see the top left pair of LPs are in fact the same core, core zero, and these are Logical Processors zero and one. With HT enabled, it is then using two sets of L1 cache per core and increases the chance of favourable outcome from look ahead and pre ordered memory transactions, and also uses more cycles available to that core rather than having waiting situations in the core with HT disabled.

The lower half shows the result of NO AM. It can be seen that there are two tasks on that first core, LP0 and LP1, both of those are P3D tasks that when loading data are competing for bandwidth of that core.

Although multicore is happening, it has not moved the second task onto another core. When the next bit of scenery loads up, those cores compete for bandwidth of the same core.

With the AM=340 we see that there is no activity on any of the sister LPs of those cores because we have manually asserted the LPs for P3D to use. These tasks are the same but now they have uninterrupted flow of the core bandwidth.

It is also apparent in the lower half of the image, that even though no AM is specified, and 38 LPs are available, there are only four important P3D tasks running as there are with the AM=340.

 

 

 

In the next image we can see that with NO AM, P3D uses every LP to gather data for the scene, before settling into the situation we saw in the first image.

What happens, when fresh scenery is gathered along the way or AI come into operation, is that all those LPs light up, all 36 with HT enabled, all 18 cores with HT disabled, and that saturates the CPU - causing stutter in the main task.

That main task has no longer got the freedom of the bandwidth available within the system, that is between GPU and Memory since it is occupied by all those cores or even worse double that with HT LPs.

 

So it becomes evident that allowing all cores irrespective is not the way to go, an AM is required, even with HT Disabled. On 6 to 18 core HT Disabled, that is AM=30. With a four core no AM is required since P3D will use all four. However with four core and HT enabled an AM = 85 should be used. With six core HT enabled AM=340, no HT AM=30.

As we add cores we see the loading time reduce by a lot. But as we add them, this reduction comes down to maybe only a few seconds. At that point the system is reaching its bandwidth limits. So we want to use less cores than that.

Again with a little know how it is not too hard to understand the principles. The motherboard has a limit of bandwidth, no matter how many cores.

 

Good god.!!!!

 

This alone is enough to make me give up!

 

lol

Steve is good at bamboozling people with tech stuff

Edited November 20, 20196 yr by Christopher Low

I find flying is complicated, but I need not ignore the complexity of the PC. Those posts are easy to understand for a pilot surely.

Problem is there's so much AM and HT FUD around that it is still thought of as some kind of problem, by those that don't understand it. I'm doing what I can to help and suggest to anyone that wants to get the best from their rig, that the FUDsters are ignored and the technology embraced, as it is with planes.

 

Edited November 20, 20196 yr by SteveW

20 minutes ago, Kilo60 said:

Good god.!!!!

 

This alone is enough to make me give up!

 

lol

Your post is nowhere near enough to make me give up. lol.

In a nutshell, those complicated posts and images (reading time 3 minutes, difficulty level experienced users) basically shows:

...when all cores gather new data at once, the system takes a hit, the one core that requires consistent throughput is hit, the rendering core, and that hit slows it down. Variance in the flow on this main core (and others) causes the appearance of stutter.

There's an example above of the use of VSync in P3D, which is not the same as other games so no use referring to a regular game player for support, they don't know how P3D works.

In the example the poster (gets upvoted) says he's just discovered something about P3D VSync + Unlimited I've been explaining since day one of P3D.

So that is the problem. I'm not the issue. I've laid out how to professionally install and set up the simulator and it's the same since day one.