P3D running but CPU not running at max speed

[Nyxx 6,993]

13 hours ago, Dirk98 said:

David, for a 4-Core CPU if using HT it is "advisable" to put prepar3D.exe on 4 cores as follows:

11.11.10.10 (JobScheduler 250)

All other apps that you are running on the same PC are "advisable" to put on 2 LPs from different Cores on the left each as follows:

10.10.00.00 (JobSch 160) and 01.01.00.00 (JobSch 80) only

So you can assign ASP4 10.10.00.00 Affinity (160) and MCE or RC4 or GoFlight, or TrackIR 01.01.00.00 Affinity (80). Also note, that it's better when each app runs on a pair of LPs from 2 different Cores, and those Cores should be those on the left as far as possible from the first 2 very busy Cores on the right. As we have learnt the most important first 2 threads of P3Dv4.4 should run on the first 2 dedicated Cores on the right. Something along these lines for a 4-Core CPU HT On.

1

Hi Dirk,

I would like to discuss this because I would like to understand it more.

Firstly I did another flight last night with 01,01,01,01 for 4.4 and all apps on 10,10,11,10. I also did my normal FPS test and found I have gained 7-10% FPS. Very happy with this setup.

My PC shows 4.4 is running really nicely with these setting. 

What I don't understand and would like you to explain so I understand the logic behind it, is how the setting you post work or more importantly could/should work better.

Let's start with 11.11.10.10 (JobScheduler 250) This takes P3D off the first two main cores but leaves it using the first two HT LP's. I have read many times that taking P3D off the "0" is a good idea but why off "2" also?

What I really don't understand is 10.10.00.00 (JobSch 160) and 01.01.00.00 (JobSch 80). This looks like a really weak way to run apps. 01.01.00.00 looks better, but when I tried cutting down chaseplane and ProATC to this kind of set up 10.10.00.00 . The sounds were broken and got mico stutters. You also say place some apps on xxxxx and some on xxxx. How would you decide what goes on what?

Lastly 11.11.10.10  the two red highlighted cores are now not tasked to p3d or any apps, why? You say move apps away from the right as they're doing all the work, but they're not because the AM has cut off the two main cores "0" & "2"

Please enlighten me.

Edited January 17, 2019 by Nyxx

[Dirk98 354]

1 hour ago, Nyxx said:

11.11.10.10 (JobScheduler 250) This takes P3D off the first two main cores but leaves it using the first two HT LP's. I have read many times that taking P3D off the "0" is a good idea but why off "2" also?

No, quite on the contrarty. By using 11.11.10.10 (or 11.11.01.01 for that matter) you arrange Prepar3D.exe's first 2 main and very demanding threads to run on 2 first Cores exclusively. Wether it is .01 or .10 LPs they are still physical part of a whole Core, so you are not taking P3D off these cores. Only .00 AM makes them unaccessible to P3D. I don't know what might be the difference between the use of .01 or .10 AM, but some posts on avsim mentioned the improvement of fluidity and fps with .10 AM version, so it's worth trying out.

Edited January 17, 2019 by Dirk98

[Dirk98 354]

1 hour ago, Nyxx said:

What I really don't understand is 10.10.00.00 (JobSch 160) and 01.01.00.00 (JobSch 80). This looks like a really weak way to run apps. 

My apps do run very well on those 2 pairs of LPs (from different Cores). This is how I arrange to run EZDOC (10.10.00.00), TIR (01.01.00.00), GF (10.10.00.00) and UTL (01.01.00.00) plus others (virtuali, and a few others for jetways etc). But mind you most of my other exe-s run on a netwroked PC, including ASP4, PATCX, PF3, Little Map and many others. 

[Dirk98 354]

1 hour ago, Nyxx said:

Lastly 11.11.10.10  the two red highlighted cores are now not tasked to p3d or any apps, why? 

Wrong, as mentioned already those 0s are LPs of the same cores where p3d is allowed already by 1 LPs. This is just a way to arrange P3D main threads in a special dedicated way. I have no idea about the science or engineering behind.

Regards,

Dirk.

[Dirk98 354]

1 hour ago, Nyxx said:

What I really don't understand is 10.10.00.00 (JobSch 160) and 01.01.00.00 (JobSch 80). This looks like a really weak way to run apps. 01.01.00.00 looks better, but when I tried cutting down chaseplane and ProATC to this kind of set up 10.10.00.00 . The sounds were broken and got mico stutters. 

For those "heavy" apps like Chaseplane and PATC I would allow them both 11.11.00.00 Affinity. I'm sure 2 pairs of LPs for these 2 apps should be enough for them.

 

[Nyxx 6,993]

Hi Dirk,

Thank you for all the above.

[Dirk98 354]

Before even making fps and fluidity tests always check Task Manager first!! You should make sure that Task Manager shows your exe-s running on the specific LPs that you targeted in your launching bat files (or similar). Open Task Manager go to Details TAB, select your targeted exe-s (one by one), right-click, select Set Affinity and see the boxes that are checked or unchecked. This is very important to make sure your actual experiments are in line with your experimental set up that you want to try out practically.

Edited January 17, 2019 by Dirk98

[Nyxx 6,993]

2 minutes ago, Dirk98 said:

