The HT core numbering are even cores are primary, i.e. 0, 2, 4, and odd are HT cores.  Setting the affinity mask to all even cores is what you want to do.  Note that what really matters is not to have FSX threads running on any consecutive even/odd pair.

BTW, the above is a somewhat simplified explanation of HT core utilization, but suffices for what is needed.

3 hours ago, TheFamilyMan said:

The HT core numbering are even cores are primary, i.e. 0, 2, 4, and odd are HT cores.  Setting the affinity mask to all even cores is what you want to do.  Note that what really matters is not to have FSX threads running on any consecutive even/odd pair.

BTW, the above is a somewhat simplified explanation of HT core utilization, but suffices for what is needed.

Yeah I found a mask calculator and it had a basic and advanced version.  Advanced you check the boxes for which cores and HT threads you wanted so I chose the actual cores for 1-7 leaving core 0 open and leaving all the "HT" cores unchecked.  This is the result..........

[JOBSCHEDULER]
AffinityMask=21844

That tool generated AM is spot on correct for your 1-7 physical core execution.  It is surprising that without any AM setting FSX figures out the CPU's HT configuration for intel processors and does the right thing.  FSX directly controls which threads can run on which "logical" cores.  If provided, the AM tells FSX which logical cores it can use for its threads. If not provided, I surmise that FSX uses special intel machine level instructions which query CPU properties (HT has been a intel processor feature since 2003), and the AMD CPU equivalent instructions are different and not implemented in FSX.  I would be really surprised if a bios update could correct this FSX behavior...but I'm ready to be surprised. 

Nice build you got there, hope that it's nothing but joy for you to use. I'm still nursing along a 4770k that I built over 6 years ago.  it's nearly golden overclock abilities still suits my needs, at least "good enough".  Recently did a bios mod so I can boot a x4 PCIe NVMe drive, works great!

1 hour ago, TheFamilyMan said:

That tool generated AM is spot on correct for your 1-7 physical core execution.  It is surprising that without any AM setting FSX figures out the CPU's HT configuration for intel processors and does the right thing.  FSX directly controls which threads can run on which "logical" cores.  If provided, the AM tells FSX which logical cores it can use for its threads. If not provided, I surmise that FSX uses special intel machine level instructions which query CPU properties (HT has been a intel processor feature since 2003), and the AMD CPU equivalent instructions are different and not implemented in FSX.  I would be really surprised if a bios update could correct this FSX behavior...but I'm ready to be surprised. 

Nice build you got there, hope that it's nothing but joy for you to use. I'm still nursing along a 4770k that I built over 6 years ago.  it's nearly golden overclock abilities still suits my needs, at least "good enough".  Recently did a bios mod so I can boot a x4 PCIe NVMe drive, works great!

I know right after release there were some modern games with affinity mask type issues with the Windows Scheduler especially on the 3900X with the two chiplets that split the cores physically in half.  So that's why I was thinking some driver/Windows updates might help, the BIOS stuff was more about hardware tweaks to the performance of the chips overall (boost behavior etc.).

Edited August 16, 20196 yr by flyinion
typo

Well, hopefully I can finish my tweaking in a couple weeks.  Just ordered all my watercooling gear, hopefully will be installing next week.  Then I can really start tweaking, trying all core OC's, etc. once my temps are properly under control and not all over the place due to currently using the stock cooler.  I only used it because I knew I was going to do my first watercooling loop and it would have been a waste of $$$ to buy anything to use temporarily.  

On 8/15/2019 at 8:44 PM, TheFamilyMan said:

It is surprising that without any AM setting FSX figures out the CPU's HT configuration for intel processors and does the right thing.  FSX directly controls which threads can run on which "logical" cores.  If provided, the AM tells FSX which logical cores it can use for its threads. If not provided, I surmise that FSX uses special intel machine level instructions which query CPU properties (HT has been a intel processor feature since 2003), and the AMD CPU equivalent instructions are different and not implemented in FSX.  I would be really surprised if a bios update could correct this FSX behavior...but I'm ready to be surprised. 

