3 minutes ago, KL Oo said:

Thanks Steve - a good explanation.

Yes, you understand it fully. 👍

Let's look at the case of not using an AM in the config, but instead after the simulator has started up, and then unchecking CPU checkboxes in Task Manager, Details, Set Affinity.

The sim has already allocated those pinned tasks when it started up, one per core or LP.

When we uncheck a CPU checkbox in Details, Set Affinity, the task is moved by the JOBSCHEDULER on to a convenient core or LP that still has a check in the box.

The question is where does that task get moved to?

If that task is moved on to core 0, that main task of rendering is now sharing with the moved task.

That is why using Set Affinity is not a good idea for testing. Always use the  [JOBSCHEDULER] AffinityMask setting in the Prepar3D.cfg.

1 hour ago, KL Oo said:

Thanks Steve - a good explanation.

The reason HT OFF has always worked for me makes sense based on what you've indicated above. That said, if HT is OFF then as I understand it the main rending task is being undertaken on CORE 0 with subordinate tasks taking place on as many other cores as P3D chooses to use. 

So if thats the case then as you say, it really is a case of trying different combinations to see what works best, but it would seem the most common use for the AffinityMask option is if one wishes to leave HT enabled on their system but still ensure P3D is only utilising on LP per core, not too. Which is what I understand Ray is doing.

 

Cheers,

 

If you don't use HT and your CPU is max 8 cores - then you don't need AM for Prepar3D.exe at all. But it is a good idea to move all of your flight sim related exes to the senior cores, give each exe 2 cores minimum - is a good practice.

Only when your CPU core count is unreasonably high lol being 12-16 then cut off the excessive ones with a corresponding AM for Prepar3D.exe.

 

PS: is what I've gleaned from SteveW's lectures on the subject over the years )) and confirmed by my own observations locally.

Edited June 22, 20214 yr by Dirk98

22 minutes ago, Dirk98 said:

is what I gleaned from SteveW's lectures on the subject over the years )) and confirmed by my own observations locally.

Going back a long time when FSX came out I initially built a complex test system that more or less guaranteed the same flight parameters for each test, mainly from replaying a saved flight file. This was collecting various samples to generate results in an excel format and then computed for various readings and to generate fair comparisons.

With a standard system without an extreme overclock, HT enabled and the right AM produced the best results. HT disabled was always a little less performance. HT enabled with no AM always worse performance, giving HT a bad name.

Since then I put the testing function capability into Ideal Flight Pro so it can be used to do the same careful tests and to compare results with its graphing facilities. Flying in the sim and looking for differences is very hard to get serious comparisons. Using the wrong settings for the CPU will reduce the performance of the P3D or FSX simulator.

37 minutes ago, Dirk98 said:

But it is a good idea to move all of your flight sim related exes to the senior cores, give each exe 2 cores minimum - is a good practice.

Ideal Flight was the first addon to deliberately use cores away from the main simulator cores and need not be assigned affinity from another program or batch file, just as we do with P3D and FSX we use the simulator affinity mask setting in the cfg file to allow it to do its own job properly. Also it was during testing with Ideal Flight performance monitoring that I found that some addons even though they only use a few percent of a core throughput, could cause performance loss with allocating only one LP, we now use two LPs minimum per exe.

2 hours ago, Dirk98 said:

If you don't use HT and your CPU is max 8 cores - then you don't need AM for Prepar3D.exe at all. But it is a good idea to move all of your flight sim related exes to the senior cores, give each exe 2 cores minimum - is a good practice.

Only when your CPU core count is unreasonably high lol being 12-16 then cut off the excessive ones with a corresponding AM for Prepar3D.exe.

 

PS: is what I've gleaned from SteveW's lectures on the subject over the years )) and confirmed by my own observations locally.

My experience is a little difference than yours.

What I have read in all those years and my experience with my former 5820  6 core processor, my 8700k  6 core processor and my 7940 x  14 core processor :

- up to 8 cores HT can add a positive effect

-  10 cores and more runs better without HT

What I do agree on with you is that using an AM can help with stability.
My 7940x uses the first 13 cores for P3D. The last core is for addons only . The Addons also are allowed to use core 2 + 4. 
 

Regarding the 8700k I do not use an AM for P3D but the addons do and use core 2 + 4.

The systems have been tested with less and more cores and what I have described above works the best for them.

 

 

4 hours ago, SteveW said:

That is, when they start up they 'look' at the CPU to 'see' the number of cores and allocate a task for each core. Those tasks are pinned to the core they are started on.

Has anyone from Aces/LM actually said this?