Before even making fps and fluidity tests always check Task Manager first!! You should make sure that Task Manager shows your exe-s running on the specific LPs that you targeted in your launching bat files (or similar). Open Task Manager go to Details TAB, select your targeted exe-s (one by one), right-click, select Set Affinity and see the boxes that are checked or unchecked. This is very important to make sure your actual experiments are in line with your experimental set up that you want to try out practically.

Am on W7 and I set all Affinity through task manager, The ones that start with P3D need changing as they show are using the same AM as P3D so I change them. So Yes I make sure everything is using what I won't.

 

BTW you say that even when 11.11.10.10 P3D is still using the red ones, but when I fire up P3D with AM 85 01,01,01,01 only the "1" cores in task manager show are working all the "0'" show nothing. So I still dont understand how P3D can be using a core that in task manager is showing nothing happening worth talking about.

[Dirk98 354]

23 minutes ago, Nyxx said:

BTW you say that even when 11.11.10.10 P3D is still using the red ones, but when I fire up P3D with AM 85 01,01,01,01 only the "1" cores in task manager show are working all the "0'" show nothing. So I still dont understand how P3D can be using a core that in task manager is showing nothing happening worth talking about.

Task Manager shows the AM arrangement in the first place, so no worries 10.10 Cores also accommodate the exe because there are parts of these Cores where P3D is allowed by LPs 1-s.

 

POST CORRECTED

 

 

Edited January 17, 2019 by Dirk98

[Dirk98 354]

Use of batch files for launching P3D and your apps is much preferrable, I'll post some examples when I'm at my PC.

Edited January 17, 2019 by Dirk98

[AnkH 2,267]

17 hours ago, Nemo said:

I've made a batch file for UTL. Maybe you can adopt it for UT2? I run the batch after P3D has reached the Opening Screen.

Ok, I did remove UT2 out of my exe.xml and started it manually via .bat file. This works, the correct cores are used. However, I see no benefit at all (rather surprising), in contrast, when UT2 fires up and loads the traffic initially into the sim, it takes about 10 seconds and the P3D window gets the "not responding" tag. As soon as the traffic is loaded, the FPS are identical to the situation when UT is started via exe.xml on my rig. Additionally, when starting UT via exe.xml, the initial loading of AI traffic after P3D fired up takes only about 2 seconds and no "not responding" message.

Verdict: on my rig, running UT2 on specific cores started outside the exe.xml has absolutely no benefit at all. Now I am back to the exe.xml startup procedure...

[Pete Dowson 558]

46 minutes ago, AnkH said:

Verdict: on my rig, running UT2 on specific cores started outside the exe.xml has absolutely no benefit at all.

I suspect that, as with UTL, the main time is spent in sending the aircraft references, plans, and positions to P3D, via SimConnect. So it may well be better off running in the same cores as those parts of P3D.

Pete

 

[Cruachan 705]

53 minutes ago, Pete Dowson said:

I suspect that, as with UTL, the main time is spent in sending the aircraft references, plans, and positions to P3D, via SimConnect. So it may well be better off running in the same cores as those parts of P3D.

Pete

 

Hi Pete,

Could it be that the developers intended this behaviour? In Process Lasso I noted (and mentioned previously in this thread) that UTLive had adopted/been assigned the same Affinity as I had specified for Prepar3D.exe in Prepar3D.cfg. So far, I haven’t identified any downsides.

If this is true then tuning the sim to ensure the main thread activity/load is maintained below 100% should help mitigate against UTLive triggering any performance issues.

Regards,

Mike

[SteveW 1,792]

1 hour ago, Cruachan said:

Hi Pete,

Could it be that the developers intended this behaviour? In Process Lasso I noted (and mentioned previously in this thread) that UTLive had adopted/been assigned the same Affinity as I had specified for Prepar3D.exe in Prepar3D.cfg. So far, I haven’t identified any downsides.

If this is true then tuning the sim to ensure the main thread activity/load is maintained below 100% should help mitigate against UTLive triggering any performance issues.

Regards,

Mike

 

2 hours ago, Pete Dowson said:

I suspect that, as with UTL, the main time is spent in sending the aircraft references, plans, and positions to P3D, via SimConnect. So it may well be better off running in the same cores as those parts of P3D.

Pete

 

Simply put, any apps started by an app with affinity are started within that affinity.

Remember that I said that the first LP found available in the AM is core zero to that process.

So if you make P3D start with an affinity then any apps *it starts* do in turn, have that affinity by definition. And their AM acts according to the available LPs there. presented.

The idea that fps might change is not what you are doing, you a re freeing up resources . Once your main thread is running on the main core there's very little more fps you can get after that because it is that task that has to fit all the things in the time between frames.

Moving the exe out of P3D is a good idea and will show results.

The thing about simconnect clients is that they are within the affinity or the calling app, the client is hosted by the server within the P3D affinity. So it still makes sense to move it out if you can be bothered. You won't see any more fps if there's none to give, you're looking to accelerate the background process.

 

Edited January 17, 2019 by SteveW

[SteveW 1,792]

So no, utlive is simply set up to work slickly, it's got nothing to do with the P3D AM as I said that's just forced onto utl by the P3D AM. How the affinity is handled is up to us.