V4.5 : what has happened to Locked framerate ?

[SKEWR 364]

Much like @LecLightning56 stated, you can get a more normal core 0 usage from BitSum products. What I do is load up into the sim (plane and airport). Then look at process lasso. You'll see your core 0 usage at 100%. Then click on the P3D process and change the current CPU affinity and disallow cores 0 and 1. You'll see the core usage on core 0 drop/ Wait about 10 seconds, then set the affinity so that all cores are used. You should then see all cores pick up.

[LecLightning56 33]

1 minute ago, Bert Pieke said:

Interesting... With HT set to ON on my 4770K, I find that keeping Core0 empty all the time gives the main P3D thread on Core1 the breathing room that it likes to have.. but every system is truly different in this regard.. number of CPU cores, HT on or off, other addons... etc etc 

My further thing to add (and more pertinent to this thread) is that the dynamic affinity with CorePrio works irrespective of whether or not frames are locked in P3D v4.5, i.e. core 0 remains well less than 100%.

[pracines 823]

53 minutes ago, LecLightning56 said:

I don't want to be accused of alchemy, but I have discovered a tool from Bitsum (the same people as Process Lasso) called CorePrio (freeware, check the Bitsum website) which does something interesting on the subject of the problem observed with core 0 at 100%.

I am only basing my findings on e.g. the default F-22 at KVPS, but when I start the sim with the aircraft on the ground, core 0 is at 100%. If you then set the CPU affinity in CorePrio to exclude core 0 for Prepar3D.exe, core 0 drops down from 100% to say 60-70% approximately and I gain about 10 fps for the bargain. Note that this is not a permanent affinity to always exclude core 0 but a dynamic affinity and this may explain why Process Lasso by itself may not be able to achieve the desired results. I have mentioned CorePrio before on the AvSim forums and I would agree that although it may have been designed around AMD processors, it certainly seems to operate on Intel processors. I cannot vouch for the performance of CorePrio on more recent Intel processors (mine is rather old, an i7 875K, but I do manage to do some modest overclocking using the Intel Xtreme Tuning Utility). CorePrio was recommended to me by the developer of Process Lasso.

 

My understanding was that CorePrio was going to be implemented into or be a part of PL. I guess that has not happened yet. 

[LecLightning56 33]

2 minutes ago, SKEWR said:

Much like @LecLightning56 stated, you can get a more normal core 0 usage from BitSum products. What I do is load up into the sim (plane and airport). Then look at process lasso. You'll see your core 0 usage at 100%. Then click on the P3D process and change the current CPU affinity and disallow cores 0 and 1. You'll see the core usage on core 0 drop/ Wait about 10 seconds, then set the affinity so that all cores are used. You should then see all cores pick up.

Interesting you should say that. It would appear that if having observed the reduction in core 0 usage from 100% I then stop the CorePrio process, the effect of having reduced the core 0 usage remains within the system. It could be that CorePrio does not have to be operating continuously in order to achieve a more dynamic affinity for the cores operating.

[Bert Pieke 7,584]

According to the CorePrio description (which I just read), it addresses a possible bug in the Windows Scheduler.. which is consistent with other observations that I have come across, that turning affinity off and on again after P3D is running can improve performance.. Others have blamed this on LM, but if indeed the Windows Scheduler is the culprit that might explain a lot, especially the inconsistent nature of both the problem and the fix..

Quote:

It turns out the reason was because the CPU affinity has to be changed after the process starts; the effect is not seen when the CPU affinity is assigned during process creation.

What is the issue?

Nobody knows. Or at least nobody has communicated such. Whether it is core thrashing, a memory channel bottleneck inherent to the NUMA allocation strategy, we don’t know. No theories have panned out that point to a definitive cause, leading to the speculation it may simply be some bug or quirk deep in the Windows scheduler.

What is the ‘fix’?

The ‘fix’ is bizarrely imprecise. For affected processes, a call to SetProcessAffinityMask, without even changing the affinity (e.g. all CPUs to all CPUs), resolves the performance issue – at least most of the time. Our best guess is that the preferred NUMA node for the process is removed, causing the Windows scheduler to change behavior, as evidenced by the thread ideal processor selections, and more importantly the massive change in performance.

[LecLightning56 33]

10 minutes ago, pracines said:

My understanding was that CorePrio was going to be implemented into or be a part of PL. I guess that has not happened yet. 

That is correct as I understand it from the developer. I think he is at two minds over whether or not to leave CorePrio as a standalone utility, or as an optional feature within Process Lasso.

Edited May 16, 2019 by LecLightning56

[edpatino 1,959]

11 hours ago, GSalden said:

It doesn’t matter if all sliders are set to the left and Locked framerate at 10 , core 0 ( main thread ) has  100% load.

