Hasn't P3D always utilized core0 to nearly 100% in most cases?  As far as I can remember, it goes back to P3Dv3 or even earlier. If the GPU is underutilized, it means that the CPU is the limiting factor and the GPU doesn't need to work so hard to process the frames per second.

7 minutes ago, Afterburner said:

Hasn't P3D always utilized core0 to nearly 100% in most cases?  As far as I can remember, it goes back to P3Dv3 or even earlier. If the GPU is underutilized, it means that the CPU is the limiting factor and the GPU doesn't need to work so hard to process the frames per second.

I mentioned it earlier but I remember this back to FS9...  It was the only program I ever launched that sent CPU to 100% and kept it there until you shut down the .exe   I figured that's never changed.  

26 minutes ago, Afterburner said:

Hasn't P3D always utilized core0 to nearly 100% in most cases?  As far as I can remember, it goes back to P3Dv3 or even earlier. If the GPU is underutilized, it means that the CPU is the limiting factor and the GPU doesn't need to work so hard to process the frames per second.

But not 100% for most of the time on my setup. Because I impose a limit of 30fps (30Hz set on the monitor with VSync enabled) there were plenty of times in v4.5 and v5.1 when the CPU Core0 was not at 100%. If I turned VSync off and had 60Hz set on the monitor then I could unerstand core0 being maxxed out because of my demands. B. Core0 ut look back to yesterday when I set all scenery to off. Core0 still hit 100% when there was very little scenery to render. I don't understand why.

I've been using MSI Afterburner and RTSS to monitor CPU and GPU usage and it's extremely useful.

The GPU would hit 100% in heavy cloud and with the lights of my Xtreme Prototypes Lear25 on. But that only occured at a few airports and in 4K. Drop to HD and all was well. That's an issue with the Lear25 though, not generally.

When flying at FL350 in the PMDG737 the CPU0 was rarely hitting 100%. For some unknown reason it is now and the only change has been v5.2.

@Ray ProudfootOne thing I most certainly agree with you on here.  Performance to me is worse than 5.1.  I followed all the recommended installation guides and insured my cfg and both shader folders were deleted.  

@micstatic, thanks. I can understand why it must be a nightmare for LM when some people say 5.2 is fine and others have a different opinion. With all the variables involved it can't be easy finding and solving these problems especially when LM have  virgin builds and we have so much 3rd party installed.

I used SimStarterNG to define my Affinity Mask. Core 0,2,4,6,8 and 10 were selected and the rest unchecked. Core0 would be maxxed out. I'm currently enroute from Belfast to Dublin in a PC12 so the demand is low. But changing the AF to 1,3,5,7, 9 and 11 is producing this. I'll see how it copes with more demanding scenery.

Incidentally, I know this is still using six cores and six VPs. Just wanted to try something different. Core 10 is running associated low-demand software.

41 minutes ago, Ray Proudfoot said:

I used SimStarterNG to define my Affinity Mask. Core 0,2,4,6,8 and 10 were selected and the rest unchecked.

Using SIMstarterNG to define P3D's Affinity Mask might also be not the best way to launch Prepar3D.exe as SteveW used to explain. Because there is an internal facility to allocate cores in Prepar3D.cfg under [JobScheduler], you may wan to try that as well and see the results. Therefore in SIMstarter instead of setting AM in Run ConfigSet section I went to Sim ConfigSet then Open in editor... and added [JOBSCHEDULER] section to Prepar3D.cfg with the following AffinityMask=21845 (01.01.01.01.01.01.01.01 LPs for my 8-core HT On i9 9900K, your calculated value for AM should be in decimal format) 

PS: if you'd like I can give you the value you want in Dec format, just give me what you want in Hex or Binary

PPS: In my case in Run ConfigSet section no AM selected and no boxes ticked for Prepar3D.exe

 

Edited June 15, 20214 yr by Dirk98

I don't know how SIMStarter works and have not tried it, so it may be that app takes relevant precautions when starting the simulator. Generally, one program that is started by another will inherit the core affinity of the starting app unless certain precautions are taken.

