Affinity Mask: An Observation

[SteveW 1,792]

The effects of hyperthreading and affinity masks and how these affect P3D (and FSX) is well understood.

 

An AM in the cfg is not enough on its own, it is also required to know what addons are doing and that they must be configured accordingly. If we've got worse performance with an AM, it is very simple, we got it wrong.

 

When we do not apply an AM, we are actually leaving the AM at default, that is with all logical processors enabled.

 

When the sim runs it splits into the same number of jobs that it finds cores (or rather Logical Processors).

 

HT enabled simply sets each core to emulate two cores by sharing the bandwidth of one core, these appear as two cores to software. HT has the advantage of reducing switching time between processes. Without an AM and with HT enabled, we get double the sim job count, two per core - unless we are using a dual core CPU, we don't want that.

 

Two equal threads running on a non HT core are comprehensively outperformed by the same two threads on an HT processor, one per LP. Both jobs on the same HT LP will perform the same as they do on the non-HT enabled core. It should be obvious we can increase the overall performance of the sim and its associated plug-ins if we know how to utilise HT properly.

 

The sim creates monolithic threads which are split into fibres. These fibres cannot benefit from HT enabled cores because they are switching within their main threads, which are running solely on one LP.

 

Addons often mean simconnect and require networking, and these are best offered improvements that HT can provide. The system will utilise HT very well when care is taken.

 

When the sim is split into four parts, the first thread job becomes leanest, with three jobs serving it. If we provide less than four LPs to the sim, the sim jobs are combined. If we do not provide an AM with HT enabled, those jobs occupy both LPs of each core, reducing the performance of each core since they are shared by monolithic threads of the sim each vying for maximum throughput when needed. When we split the sim into more than four parts, the main thread does not split out any more, but instead is put to task servicing those extra jobs, on a 4GHz class CPU these extra jobs add nothing.

 

What extra jobs do actually do is to expand the effective LP count running below the sim. When the sim uses system resources these extra LPs come into play, however when the sim is heavily set these extra jobs squeeze out the other processes on those extra LPs which is a compromise.

 

Depending on the setup these extra jobs beyond four may actually be a problem, in fact they generally are. Gerard has some good data and tested these situations very well, and came to the same conclusion.

 

So to conclude, four LPs presented to the sim means the sim gets the best configuration it can have. That's why no AM and HT disabled works very well (esp. on a four core CPU). When we have six or eight or more cores, those excess jobs beyond four are filled with sim jobs that reduce the performance of the sim main job and addons, and the system interaction with the sim. But it's not bad performance because we have allocated at least four LPs so we get the leanest main job, and we've got more cores for system processes to find holes to run in. It may be good performance but it's not the best performance.

[henry 19]

i run titan card on an I 7  3770k 3.50 ghz with windows7 , P3D version 3.1 mostly flying with NGX , dash8 400 and FSDT airports like KLAS, KLAX, CYVR, flightbeam KSFO and  ASNEXT for weather. i have never turned on HT . what would you suggest for AM? i have it set to 0. running the sliders pretty much in the middle i only get 14 frames at FSD vancouver with occasionnal stutters when heavy overcast.

 

henry

[SteveW 1,792]

The first sim job takes maximum bandwidth often so we try to ensure addon activity does not utilise that core. The second sim job does not often require maximum throughput, so we can put an addon there. Job three often draws maximum use of a core, and job four usually slightly less than that. So we can put addons on the same core as job four, and at a push we can put addons on the core with job three as well. A good rule of thumb is to allocate at least two LPs per exe. If we only allocate one, test that addon thoroughly especially if it's a simconnect client.

 

Let's look at four cores HT off no AM - we have LPs 0,1,2,3 and the sim on all four LPs, main sim thread on LP0:

addons should be kept off of LP0, so allocate two LPs to each addon from LPs 1,2,3.

 

Now with four cores HT on we have LPs 0,1,2,3,4,5,6,7, remember that 0 & 1, and so on, are sharing a core so we allocate an AM=85=01,01,01,01 (or 170=10,10,10,10) to more or less replicate the HT Off situation. However addons without AM support will utilise these as if they are regular cores and double the thread count on each HT core. So with AM=85 we might assign addons to LPs 3,5,7. Notice 3,5,7 are also the brother LPs of the LPs utilised by the sim 0,2,4,6.

 

Regarding the differences with P3D v3.2, this version handles sim job counts beyond four slightly better now. So if we allocate five LPs to the sim, this will reduce the performance less with P3Dv3.2, than with earlier versions of P3D (and FSX).

[David Roch 1,980]

Steve, with HT off and no AM, would you suggest limiting the fps externally (NI)?

Thanks ;-)

[SteveW 1,792]

There can be problems when limiting P3D fps with NI with certain GPU/driver versions so it's got to be tested on a per system basis, depends on GPU/Monitor/Interface cable etc.

 

