2 hours ago, Langyboy63 said:

I have been using Process Lasso for several months now and find it does the AM stuff brilliantly.

Can see any reason to go back to an AM setting in the CFG, just limit frames vsync to 1/2 refresh and getting smooth stutter free with my settings maxed out for my gaming laptop.

So long as PL only allows P3D to start on the AM LPs it's fine. If you allow P3D to start with no AM in the P3D cfg it will align itself on all cores or LPs and then the process manager corrals those tasks into a crowd onto the less cores or LPs assigned in the mask - which won't work the same.

Also the AM specified that the Process Manager is applying to P3D presents a set of available cores or LPs that look like the available cores of the processor. So when you specify the AM in the P3D config it also knows the cores of the entire CPU and assesses its tasks across all the available cores or LPs in the P3D cfg AM.

So it's much safer to recommend to simply put the AM in the P3D config and let it get on with that task since the process manager alters the P3D 'view' of the CPU. Use the process Manager to handle the rest of the stuff, that's great.

Edited December 12, 20187 yr by SteveW

Ok, think I get what you are saying, i will try an AM entry in the CFG and disable the p3d profile in LP to see what it does

But did make a huge difference when I started using LP to handle the AM stuff, completely got rid of the stutters for me.

Yes - I'm  just saying we have to be careful when externally mothering ANY apps that do their own AM thing. 

The benefit of using the process managers such as Proc Lasso comes from the fact that they can keep addon apps within a specific partition of the CPU away from important P3D tasks. We can't improve on P3D's AM function, or any other AM handling app, by corralling onto lesser cores with another process. We can easily mess it around, it's OK if we are aware of the pitfalls.

P3D is not the same as regular apps. P3D can make use of high clock rate on particular cores, and also can make use of Hyperthreading. We see that some tasks run in the background and take seconds to complete, these can happily be ganged onto HT LP pairs and they extract maximum performance from those cores. Then we have some more important tasks that are frame time critical, we don't want these to share an LP on the same HT core with another task if we can help it.

The ultimate system will demonstrate a purposeful mixture of those tasks sorted correctly.

The main thing is that with an HT system the first task appearing on the 'one' on the right of the AM ones and zeros string (rightmost digit is top left in task manager) does not share that core with another task, because it can use the entire bandwidth of the core. So we see some amount up to 100% on that one LP of that core with the main task. Even though we might see only a few percent on the sister LP, that's just as unwanted as if it was a big percent. Remember that an LP showing zero percent with a sister LP showing some percent of use is still a core IN USE with zero showing on the dial.

We can't just throw all the LPs or cores at the sim because it will use them all pushing aside other processes, including those resources supplying the sim delaying the sim. We can't increase priority of the sim, that simply decreases priority of resources supplying the sim and the performance drops in the same way.

So we can add LPs one by one and see the time to load the scenario comes down. When we start the sim, that's the biggest hit the system sustains. The faster that works the better the sim can run - right? Well...up to a point...

We see a decrease in loading time with every core or LP added to P3D.

But if we use them all, so that the last few perhaps only gained us a second, could those cores could be utilised more effectively for the weather and traffic addons?

Not only that, that's good, but not so essential as system available bandwidth.

How many P3D background processes loading scenery saturate the bus? Put it in a non technical way - how many tasks can read the disk system all at once before it slows down to the detriment of some other task like the P3D renderer?

If we keep on allocating more and more cores to the sim, after it gains us little time, we have overreached the available throughput and in effect will be hogging the system for no gain in performance. This even creates unnecessary heat and also can and will result in less overall performance at some stage. There's going to be a sweet spot.

After that we tune the addons away from the important cores, and give everything at least two LPs even if on the same core - otherwise they can be found waiting for stuff on their own LP.

Only now we can worry about the GPU settings and other stuff, since we have a good foundation to enable the data to the card. With care of the CPU side we get less chance of bottlenecking onto the GPU card and that can produce odd errors and low GPU throughput.

Don't try altering the AM after that just because some part of the system doesn't work right. If it doesn't respond in the way described suspect you have something flatlining rather than rip up the rule book to blame HT and AMs.

 

 

 

Edited December 12, 20187 yr by SteveW

