8600k buttery smooth to stutter fest 8700k

[asgnp 27]

Hi folks,

So having jumped from a 8600k with buttery smooth performance to a 8700k with bad stutters, is this normal? Caused by HT? Also, if i use AM 1365, its back to being buttery smooth. Any other tricks, AM values.

Thanks in advance for any help.

[kevinfirth 1,396]

Probably explained by the core usage with HT enabled with no AM yes.  @SteveW will confirm I'm sure..

[SteveW 1,792]

Yeah. On an HT enabled rig of six or more cores 1365 runs P3D and FSX as if in non HT mode 01,01,01,01,01,01 on six cores one task per core. Put this in a simplified way, the first two cores basically run the sim, the others in support.

SO HT enabled with no AM = 11,11,11,11,11,11 and that basically runs P3D on one core performance will suffer.

[asgnp 27]

On 1/16/2020 at 12:18 PM, SteveW said:

Yeah. On an HT enabled rig of six or more cores 1365 runs P3D and FSX as if in non HT mode 01,01,01,01,01,01 on six cores one task per core. Put this in a simplified way, the first two cores basically run the sim, the others in support.

SO HT enabled with no AM = 11,11,11,11,11,11 and that basically runs P3D on one core performance will suffer.

Thank you for clearing that out. Is there any other AM value that will/ might work?

[SteveW 1,792]

What happens is we want six cores for P3D for maximum file loading, but we also have system resources and addon exe apps might be running as well, so we need to give CPU throughput to those too.

Each system is different so we experiment armed with a bit of know how.

 

Some examples given the six core HT enabled CPU, these are good CPU's.

With that AM 1365 = 01,01,01,01,01,01 which uses six straight cores that's great but pushes out system resources that P3D and FSX rely on. Other games don't rely on so much system throughput once they are running. The flight sims require much more system resources like file and network.

So we could try AM 340 = 00,01,01,01,01,00 which is four straight cores. If the system has addon exe apps AI traffic and weather maybe, this might be a good balance of power leaving two cores free.

We can intensify background loading with an example: AM 980 = 00,11,11,01,01,00 this is four cores for the sim, but the background tasks are doubled on the leftmost two sim cores (11,11) and this intensifies use of the core for loading files.

So we could do that with AM1365 to produce something like AM3925 = 11,11,01,01,01,01

 

Adding more ones into the AM pushes out the system resources the simulator uses all the time and can in effect make it wait for itself.

 

Remember the rightmost one in the AM is the main task when we allow P3D and FSX to organise themselves. We need to ensure this runs unimpeded by sharing with other tasks whether on the sister Logical processor core or the same LP.

 

If we subsequently go into Task Manager and choose more CPU cores then the main task will probably move to another core, this is how we can jog the jobscheduler into action.

If we choose less cores we bunch the tasks already running onto less cores which might not be the desired outcome.

 

[asgnp 27]

Thank you Steve. I will try and see which one provides me with the most consistent frame times.

[SteveW 1,792]

Consistent frame times heavily rely on P3D display settings rather than CPU throughput balance. Choosing an AM cannot cause problems in the simulator, P3D works fine on one core with 2 LPs. So when we see big changes in the system we know something might be wrong somewhere.

To test initially, I set Display Settings very low and use Unlimited with VSync = Off and with the key SHIFT + Z we can watch the fps capacity of that system. No good to use high settings first, use low first.

When we add settings, and move sliders right the fps will come down and the time to load the scenario will increase.

We can measure the time to load any given scenario up to a certain point perhaps when we first see the sim running. With a stopwatch measure how much time is taken with the addition of one more core or LP at a time.

We come across a point whereby the scenario continues to load more quickly, but only by a fraction. We now have the number of cores or LPs that saturate the system throughput. In effect we have found out more or less the number of cores or LPs we need. Actually this may be too many. More cores do nothing other than load the system without giving us a better experience.

 

 

Edited January 17, 2020 by SteveW

[SteveW 1,792]

When the sim runs we can look at the fps consistency as you suggest. The sim relies on more consistent frame periods when it is used with low fps, perhaps below 30fps. In those cases we check what we can get using locked fps on the slider, use VSync off with that in P3D. We can use VSync=On with locked fps but we might expect tiny stutters as some early frames are lost. Instead with VSync=Off we might see slight shifting in the view when we pan quickly.

With Unlimited + VSync = On we kind of limit the sim to the refresh rate of the monitor. We see the fps wobble around 60fps on a 60Hz monitor. We can limit that externally so we don't rely on the monitor refresh time. Or we can set up a monitor profile for say 30Hz.

We get nice results if we limit to a division of the Monitor refresh, or just below it. Limiting to just above "to help make sure a frame is ready" is not how it works. Instead early frames are lost, and we have to wait for the next which can be nearly two frames. So we limit at or just below. A 144Hz monitor could be used as 24fps which is 144/6.

Vertical synchronising is handled by the desktop in P3D, the VSync=On setting in P3D display settings enables the sim to tune itself to that frequency, the monitor refresh frequency.

 

Edited January 17, 2020 by SteveW