We use particular settings for GPU functions when testing for performance, and so as when we are testing an AM. We are looking for the best possibility of throughput with our CPU and addons. We would usually unset certain GPU functions, like limiter, AA and VSync, so we don't get these effectively limiting the performance during testing. Once we are sure the sim keeps the best fps/stability across the broadest of scenarios, we can then apply AA and VSync, or maybe a Fixed fps, and so on, to obtain our best image quality. When looking for top performance we might have a less than desired setup for viewing and running the sim.

[Jim Young 2,356]

If members think it works well for them, let it be.  If members think it does not work, like me, then let that be.  Everyone is therefore happy.  But, if one who has tweaks such as the AM and has unexplained crashes, then this should be their first clue.  Rebuilding the FSX.cfg (not sure yet about the P3D.cfg) is well known as the best fix for most crashes.

[SteveW 1,792]

What does not work for you Jim?

[Jimm 437]

Before everyone starts flexing their brains, I should clarify that my post was intended not to start a tweak war, nor a Ken Burns documentary about the bits and bytes of coding.  I've seen a lot of discussion lately about the use of AM and I came forward to inform others who weren't sure whether to use it or not, that it's usage on my machine actually was not any more effective than without.

 

I honestly do not see any negative implications in not using the AM setting line in my cfg.  I'm not saying I'm an exception to the rule, just that AM may not be that proverbial magic bullet that a lot of people are looking for.

 

As far as solutions to crashes, it's much easier to backtrack when you keep track of whatever you set differently than from what you had.  Sage advice was given a long time ago by trusted sources that when it comes to setting up your sim, make one change at a time and then test, so if things go south, you'll know immediately what it was that caused the issue...simple as that.  The same thing goes for setting changes to external sources.

 

I have now given up trying to figure it all out.  It's like that gift horse in not looking in his mouth.

 

-Jim

[SteveW 1,792]

It is not about whether "it works" (whatever it is) or not, it's about how to use stuff. If you got a tray that can handle four drinks, it's a waste of time comparing it to a tray that can handle six, other than you only got space for four. People chiming in with stuff about whether it works for them or not without any technical data are blurring the subject back into the realms of mysticism. HT works, and AMs are a necessary fact of life.

[Jimm 437]

It is not about whether "it works" (whatever it is) or not, it's about how to use stuff. If you got a tray that can handle four drinks, it's a waste of time comparing it to a tray that can handle six, other than you only got space for four. People chiming in with stuff about whether it works for them or not without any technical data are blurring the subject back into the realms of mysticism. HT works, and AMs are a necessary fact of life.

Then if AM is necessary, how come LM hasn't released instruction concerning it's usage, and how it needs to be set for every user?

 

-Jim

[SteveW 1,792]

 

...if anyone says 'it depends on the diameter of the glasses', that's quite correct. So if you can do it with drinks, then why not cores.

 

 

 

Then if AM is necessary, how come LM hasn't released instruction concerning it's usage, and how it needs to be set for every user?

 

-Jim

 

here's something from the P3D documentation:

 

By default, Prepar3D will use all available processor cores. On machines with four or more cores, it will dedicate a core to rendering tasks.

[Jimm 437]

With all due respect Steve, but I for one fail to understand your analogies.  I guess I am now wondering when you will get to the point of your responses.  Am I to assume that you are saying that the affinity mask setting, placed in the P3D.cfg file NEEDS to be there, regardless of a given user's setup, add-ons and everything else?  If this is the case, then why hasn't LM released a statement stating as such?

 

My question is not to dissimilar to the issue with the highmem fix for FSX.  We were told a long time ago that it was needed because the devs at Aces forgot to add it.  I can totally understand that logic and I never took issue to it.  It was needed, they forgot, we were now told to add it, case closed.

 

I am personally not as code literate as you, and the explanations about ones and zeros and backwards hexidecimal codes is not getting me anywhere.  I honestly don't know what more I can say about the fact that not having AM active in my cfg is not hurting my sim in the least.  I know I am running a lot less than others for add-ons and maybe that's why I don't have any problems but telling me it is necessary is like you are forcing me to use it or else bad things will happen.

 

-Jim

[SteveW 1,792]

P3D has a default AM, on a four core it's 15, on 8 it's 255. It's up to you to grasp all that stuff. I'm happy with HT and core affinity, and these technologies are being wielded by apps with no problems. I'm just dropping knowledge onto you.

[newtie 533]

P3D has a default AM, on a four core it's 15, on 8 it's 255. It's up to you to grasp all that stuff. I'm happy with HT and core affinity, and these technologies are being wielded by apps with no problems. I'm just dropping knowledge onto you.

Hi Steve-

 

Am=116 works really well for me and I've tested that against the stock AM along with a few others.

So, score one for AM use!

[SteveW 1,792]

Thanks newtie, 116 is a cool number for four core CPUs with HT. I mean, here's an example where we have a balance of addon activity with the sim. 116 utilises three cores, 1,2,3, but splits the sim into four thread jobs to produce the lean main thread doing the rendering, leaving the first core 0, for the jobscheduler to fill with addon activity. It's basically a more refined version of using AM=14 on a four core with no HT.