Yes Richard, unfortunately some apps don't take kindly to being moved around. How are you setting ProATC affinity?

I removed it altogether for now but it does seem strange that an EXE that works on a 4 core system has a hard time on a 6 core reduced to 4 core. I did put ASN is on on 2698.

Could be the affinity isn't changed fully until after the app has started, and it may not work as expected.

This is (was) a truly interesting thread, mainly about the proper affinity mask to be used. Thanks for SteveW's great contribution to the subject.
Unfortunately when I went through the thread I found that a very important factor is not mentioned here. Let me sum up the problem:

1. When you start P3D with a specific affinity mask (defined in the .cfg file) it will automatically place ALL internal or external programs - started by one way or the other from P3D - will also inherit the same affinity mask.

2. Thus, if you, for instance start UT2 from the exe.xml file, apart from running in the same VAS space that P3D has, it will also inherit the affinity mask that P3D is using.
The same stands for ALL executable programs that were NOT started separately.

3. So either the exe.xml startups or the dll.xml starts will run in P3D's VAS space but at the same time will inherit the mask too.
The same is the case with programs stated via the FSUIPC startup facilities.

4. That's why Lasso or any similar prg is needed to permanently SEPARATE these programs from the actual affinity mask P3D is using, or otherwise we end up using the same cores that P3D is defined to use.

Potroh
 

 

 

Thus, if you, for instance start UT2 from the exe.xml file

 

Anything in the EXE.XML does not share VAS space with P3D, runs in it's own VAS.  That does NOT mean it will not increase VAS on P3D because it depends what the EXE is doing with P3D.

 

Anything in the DLL.XML will use P3D VAS (even when it might not be used it's initially registered).

 

But as I demonstrated earlier in this thread, P3D can still use a core (or cores) that is not defined as part of the affinity ... low usage but still present.

 

Cheers, Rob.

That's right Rob. The affinity setting defines the way the sim initially lays itself out.

SteveW,

 

i follow your recommandation about am seting in p3D, so now P3D am setting is 116, all the rest of my addon are setting via process lasso

 

on thing however, i setup texture bandwith mult @180, i have a 980TI asus strix,and i don't know if vas is link with TBM but for a standard flight 1H, vas start about 1.8gb at aerosoft lfpg with aerosoft a 320, and finish @ between 700/900MB at marseille.

 

Well, before i use this 116 setting i never finish my standard flight with a poor vas, i don'twant imagine a full long flight who i think finish by an OOM!

 

have you something for me about am setting for a better vas managment?

 

Thanks Stevew

 

 

FREDERIC

No. There's nothing you can do further to reduce VAS use through the Affinity Mask. You should look at other things.

 

 

Anything in the EXE.XML does not share VAS space with P3D, runs in it's own VAS. That does NOT mean it will not increase VAS on P3D because it depends what the EXE is doing with P3D.

Anything in the DLL.XML will use P3D VAS (even when it might not be used it's initially registered).
But as I demonstrated earlier in this thread, P3D can still use a core (or cores) that is not defined as part of the affinity ... low usage but still present.

 

Rob, you seemingly didn't get what I was trying to say.

VAS is a different thing... Let's simplify it: Whichever program is started via the exe.xml OR FSUIPC, will use the SAME affinity that P3D does.
So those programs need to have their OWN affinity, otherwise you achieve the opposite of what you wanted and those programs will ALSO use the very same affinity that P3D does.
(We who fly home-cockpits, needs quite a few external programs to run that way, and in case those were started from P3D, the opposite effect is achieved when using any affinity from within the P3D config file.)

 

Potroh

Whichever program is started via the exe.xml OR FSUIPC, will use the SAME affinity that P3D does.

That's absolutely correct. Generally, when programs start another app via the shell, that app "sees" the affinity space of the app starter program. However, programs can be specially written to start other apps to respect the affinity setting of those apps, although that's a little more complicated.

Monitoring this thread.

RMM

That's absolutely correct. Generally, when programs start another app via the shell, that app "sees" the affinity space of the app starter program.

 

Thanks for the confirmation Steve. So my next logical question is:

Say, I have to start 6 other programs on the main FS-PC (4 other clients are running, but these six programs need to be on the main one).

Four cores with HT On. I use AM = 85 for P3D.

Out of the six programs, two are using the CPU quite much, whereas the other four take much less CPU time.

So at present the CPU-intensive ones I run like: 00111111 and the less intensive ones: 00001111

 

How would you suggest masking them?

 

Potroh

4 core HT enabled, 4 LPs one per core configuration

AM=85=(01,01,01,01)=0,2,4,6 P3D

F8=248=(11,11,10,00)=3,4,5,6,7 Addons

 

None of them want to be stopping any of the sim jobs for too long. We don't start them on core zero at all, but we allow them onto core 1, but on the unallocated LP3. If they max out, on LP3, the HT will ensure they can't get too much bandwidth from that core. The second sim job shares this core, but always get's bandwidth, and doesn't require so much bandwith as the first, third, and fourth jobs. We can allocate the last two cores wholly, the jobscheduler will take care of housekeeping where there isn't HT, but mostly target LP5 and LP7 with the remaining threads starting on those programs. However, as Rob pointed out there's activity emanating outside of affinity. These programs, and the sim, use underlying resources which are firing up on all cores, targeted somewhere the jobscheduler sees fit. That's another reason to optimise the AM, we don't want extra jobs being made by the sim filling in those holes when those jobs come to nothing. With HT enabled we've got an overall improvement because we have options when it comes to sharing cores.

 

 

We don't start them on core zero at all, but we allow them onto core 1, but on the unallocated LP3. If they max out, on LP3, the HT will ensure they can't get too much bandwidth from that core.

 

Great. Absolutely clear and logical.

Many thanks Steve!

 

Potroh

Steve,

 

I have

4 core HT enabled, 4 LPs one per core configurationAM=85=(01,01,01,01)=0,2,4,6 P3DF8=248=(11,11,10,00)=3,4,5,6,7 AddonsNone of them want to be stopping any of the sim jobs for too long. We don't start them on core zero at all, but we allow them onto core 1, but on the unallocated LP3. If they max out, on LP3, the HT will ensure they can't get too much bandwidth from that core. The second sim job shares this core, but always get's bandwidth, and doesn't require so much bandwith as the first, third, and fourth jobs. We can allocate the last two cores wholly, the jobscheduler will take care of housekeeping where there isn't HT, but mostly target LP5 and LP7 with the remaining threads starting on those programs. However, as Rob pointed out there's activity emanating outside of affinity. These programs, and the sim, use underlying resources which are firing up on all cores, targeted somewhere the jobscheduler sees fit. That's another reason to optimise the AM, we don't want extra jobs being made by the sim filling in those holes when those jobs come to nothing. With HT enabled we've got an overall improvement because we have options when it comes to sharing cores.

Steve, I have 340 and my addons through process Lasso assigned to cores : 0,10 and 11.

Reading the above would it be better to use cores : 0, 3, 5, 7, 9 , 10 and 11 ? ...