Using Unlimited shows a 92%  load with very high settings and 95+  fos, while with Vsync on ( 25 hertz / 2 4K displays in NVSurround with Distortion correction ) load drops to 67%.

As Uimited + Vsync still show some jumping up fps ( 50/100/ back to 25 ) , in V4.4 I also used Locked at 30 to avoid that.

When doing that with V4.5 because of the Locked framerate too there is this 100% load .

Therefore I started to test with my 2 pc’s and found out that with Locked framerate , regardless of the settings , the main core shows a load of 100% which causes micro stutters ..

After reading things like that everywhere, I decided to keep on with my v4.4 that works!. No rush here, but don´t like to be part of any beta testing.

Cheers, Ed

[Bert Pieke 7,584]

20 minutes ago, LecLightning56 said:

Interesting you should say that. It would appear that if having observed the reduction in core 0 usage from 100% I then stop the CorePrio process, the effect of having reduced the core 0 usage remains within the system. It could be that CorePrio does not have to be operating continuously in order to achieve a more dynamic affinity for the cores operating.

CorePrio appears to offer two capabilities, which one are you using?

Is the NUMA disassociator enough by itself?

[pracines 823]

6 minutes ago, Bert Pieke said:

According to the CorePrio description (which I just read), it addresses a possible bug in the Windows Scheduler.. which is consistent with other observations that I have come across, that turning affinity off and on again after P3D is running can improve performance.. Others have blamed this on LM, but if indeed the Windows Scheduler is the culprit that might explain a lot, especially the inconsistent nature of both the problem and the fix..

Quote:

It turns out the reason was because the CPU affinity has to be changed after the process starts; the effect is not seen when the CPU affinity is assigned during process creation.

What is the issue?

Nobody knows. Or at least nobody has communicated such. Whether it is core thrashing, a memory channel bottleneck inherent to the NUMA allocation strategy, we don’t know. No theories have panned out that point to a definitive cause, leading to the speculation it may simply be some bug or quirk deep in the Windows scheduler.

What is the ‘fix’?

The ‘fix’ is bizarrely imprecise. For affected processes, a call to SetProcessAffinityMask, without even changing the affinity (e.g. all CPUs to all CPUs), resolves the performance issue – at least most of the time. Our best guess is that the preferred NUMA node for the process is removed, causing the Windows scheduler to change behavior, as evidenced by the thread ideal processor selections, and more importantly the massive change in performance.

The thing is, I did not have this issue in 4.4 and still don't with any other program. 

I just confirmed it with XPlane 11.34 r1, all cores being used about equally at about 80-90%

 

[Mace 1,896]

11 hours ago, GSalden said:

It doesn’t matter if all sliders are set to the left and Locked framerate at 10 , core 0 ( main thread ) has  100% load.

Wow.  In 4.4 that was not normal with a frame limit/vsync -- and was very bad for smoothness.

Have you tested with 4.5 and confirmed that it is stuttering?  Or is it at 100% load yet smooth?

 

[pracines 823]

4 minutes ago, Mace said:

Wow.  In 4.4 that was not normal with a frame limit/vsync -- and was very bad for smoothness.

Have you tested with 4.5 and confirmed that it is stuttering?  Or is it at 100% load yet smooth?

 

11 hours ago, GSalden said:

Therefore I started to test with my 2 pc’s and found out that with Locked framerate , regardless of the settings , the main core shows a load of 100% which causes micro stutters ..

[Bert Pieke 7,584]

5 minutes ago, pracines said:

The thing is, I did not have this issue in 4.4 and still don't with any other program. 

I just confirmed it with XPlane 11.34 r1, all cores being used about equally at about 80-90%

 

XPlane is different... always has been.. 

[Mace 1,896]

1 minute ago, pracines said:

 

I saw that paul -- I meant (big) stutters aka pauses.  But microstutters will do, too.  That's bad enough.

[Bert Pieke 7,584]

48 minutes ago, GSalden said:

Already posted this at the LM forum with a link to this thread.

Please post your experience too as it will help . Thanks !

Here the link : http://www.prepar3d.com/forum/viewtopic.php?f=6312&t=133690

 

Just to clarify what we are discussing here...

P3D always has loaded up the first Core, maybe not to 100% but certainly to 90% when the VC cockpit is showing..

Are you now at a solid 100% all the time, even in exterior view??

For what it is worth, I am finding that V4.5.1. runs very smoothly on my system..

 

[Bert Pieke 7,584]

6 minutes ago, Mace said:

I saw that paul -- I meant (big) stutters aka pauses.  But microstutters will do, too.  That's bad enough.

Big difference here.. Scenery loading pauses, where the display stops for a fraction of a second or longer, are one thing and common, especially in heavy scenery like Orbx SoCal...

Microstutters while flying, especially when looking out to the side, aka "Fluidity" or lack there of, are what I thought we were discussing.. No?

Edited May 16, 2019 by Bert Pieke