GSalden

V4.5 : what has happened to Locked framerate ?

Recommended Posts

Posted (edited)

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.

 

Edited by LecLightning56

Share this post


Link to post
Help AVSIM continue to serve you!
Please donate today!

You can always use the Windows Task Manager to set/change Affinity for the Prepar3d process in real time..:cool:

Share this post


Link to post
14 minutes ago, Bert Pieke said:

You can always use the Windows Task Manager to set/change Affinity for the Prepar3d process in real time..:cool:

I cannot pretend to understand the nerdy gobbledygook associated with how CorePrio works except that it works dynamically rather than using permanent affinity settings. This is something that Windows Task Manager cannot do.

My conclusion for my own particular system is that it is this dynamic behaviour which works the magic, presumably making reference to core 0 as and when the load on the system demands it (a dynamic affinity).

Share this post


Link to post
13 minutes ago, LecLightning56 said:

I cannot pretend to understand the nerdy gobbledygook associated with how CorePrio works except that it works dynamically rather than using permanent affinity settings. This is something that Windows Task Manager cannot do.

My conclusion for my own particular system is that it is this dynamic behaviour which works the magic, presumably making reference to core 0 as and when the load on the system demands it (a dynamic affinity).

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 

Share this post


Link to post

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.

Share this post


Link to post
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%.

Share this post


Link to post
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. 

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
Posted (edited)
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 by LecLightning56

Share this post


Link to post
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

  • Like 1
  • Upvote 1

Share this post


Link to post
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?

Share this post


Link to post
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%

 

Share this post


Link to post
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?

 

Share this post


Link to post
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 ..

Share this post


Link to post
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..  :wink:

Share this post


Link to post
1 minute ago, pracines said:

 

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

Share this post


Link to post
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..

 

Share this post


Link to post
Posted (edited)
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 by Bert Pieke

Share this post


Link to post
Just now, Bert Pieke said:

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, ala "Fluidity" or lack there of, are what I thought we were discussing.. No?

My concern was (and it wasn't fully clear in this thread) that 4.5's cpu usage also induced pauses as well.

If it does not, that is good, I can focus on microstutters solely.

Share this post


Link to post
1 minute ago, Mace said:

My concern was (and it wasn't fully clear in this thread) that 4.5's cpu usage also induced pauses as well.

If it does not, that is good, I can focus on microstutters solely.

There are just a lot of imprecise observations being offered up here.. 

  • Upvote 1

Share this post


Link to post

 

58 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.

Confirmed, thank you.

I never had to do this before in V4, before 4.5 - I think somebody would have caught  this long ago.

Share this post


Link to post
Posted (edited)
1 hour 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.

I only do understand a small percentage of the tech speak, however, isn't that equivalent to the age-old trick to open Task Manager, deactivate core 0 (or any other one) of Prepar3d, quit, open it again and reenable core 0. Which Lockheed Martin's Beau Hollis decidely adviced against as it would destroy the intended Prepar3d task handling?

Kind regards, Michael

Edited by pmb
  • Upvote 1

Share this post


Link to post

@pmb I've never seen that article so its very hard for me to agree. What I will confirm is that this method has given me a few frames and smoothness (the latter being subjective of course).

 

I'll try to find some time to execute a flight with the method I posted and without to see how it goes.

 

Thank you for the head's up!

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now