Ok so dont use PL for p3d then.

 

Thanks for your explanation, I will read it more thoroughly when I get home.

1 hour ago, SteveW said:

Yes - I'm  just saying we have to be careful when externally mothering ANY apps that do their own AM thing. 

Steve what AM setting do you recommennd for an i7 8 core with HT on.

I am thinking 252 (11111100) leaving my add ons on 0-1 and p3d on 2-7. This is how I have done it in PL and seems to work ok.

Am i reading that correct?

Thanks

Chris.

There comes the individuality and the list of other addons running alongside P3D and how you treat them. So, no generally valid answer can be given.

In my case, since the first days of using AffinityMask, always limiting the sim on the logical cores served me best. In your case this would mean AM=85. Since I now restrict my externally running addons such as ActiveSky, REX Skyforce and ProATC/X to cores 5 and 6 only, my sim is almost stutter free and smooth. Not perfect, but close.

But you need to test the AM that suits best in your case. Might be that it is AM=85, might be that 252 is the way to go. Might be that it is even another AM.

Ok thanks, will give it a try. Can always go back if needed.

9 hours ago, AnkH said:

BTW: I now also use FFTF Dynamic, as I was interested of the capabilities of this Little tool. So far no time for 2-3h flights, but I am curious if starting from a heavy airport with FFTF Dynamic Setting FFTF to "0.01" will have any adverse effect on autogen loading later on in the flight or not

For what it’s worth I have been using the Dynamic FFTF tool since it came out on v4.3 and now on v4.4 with the new update recently released and I find it to work well. A few months ago on the forum it was shown to work with unlimited settings, a point that keeps coming up.

I run Unlimited, Vsync on, TB on with no external limiter on a 30 Hz 4K monitor using these Dynamic FFTF settings:

at less than 200 ft.  FFTF = 0.01   at 7000 ft.  FFTF = 0.40

So basically on the ground and at takeoff I’m running at FFTF = 0.01 and as I gain altitude the value increases linearly to 0.40 (yes a bit higher than 0.33)  and stays at 0.40 above 7000 ft. I’ve also followed the discussions around 0.01 not being possible it’s only 0.1 and it doesn’t matter to me who’s right I do see improved stability and if I’m really only getting the range of 0.1 to 0.4 that’s fine even though the FFTF monitor shows 0.01 to 0.40.

Obviously ALL systems and setups vary but I choose to use the Dynamic FFTF tool, before this I was editing my config files but find this Dynamic approach works better on my system.

Joe

 

 

I have only used FFTF dynamic for a little look, but will give a more thorough test tomorrow and see how it goes.

5 hours ago, SteveW said:

The benefit of using the process managers such as Proc Lasso comes from the fact that they can keep addon apps within a specific partition of the CPU away from important P3D tasks. We can't improve on P3D's AM function, or any other AM handling app, by corralling onto lesser cores with another process. We can easily mess it around, it's OK if we are aware of the pitfalls.

P3D is not the same as regular apps. P3D can make use of high clock rate on particular cores, and also can make use of Hyperthreading. We see that some tasks run in the background and take seconds to complete, these can happily be ganged onto HT LP pairs and they extract maximum performance from those cores. Then we have some more important tasks that are frame time critical, we don't want these to share an LP on the same HT core with another task if we can help it.

The ultimate system will demonstrate a purposeful mixture of those tasks sorted correctly.

The main thing is that with an HT system the first task appearing on the 'one' on the right of the AM ones and zeros string (rightmost digit is top left in task manager) does not share that core with another task, because it can use the entire bandwidth of the core. So we see some amount up to 100% on that one LP of that core with the main task. Even though we might see only a few percent on the sister LP, that's just as unwanted as if it was a big percent. Remember that an LP showing zero percent with a sister LP showing some percent of use is still a core IN USE with zero showing on the dial.

We can't just throw all the LPs or cores at the sim because it will use them all pushing aside other processes, including those resources supplying the sim delaying the sim. We can't increase priority of the sim, that simply decreases priority of resources supplying the sim and the performance drops in the same way.

So we can add LPs one by one and see the time to load the scenario comes down. When we start the sim, that's the biggest hit the system sustains. The faster that works the better the sim can run - right? Well...up to a point...