AffinityMask was introduced in FSX SP2 (?) and as best I can tall it just involves taking the mask value directly and calling SetThreadAffinityMask (which is a Win32 API function) on the created thread (there may be a way to do it on start, I'm not a Win32 expert). P3D appears to call SetProcessAffinityMask on itself which the threads then inherit which is why you can see the affinity mask settings in Task Manager.

I'd be surprised if FSX rolled its own thread scheduler into a service pack, and if they did why Phil Taylor wouldn't have said a peep. The complicating aspect of course is this notion of Fibers which seems like a failed Win32 experiment.

Cheers

The "Tasks" I mentioned are not "threads" hence I didn't say threads.

It is a simple matter to put extra work onto LP0 and see the simulator performance come down. By putting extra work on other LPs the background process slows. That is the basis of the what we are saying about AMs in P3D.

...and in the case with HT enabled it is a simple matter to put extra work on LP1 and see the performance come down. That extra work can be from allowing the simulator to put the second Task on LP1 which brings down the performance in that way. Tasks are made up of several threads.

I've only just moved over to 5.2,but prior to moving I raised some questions here as my core 0 was at 100% continuously.

So I decided that I might as well move to 5.2 and tweak that instead I have read this thread a few times and watched a couple of youtube  videos to get a handle on things a bit.

I'm running a 5950x  and using process lasso i've been having some interesting results (for someone thats not sure what he's doing ). I have been trying various options with moving things onto different cores but must p3d be ran on core 0?

the reason I ask is that using ryzen master, it tells me that my best cores are 4 and 13 and the second best are 6 and 14.

Is there any reason why I could not use these cores initially and if need be then ad core 0 and 1 if required? 

with some of the trial and error approach i've been doing I can have core 0 at almost 0 but some of the other cores are nudging 100% at times.

just using an affinity mask didn't initially do any good that I could see as core 0 stayed at 100%

32 minutes ago, Luke said:

Has anyone from Aces/LM actually said this?

AffinityMask was introduced in FSX SP2 (?) and as best I can tall it just involves taking the mask value directly and calling SetThreadAffinityMask (which is a Win32 API function) on the created thread (there may be a way to do it on start, I'm not a Win32 expert). P3D appears to call SetProcessAffinityMask on itself which the threads then inherit which is why you can see the affinity mask settings in Task Manager.

I'd be surprised if FSX rolled its own thread scheduler into a service pack, and if they did why Phil Taylor wouldn't have said a peep. The complicating aspect of course is this notion of Fibers which seems like a failed Win32 experiment.

Cheers

So what we are saying is simply that when the simulator starts up the rendering process is part of the first task. Through the AM configuration this first task appears on the first available LP or core unmasked in the AM. This first core is running the main task that affects the rendering performance directly. This behavior most observe in their tests. I use the term "task" as a simplified way to visualise the behavior. How the program is subdivided into threads and how that is handled by the jobscheduler is not our concern.

 

3 minutes ago, mazelda said:

I've only just moved over to 5.2,but prior to moving I raised some questions here as my core 0 was at 100% continuously.

So I decided that I might as well move to 5.2 and tweak that instead I have read this thread a few times and watched a couple of youtube  videos to get a handle on things a bit.

I'm running a 5950x  and using process lasso i've been having some interesting results (for someone thats not sure what he's doing ). I have been trying various options with moving things onto different cores but must p3d be ran on core 0?

the reason I ask is that using ryzen master, it tells me that my best cores are 4 and 13 and the second best are 6 and 14.

Is there any reason why I could not use these cores initially and if need be then ad core 0 and 1 if required? 

with some of the trial and error approach i've been doing I can have core 0 at almost 0 but some of the other cores are nudging 100% at times.

just using an affinity mask didn't initially do any good that I could see as core 0 stayed at 100%

Start with very low settings so that the cores are not reaching 100%, shown in Task Manager graphs. Then gradually increase settings to increase those loads on those cores (or LPs).

One thing to be aware of is that this main task we observe on the first core can reach 100% when we allow an increase to the frames per second (fps) through a limit, or increase the graphical settings. When it reaches 100% and we increase the load more, we introduce extra demand but we don't get 115%, instead we get a slowdown of available fps - or we see stutter. So it is best to allow an overhead of a few percent on that main core.

So if we go back to this screenshot:

Here I have a limit set in Nvidia Control Panel (NCP) of 28fps. The monitor has a refresh frequency of 60Hz. The graphical settings are low to medium. Hyperthreading is enabled and the Affinity Mask allows LP0 and masks out LP1 so there will be no activity directly from the simulator tasks, and hence there is only a little activity observed on LP1.

If I increase the frame limit in NCP that graph of LP0 rises with the extra load. If I increase graphics settings in the simulator, the LP0 graph rises with the extra load.

If I allow activity onto LP1 from the simulator with no AM, or from other processes like addon exe programs (on LP0 or LP1), the simulator becomes less able to maintain the fps and stutters.

 

Edited June 22, 20214 yr by SteveW

1 hour ago, GSalden said:

My experience is a little difference than yours.

What I have read in all those years and my experience with my former 5820  6 core processor, my 8700k  6 core processor and my 7940 x  14 core processor :

- up to 8 cores HT can add a positive effect

-  10 cores and more runs better without HT

What I do agree on with you is that using an AM can help with stability.
My 7940x uses the first 13 cores for P3D. The last core is for addons only . The Addons also are allowed to use core 2 + 4. 
 

To be honest I've never tried running P3D on a CPU with more than 10 cores, but I read some discussions that there was no benefit observed in using more than 10 cores so the inference was to leave 10 cores max. And I think I can remember that you mentioned then, that in your multi monitor configuration even more cores (>10) produced better performance.

Edited June 22, 20214 yr by Dirk98