I too am an inveterate tinkerer but if I make a change that gives no measurable improvement in any performance metric then I undo it. Fiddling around with scheduling and priorities falls into that category in my experience.

I guess manual scheduling might help in edge cases for people running masses of add-ons (let’s face it, not all of them very well written) that don’t get picked up as suitable for E cores.

But for the general case, it would be disappointing and surprising if manual settings can outperform the scheduling achieved automatically by Windows and implemented by software developers.

I also think we (certainly I) make assumptions about what is optimal, that can be mistaken. For example, not every clock cycle in a P core that’s used by some add-on, is being stolen from MSFS. In most cases, there is plenty of headroom in the P cores for undemanding tasks we might typically leave running in the background: the game is CPU-bound because of its relative inefficiency in distributing and coordinating different tasks/variables, rather than because any single P core is running at 100% capacity. That’s the sense in which it’s the “main” thread which is shown as constraining performance for most people. Similarly we see people anxious when MSFS wants to use 100% of their VRAM, or run their CPUs “hot” - whereas (discounting the case of a memory leak or the like) this is exactly what we should all be hoping for: the game making full use of what it can find!

 

Edited May 4, 20242 yr by tfm

1 hour ago, tfm said:

I also think we (certainly I) make assumptions about what is optimal, that can be mistaken. For example, not every clock cycle in a P core that’s used by some add-on, is being stolen from MSFS. In most cases, there is plenty of headroom in the P cores for undemanding tasks we might typically leave running in the background: the game is CPU-bound because of its relative inefficiency in distributing and coordinating different tasks/variables, rather than because any single P core is running at 100% capacity. That’s the sense in which it’s the “main” thread which is shown as constraining performance for most people. Similarly we see people anxious when MSFS wants to use 100% of their VRAM, or run their CPUs “hot” - whereas (discounting the case of a memory leak or the like) this is exactly what we should all be hoping for: the game making full use of what it can find!

I think this is a great point. 

This is from a 16 min CapFrameX capture I did last flight in the Fenix into FlyTampa’s Schiphol:

The CPU is not even close to being near max load - although I was still mainthread limited during the approach (photogrammetry, AI traffic etc). 

As far as I understand, we have no way of knowing how to take the load off the mainthread outside of the sim. As we have no way of identifying it. It’s not a specific core or thread that we can identify in Lasso or other software is my point.

I’d love to hear other opinions on this though.

I’m not going to stop using Lasso. But I didn’t change many settings other than core affinities for some programs (FSLTL, Fenix apps to the E-Cores). I never changed MSFS core affinities, and I’m hesitant to mess around with that. It’s been running in the background for ages without any detrimental effects - and quite possible not many advantageous effects either. 

Perhaps one day I’ll run a performance comparison with it off vs on.

7950x3d on board, using PL for a year now with subscription. I use MSFS on the 8 cores with 3d cache ( I use only 7 cores )and all other programs on CCD1. things are really smooth. Suppose wit he the game bar and the full chipset all will go automatic. But I like to keep control of what is running and on which cores

FYI, it can be a cause of CTD's for some users and you may not realise it. It was for me. Stopped using it.

I have no ctd's Just don't force affinity but cpu sets. Get the right power profile running. For me most important is that AMD and windows are buggy for the 7950x3d to make sure on which ccd it is running with the 3dvcache. 

46 minutes ago, Brocky120 said:

FYI, it can be a cause of CTD's for some users and you may not realise it. It was for me. Stopped using it.

I experienced this, which is why I stopped messing around with MSFS core affinities. So I don’t think I’m going to follow Island’s advice in this case, I’ll revert back to my previous (simple) settings.

I've been using PL for years and I have yet to experience sound issues or CTD. If you have core issues with your system setup, PL is NOT going to help or produce a miracles, otherwise it does work and is worth every penny.

Edited May 4, 20242 yr by CarlosF

Interested to hear what others who are trying it think.  When I tried to limit MSFS to 0-4 or even 0-7 I got an audio popping in the sim. 

When I selected all my P Cores but excluded Core 0 things improved but when I combined that with with moving all my "supporting" apps to the E Cores and placing my MSFS priority to above normal the sim is as smooth as it used to be before I loaded it up with add ons and ancillary apps.  Note that anything that launches as a child app to the sim (FSUIPC, Simconnect etc inherit the core assignments from the sim.

So just as I was very pleased with the simplicity and the perceived positive impact in P3D I now see the same benefits with MSFS segmenting the sim and ancillary apps from each other on P Cores and E Cores.     

I have used Process Lasso for a long time and while I still had it running, I felt that Pro Balance and Performance mode were enoughal and making some, but not a ton of difference. I had tried tweaking the affinity mask before, but felt it didn't change much.

After watching this video, though, I thought I'd retry things. To my surprise, I definitely feel that even lower FPS situations feel smoother after making some of the suggested changes. I took the flight simulator process off of core 0 but I also remov3d it from all of my mutli-thread cores (1,3,5,7,9,11,13,15). I think it's allowing my computer to run a bit cooler and making the processing more efficient. It seems to also be smoother by removing any execution off of the Efficiency cores as well as the hyper threading cores.

5 minutes ago, psolk said:

When I selected all my P Cores but excluded Core 0 things improved but when I combined that with with moving all my "supporting" apps to the E Cores and placing my MSFS priority to above normal the sim is as smooth as it used to be before I loaded it up with add ons and ancillary apps.  Note that anything that launches as a child app to the sim (FSUIPC, Simconnect etc inherit the core assignments from the sim.

This. Very much agreed and I hadn't tried it previously. See if removing the hyper threading cores makes any kind of a difference. Might be splitting hairs...

6 hours ago, mmcmah said:

I took the flight simulator process off of core 0 but I also remov3d it from all of my mutli-thread cores (1,3,5,7,9,11,13,15). I think it's allowing my computer to run a bit cooler and making the processing more efficient. It seems to also be smoother by removing any execution off of the Efficiency cores as well as the hyper threading cores.

I guess it won’t break anything testing different options. Just wondering why you took MSFS off all the HT-threads though. How would that improve performance, when the sim has 8 performance-threads instead of 16? Or perhaps the reasoning is that you make 8 P-“threads” available for other apps? But then again, when I check Lasso with the sim running, it’s rare that another app is using more than 5% of the CPU. 

Core0 I can sort of understand, if this is indeed the thread most used by the operating system. I don’t have any in-depth knowledge of how this works. 

I think I remember trying it out and gave up because the free version didn't hold my settings and had to re-configure it every time I ran it. 

7 hours ago, mmcmah said:

To my surprise, I definitely feel that even lower FPS situations feel smoother after making some of the suggested changes.

So many times I’ve “felt” something was an improvement, then on reflection / using under different conditions found it was making no difference at all. 

These days I only trust an improvement if I can see it making a distinctive change showing up consistently in Capframex.

And a slightly different approach 

 

Edited May 5, 20242 yr by GSalden

1 hour ago, GSalden said:

And a slightly different approach 

 

Yeah but all that jibberish on YouTube is just teenage clickbait!

Here’s what actually happens if I compare the results with and without all the BS in the first video.

Five tests using Capframex under identical settings at EGLL in the Fenix at stand 512:

Before all the fiddling around:

https://1drv.ms/i/s!AhRYUspKTjKIiOoDvYKj0s2AOL2h6A
 

After the fiddling around:

https://1drv.ms/i/s!AhRYUspKTjKIiOoJkW1ca5L2PtXMvg