You're surprised because you don't understand how the Windows kernel scheduler works.

The scheduler assigns what CPU core to execute what threads on, each time a CPU slice is available for a given thread to run on. It bases its decision on what core is available, the previous core that thread ran on (for cache affinity) as well as whether the core is a real or virtual (HT) core. The scheduler is the only component that can do this properly, since it has visibility into all the threads in the system and their execution.

The AffinityMask simply tells the kernel "only use these cores when deciding" and is a simple Win32 API call (for P3D) or this Win32 API call (for FSX). It can limit the kernel's choices, but under no circumstances is a Windows application dynamically deciding what thread something should execute on. It gives the kernel a list of choices, nothing more. An AffinityMask of zero simply lets the kernel pick from any available core. Neither FSX nor P3D are interrogating the CPU for what its cores are using CPUID instruction (which by the way is implemented in x64 as well) and there's no point since the operating system provides all of that data with additional information (like whether the core is physical or virtual).

The reason why some folks have issues with new Ryzens is that they have different performance characteristics to Intel especially when switching cores and it takes Windows a little bit of time to catch up. It's much faster now; in the early days I needed to upgrade the entire OS (Win2000 -> XP) so that the kernel would be properly aware of P4's virtual core.

Cheers!

"You're surprised because you don't understand how the Windows kernel scheduler works."

That's a rather bold and unfortunately misinformed statement.  I've been providing programming support for simulations running in realtime hardware in the loop testing labs for nearly 35 years at a major aerospace company.  As for multi-processor, multi-core, multi-process, multi-thread, realtime, shared memory, and distributed programming, I was a go-to expert (that is, until I recently retired).  To say "you don't understand how the Windows kernel scheduler works" is rather laughable, if not insulting.

Also, your response side stepped my "surprise":  mainly that FSX figures out, WITHOUT the help of a fsx.cfg supplied affinity mask, its host CPU environment and then creates and launches its threads, most likely setting each thread's logical core affinity (as you mentioned) to best alleviate inter-thread contention, all to best optimize FSX's overall execution in light of the CPU resources available to it, whether the host's CPU is hyperthreaded or not. Perhaps my misguided statement about directly querying the CPU set you down your path.  It was a bad guess, as you called out; this system service is the (most probable) correct way that that information is accessed from the OS, as you alluded to: getlogicalprocessorinformation. 

Luke, please indulge me here, you probably know all that follows.  A final note of what a hyperthreaded CPU is, at least from an application programmer's point of view. A hyperthread CPU is a collection of logical cores, period!  (A non-hyperthreaded CPU is also a collection of logical cores!)  Hyperthreading is that two (but could be more) logical cores share the same physical core; but from a program's perspective there are only logical cores available to it, and none of them are specifically marked as a physical core.  The Window scheduler, and informed programs, know its host's CPU(s) logical to physical core ratio, and they best manage their payload to keep all the available physical cores most efficiently busy as possible given the processing payload to be managed. Part of "most efficient" is to minimize the number of each physical core's logical cores in use, but definitely use them when needed!

One bummer about Windows which RTOS provides and Windows does not is the ability to globally have the scheduler reserve cores (and shield them from device and some of the OS interrupts) for exclusive use by realtime applications.  I sort of back door this functionality by using cmd's exe to launch and set an AM for all the FSX helper apps I use, e.g. TrackIR, so FSX is least bothered by them.

Thanks for reading my mini-tome! 🙂

