The Dev Mode FPS tells us that it is Main Thread limited when the frame time (spent preparing a frame for execution/display on the CPU) is greater than the delay waiting for the GPU to do it's processing and displaying.   The FPS display will ALWAYS show the sim to be limited by something since it is trying to show you the relative contribution to FPS of the CPU and GPU components of total response time. 

SO - in my 5.0 GHZ test time - the 20ms CPU frame time was in the Green but Dev Mode still told me it was main thread limited because the GPU time was only about 15 ms.  

I ran the sim at 3.6GHz with 8-cores over Seattle with a lot of scenery and traffic.  I used RTSS and System Informer and Core Temp to monitor everything.  I then ran the same flight using the same system but set to 5.0 GHz.  CPU Benchmarks show faster cycle time (5.0GHz vs 3.6 GHz) results in a 41% increase in the CPU score.

The Dev Mode/Display FPS frame rate over Seattle went from ~19 to ~25 FPS (with frame gen and all Ultra settings and max TLOD and OLOD) by increasing the CPU cycle speed from 3.6 GHz to 5.0 GHz.

The frame time reported by both RTSS and Dev Mode went from ~48ms to ~34ms.

The eight cores were all simultaneously 100% busy about 10% of the time and there were many times where a single core was 75%, several were 10% busy, and a couple were idling. The average total CPU busy [all eight cores  combinded (my i7-9700K does not have hyper-threading available)] was in the 87% to 92% busy running at 3.6 GHz and 75% to 77% at 5.0GHz.

I then modified the sim settings to balance the CPU and GPU load.  In that configuration the DevMode FPS display rapidly fluctuated between Main Thread and CPU limited.  In that 5.0GHz configuration the CPU and GPU times were both about 38ms.  When I changed the CPU to be 3.6GHz the FPS display switched to a solid Waiting on Main Thread and the CPU frame time went to 45 to 49ms while the GPU stayed at 38ms. 

Now for your question:  the sim had 30 active flightsim.exe threads running ALL the time.  The busiest single thread accounted for 11 to 12% total CPU usage (one core 100% busy is 12.5% total CPU on my 8-core non-hyper thread system) and the next five busiest accounted for another 10 to 15% busy.  But all 30 active threads were dispatched many times a second, i.e. took control of one of the 8 processors.  The busiest thread spent about 75% of it's time on a single core but did dispatch on all the cores at one time or another.

Every thread at some point showed a status of waiting, which means it needed data from another thread.  At any single instant - about half of the 30 threads were in a wait state. 

The threads have names like long worker or event manager or worker or si.pacer.  

SO - in my opinion, and experience, the busiest/dependent worker thread had to wait at times for one or more independent threads to complete and then obtain the data from them to go back to work.  It is a hard earned understanding in the CPU management field "Every processor WAITS at the same speed" - if the busiest core/thread does not have the data it needs - faster cycles will not finish it's wait any sooner.  But, more cores or faster cores may get the data back to the busy guy sooner IF the sim can schedule more independent threads. 

SO - IF the sim wants to be heavily threaded (off load more and more work to multiple processors) then it is inevitable that the main thread/busiest thread will have to wait at some point and thus the total CPU usage will be less than 100% some of the time. 

I use Intel Xtreme Tuning Utility to dynamically change the CPU cycle time and can do so on a per processor basis. 

This is probably more than you ever wanted to know - but in a prior life I spent 30+ years answering this question on the biggest and fasted CPUs in existence.  Those were the dinosaurs of a previous IT world.  When the little Linux and PC processors started nipping at the heels of my favorite dinosaurs - I knew it was time to go sailing full time and let the next generation of hardware geeks answer the same questions. 
 

Edited September 22, 20241 yr by TacomaSailor

On 9/22/2024 at 12:31 PM, TacomaSailor said:

In that configuration the DevMode FPS display rapidly fluctuated between Main Thread and CPU limited.  

That should read:  In that configuration the DevMode FPS display rapidly fluctuated between Main Thread and GPU limited.