We see a decrease in loading time with every core or LP added to P3D.

But if we use them all, so that the last few perhaps only gained us a second, could those cores could be utilised more effectively for the weather and traffic addons?

Not only that, that's good, but not so essential as system available bandwidth.

How many P3D background processes loading scenery saturate the bus? Put it in a non technical way - how many tasks can read the disk system all at once before it slows down to the detriment of some other task like the P3D renderer?

If we keep on allocating more and more cores to the sim, after it gains us little time, we have overreached the available throughput and in effect will be hogging the system for no gain in performance. This even creates unnecessary heat and also can and will result in less overall performance at some stage. There's going to be a sweet spot.

After that we tune the addons away from the important cores, and give everything at least two LPs even if on the same core - otherwise they can be found waiting for stuff on their own LP.

Only now we can worry about the GPU settings and other stuff, since we have a good foundation to enable the data to the card. With care of the CPU side we get less chance of bottlenecking onto the GPU card and that can produce odd errors and low GPU throughput.

Don't try altering the AM after that just because some part of the system doesn't work right. If it doesn't respond in the way described suspect you have something flatlining rather than rip up the rule book to blame HT and AMs.

 

 

 

Hi Steve

This coming year I will be building a new PC with higher performance and more cores but I have been running an i5-2500K clocked at 4.5 GHz quite well for years now with a GTX 1070.

I use Process Lasso to assign my cores ( which there are only 4 no HT ) and no AM config file edits. What I have found works best on my system is the following:

I let P3D run on all 4 cores and I remove the 1st core ( core 0 ) from EVERYTHING else including all my MS things running this amounts to in excess of 20 to 30 items. This is easily accomplished by highlighting the first process holding down the shift key and going down to the last process then when you right click to assign the core affinity and eliminate core 0 always it does it for all processes with one edit to save time. I then go in and push all my hungry add-ons to the last two cores. I find this brings a very nice core balancing across the 4 cores to my system.

So in essence I am running P3D on all 4 cores, ONLY P3D on core 0 ( my primary rendering core ), and add-ons on the last two cores, and the other MS processes etc get the last 3 cores.

Any thoughts on the setup I have been successfully running across all the P3D v4 versions?

Thanks in advance

Joe 

2 minutes ago, joepoway said:

Any thoughts on the setup

Seems good. Not much can be done with four cores, but you've managed to work out the balance is still quite important. Nice post and demonstrates proper technique.

1 minute ago, SteveW said:

Seems good. Not much can be done with four cores, but you've managed to work out the balance is still quite important. Nice post and demonstrates proper technique.

Thanks again Steve

Joe

21 minutes ago, joepoway said:

Thanks again Steve

Joe

You're welcome!

Let's have a look at  that technique because it's quite intuitive and a natural way of going about things. So we basically move off of core zero all the other things and start our must run apps alongside the sim with a BAT file or starter app or manage them with Proc Lasso.

Should work great!

Core zero, the one at the top left in Task Manager CPU graphs, the one on the far right in the string of ones and zeros in the AM - right?

Well, it doesn't really matter which is core zero to most of the system. If a process is on core zero and activates and that core is busy, the jobscheduler can move it to a lesser used core if the circumstances allow, including the windows tasks and the dormant jobscheduler as well. Unless the app chose to have certain tasks stay put (P3D), wherever they are started. That's more or less how the Windows threading works in a simplified way of thinking.

So if we go in and move absolutely everything, we could be moving stuff around that makes no difference. What makes a difference is an app firing up across the internet, to download weather or schedule data and blast it at the sim. If we keep that spurious activity to spare cores or cores that do not run the rendering task, we're usually OK.

Edited December 12, 20187 yr by SteveW

I undertook extensive testing with this, as it has affected so many people. My conclusion is that it's not just one single thing, in my experience it's caused by several. For me, I have locked framerates at 31, turned off hyperthreading and removed any affinity mask value and set all scenery sliders to medium. Oh, and also disable all the sceneries I'm not flying in. I no longer have any problem. Additionally, I no longer have any pauses either! Having said this, I can only report my own experiences. 

Edited March 10, 20197 yr by Rockliffe