Edited August 20, 20196 yr by TheFamilyMan
Dang, I never get it right the first time :-(

13 hours ago, TheFamilyMan said:

That's a rather bold and unfortunately misinformed statement.  I've been providing programming support for simulations running in realtime hardware in the loop testing labs for nearly 35 years at a major aerospace company.  As for multi-processor, multi-core, multi-process, multi-thread, realtime, shared memory, and distributed programming, I was a go-to expert (that is, until I recently retired).  To say "you don't understand how the Windows kernel scheduler works" is rather laughable, if not insulting.

I have no doubts that you are an expert in multi-threaded code. I have no doubts that you understand how RTOS-based systems work (an area which I will admit my ignorance with no sense of injured pride) and you've spent a great deal of time designing and implementing systems that are a single, dedicated hardware/software combination.

FS/P3D on Windows is none of these, and the assumptions and design choices you made in your career will not likely be good ones in this environment. If you have spent the last few years writing latency-sensitive multi-threaded code on Windows, I'll happily walk back and apologize. But still disagree with you. 😄

Windows was designed to work in a situation with large numbers of applications from different authors and sources, operated by someone with a limited understanding of the internals of the system. (That includes us, BTW). The apps cannot be individually tuned, it's up to the OS kernel to dedicate CPU time between them given hints (priority, affinity, etc). The kernel has been written by much, much smarter folks than us and 99.9999% of the time just works. The only quirks are when a new CPU comes out with (usually) significantly different latency characteristics - like from AMD.

13 hours ago, TheFamilyMan said:

Also, your response side stepped my "surprise":  mainly that FSX figures out, WITHOUT the help of a fsx.cfg supplied affinity mask, its host CPU environment and then creates and launches its threads, most likely setting each thread's logical core affinity (as you mentioned) to best alleviate inter-thread contention, all to best optimize FSX's overall execution in light of the CPU resources available to it, whether the host's CPU is hyperthreaded or not. Perhaps my misguided statement about directly querying the CPU set you down your path.  It was a bad guess, as you called out; this system service is the (most probable) correct way that that information is accessed from the OS, as you alluded to: getlogicalprocessorinformation. 

With respect, you're continuing with the mistaken assumptions that a) FSX is querying the CPU properties (either directly or via the OS) and then b) setting its thread affinity based on that. Neither is true.

Microsoft has been quite explicit that in the absence of an Affinity Mask, it will request no processor affinity and the OS scheduler will figure it out. By and large, Windows understands the notion of virtual and physical cores, and has done so for almost two decades. It may not be perfectly optimized for AMD chips (iirc which you switch dies there is a penalty which the scheduler doesn't fully realize) but again, there is nothing to be surprised about here. You would find that P3D behaves the same way, and you can query its process affinity mask to see that it it still zero.

13 hours ago, TheFamilyMan said:

One bummer about Windows which RTOS provides and Windows does not is the ability to globally have the scheduler reserve cores (and shield them from device and some of the OS interrupts) for exclusive use by realtime applications.  I sort of back door this functionality by using cmd's exe to launch and set an AM for all the FSX helper apps I use, e.g. TrackIR, so FSX is least bothered by them.

The problem I have with all the AffinityMask voodoo (no offense) is that setting the affinity on program start is a very crude instrument that arbitrarily restricts what the scheduler can do. By and large, we have a ton of spare CPU cycles and as you point out we want to have as many cores available as often as possible - the best way IMO to do that is to let the scheduler pick the best core to execute on from as many choices as possible. The scheduler is not dumb - it understands what cores are busy and will try and schedule away from them if possible. It's also worth noting that the vast majority of add-ons take a miniscule amount of CPU time. In the past, I've looked at aggregate CPU time for processes and my add-ons are a rounding error compared to FSX/P3D. My virtual airline's flight recorder is polling multiple times a second and struggles to exceed 2s of aggregate CPU usage over a 12-hour flight.

(And by and large, if you need higher priority for CPU time, you set the process/thread priority in Windows, not dedicate a core.)

I recall a mantra that I see in every single Linux filesystem tutorial - unless you have a very, very deliberate and informed reason for tweaking any defaults.... leave them alone. By and large it extends to the flightsim world, with the exception that some of the defaults in FSX/P3D arbitrarily restricted the sim for lower-powered hardware.

Thanks for reading my tome!

Cheers!

Luke