11 minutes ago, SteveW said:

I don't know how SIMStarter works and have not tried it, so it may be that app takes relevant precautions when starting the simulator. Generally, one program that is started by another will inherit the core affinity of the starting app unless certain precautions are taken.

It is safest to use the provided internatl facility [JOBSCHEDULER] in Prepar3D.cfg init?

Edited June 15, 20214 yr by Dirk98

I would check with SIMStarter instructions, but from Ray's post and screenshots it does seem to do it's job of enabling the AM correctly so that the jobscheduler statement seems not to be required in that case. However the way Prepar3D initialises its use of cores I would definitely check that the simulator is running right.

Just now, SteveW said:

I would check with SIMStarter instructions, but from Ray's post and screenshots it does seem to do it's job of enabling the AM correctly so that the jobscheduler statement seems not to be required in that case. However the way Prepar3D initialises its use of cores I would definitely check that the simulator is running right.

Well, you can use Proccess Lasso as well, but you don't know exactly how it allocates LPs at runtime or elsewhen. Therefore I prefer the stock facility as I explained earlier.

Yes, good idea to prefer the simulator config setting for AM.

I've been trying a few things in 5.2 regarding LP 0 being maxed out. Basically with low settings and the Nvidia Control Panel Prepar3D.exe profile set to limit frames to 28 fps on my 60Hz monitor I am seeing around 50% LP 0 use. I can increase graphics settings in the Prepar3D UI and that use climbs up. With very high settings it will reach 100%. Also by increasing the fps limit the same thing happens the LP 0 use will increase with that until it reaches 100%. After it reaches 100% it is not known how exactly how much demand is placed on it with increased graphics settings (or increased AI Traffic etc.)

So if I was comparing 5.2 to core use with 5.1 it may be that some slider settings impart increased core activity with the same setting and the simulator might not show the same core use.

The use of some external frame limiters might also show the LP 0 use to be 100% when the LP s not actually utilised that much and the discrepancy can be due to how performance counters are interpreted by Task Manager and other performance counting apps.

Did anyone check the CPU load just before updating to v5.2 ?

I did as I had several Windows updates installed. Another H update amongst them.

See the core load on both pc’s.

Three months ago I did the same test and the main cores were 90-100% and the terrain cores 30-60%.

So hoe sure are we that not a Windows update has something to do with this ?

@Dirk98, I'm happy to give JobScheduler a try and see if it's any different to how SSNG does it. I run several executables such as LittleNavConnect, ASP3D, Aivlasoft's EFB server and other minor things and tend to stick all those on a different logical processor.

I have a 12 logical, 6 core CPU. If I enter 010101010101 it gives 1365. Alternatively, 101010101010 gives 2730.

Can you provide what you consider the optimum entry, thanks.

 

1 minute ago, Ray Proudfoot said:

@Dirk98, I'm happy to give JobScheduler a try and see if it's any different to how SSNG does it. I run several executables such as LittleNavConnect, ASP3D, Aivlasoft's EFB server and other minor things and tend to stick all those on a different logical processor.

I have a 12 logical, 6 core CPU. If I enter 010101010101 it gives 1365. Alternatively, 101010101010 gives 2730.

Can you provide what you consider the optimum entry, thanks.

 

Ray, 

To make sure I get your right: Do you set AM for Prepar3D.exe in Run ConfigSet section of SIMstarter currently? If so - try to untick all Core boxes there and go to Sim ConfigSet Open in Editor.. add [JOBSCHEDULER] section and under it: AffinityMask=1365 to edit directly Prepar3D.cfg. When you set it there run SIMstarter, launch Prepar3D.exe and check AM allocation in Task Manager first to make sure all is good.

Hi Dirk,

I'd forgotten about that section in SSNG. I calculated it and googled how to enter it in p3d.cfg. So it's there at the moment with 1365.

This shows what RTSS is reporting. Remember it has a base of 1, not 0 so deduct 1 from each value for the actual vp.