Well i tried process lasso free

 

ht off i9 9900k

Aaaaaaand seen no difference.
 

i has P3d running on cores 0 to 5

And  all addons on 6 and 7

 

i then switched to default with everything running on all cores.

graph showed that all cores where level across the bar spread out evenly.

and was the same.

the sim is running quite smooth.some very slight stutter when panning in some areas that is quite congested.

i guess that’s normal?

but I guess I am being anal trying to squeeze more smoothness out.

 

cheers
mike

 

 

As Gerard says, positive results on his system are seen in simple observation. FSX/P3D operate to consume cores as they see in the affinity mask and how the jobscheduler works to share out cores for those is not relevant. They assert an AM whatever we do.

With FSX and P3D this behaviour is different because these apps operate on the cores seen through the mask (including AM = 0 = tasks split out to all cores irrespective of the jobscheduler) as they spread onto those available cores. Instead we can assert an AM for the simulator and - it has the command to do it for this reason.

Indeed, there are many discussions of how stutter is alleviated by changing chosen CPUs in Task Manager. That is when the jobscheduler can do its work with some success. The main cores of the simulation become unshared after the changes made in TM. Instead it is better to set up the system without shared cores where it counts - in the first place.

We can corral exe apps running alongside the simulator program for more gains. An exe handling for example a stack of panels might be a problem even though this never shows more than say 5% CPU load. That load is not helping in any case but if that load is amongst the primary cores of the sim we get a variation in fps causing the appearance of stutter. A small exe with a few percent load can disturb the simulator by a few percent on core throughput. That can be reduced to an extent by corralling those addons away from the main simulator cores. Remember that exe apps connecting to the simulator server make an extra process on the simulator handling the client. When we move out the exe we move all the other processing out of the simulator held cores. And that reduces the combined throughput on those cores.

Essentially the Windows OS and i / o are heavily multi-threaded. We can observe that very easily during file loading for example, as we add cores we decrease the time to load the file(s).  With the simulator, results vary depending on scenery load mostly.

When the scenario is loading we can see that more cores load the scenario faster. After a number of cores the files only load a tiny bit faster no matter how many cores are added. This is where the system limits of  i / o are met by basically too many CPUs on the bus all accessing the same data at once - competing for system bandwidth that disturbs the simulator main process or rendering in a timely fashion.

When the sim is in flight and coming up to more scenery these files loading gradually are needing fewer cores. Without an AM they will continue on as many cores as they got. Also most CPUs and motherboards handle six cores aggressively loading files, but adding another core or two adds an overhead bigger than is expected as combined their demand on the system is quite simply more than is available for free.

With Hyperthreading the simulator and addons are helped even more by utilising AMs, in fact an AM on the simulator is essential with HT enabled because these simulators have their main processes in monolithic tasks where we don't want to share cores, coupled to a paralleled back end that will overburden the system if allowed.

On a system with few cores we can share those backend tasks on HT cores, but still we must keep the main processes on unshared cores.

It is not a problem of the theory of multi core and HT that does not fit the observations made, rather, it is a mis-understanding of that theory. We find by observation that restricting the number of cores and corralling the other exe's produces positive results. Many have observed this without specialist software and measuring techniques.

The partitioning of cores for programs running together to gain best performance is nothing new at all.

 

50 minutes ago, SteveW said:

As Gerard says, positive results on his system are seen in simple observation. FSX/P3D operate to consume cores as they see in the affinity mask and how the jobscheduler works to share out cores for those is not relevant. They assert an AM whatever we do.

With FSX and P3D this behaviour is different because these apps operate on the cores seen through the mask (including AM = 0 = tasks split out to all cores irrespective of the jobscheduler) as they spread onto those available cores. Instead we can assert an AM for the simulator and - it has the command to do it for this reason.

Indeed, there are many discussions of how stutter is alleviated by changing chosen CPUs in Task Manager. That is when the jobscheduler can do its work with some success. The main cores of the simulation become unshared after the changes made in TM. Instead it is better to set up the system without shared cores where it counts - in the first place.

We can corral exe apps running alongside the simulator program for more gains. An exe handling for example a stack of panels might be a problem even though this never shows more than say 5% CPU load. That load is not helping in any case but if that load is amongst the primary cores of the sim we get a variation in fps causing the appearance of stutter. A small exe with a few percent load can disturb the simulator by a few percent on core throughput. That can be reduced to an extent by corralling those addons away from the main simulator cores. Remember that exe apps connecting to the simulator server make an extra process on the simulator handling the client. When we move out the exe we move all the other processing out of the simulator held cores. And that reduces the combined throughput on those cores.

Essentially the Windows OS and i / o are heavily multi-threaded. We can observe that very easily during file loading for example, as we add cores we decrease the time to load the file(s).  With the simulator, results vary depending on scenery load mostly.

When the scenario is loading we can see that more cores load the scenario faster. After a number of cores the files only load a tiny bit faster no matter how many cores are added. This is where the system limits of  i / o are met by basically too many CPUs on the bus all accessing the same data at once - competing for system bandwidth that disturbs the simulator main process or rendering in a timely fashion.

When the sim is in flight and coming up to more scenery these files loading gradually are needing fewer cores. Without an AM they will continue on as many cores as they got. Also most CPUs and motherboards handle six cores aggressively loading files, but adding another core or two adds an overhead bigger than is expected as combined their demand on the system is quite simply more than is available for free.

With Hyperthreading the simulator and addons are helped even more by utilising AMs, in fact an AM on the simulator is essential with HT enabled because these simulators have their main processes in monolithic tasks where we don't want to share cores, coupled to a paralleled back end that will overburden the system if allowed.

On a system with few cores we can share those backend tasks on HT cores, but still we must keep the main processes on unshared cores.

It is not a problem of the theory of multi core and HT that does not fit the observations made, rather, it is a mis-understanding of that theory. We find by observation that restricting the number of cores and corralling the other exe's produces positive results. Many have observed this without specialist software and measuring techniques.

The partitioning of cores for programs running together to gain best performance is nothing new at all.

 

Great explanation as always.

As regards your point on HT, I totally concur that HT ON and allocation of cores is the best way to go. I actually turned HT OFF because of excessive heat but with the onset of winter I will go back to HT ON :). Gives me many new cores to allocate my programs.

Yes on my 18 core+2080ti I am seeing the performance after around 6 to 8 cores drops off depending on scenery loads. Heavy scenery needs more cores, but not all cores. 

The main thing is that when loading the scenario, looking at Task Manager see which logical processors are hitting maximum, that's where the heat is generated. With HT on and no AM the CPU throughput will be at the greatest possible demand.

6 hours ago, SteveW said:

Yes on my 18 core+2080ti I am seeing the performance after around 6 to 8 cores drops off depending on scenery loads. Heavy scenery needs more cores, but not all cores. 

The main thing is that when loading the scenario, looking at Task Manager see which logical processors are hitting maximum, that's where the heat is generated. With HT on and no AM the CPU throughput will be at the greatest possible demand.

So the best option is for me to se HT on

on my i9 9900k  and have an AM?

if so what AM?

and then allocate all my addons off those cores.

using process lasso.

 

cheers

mike

40 minutes ago, mikeymike said:

So the best option is for me to se HT on

on my i9 9900k  and have an AM?

if so what AM?

and then allocate all my addons off those cores.

using process lasso.

 

cheers

mike

I have nearly the same PC as you. I run HT on (have tried both ways many times and HT on just looks and feels smoother in flight scenery loading to me, and @5.0GHz the temps stay mid 70's). I use:

[JOBSCHEDULER]    ///  -- start ASP4, FSXFlight, FFTF, RTSS in FSUIPC with affinity 3
AffinityMask=65532  /// 1111 1111 1111 1100    add ons = 3    0000 0000 0000 0011

This way I let P3D use as many LPs as needed EXCEPT for LP 0 & 1 where there may be system processes going on to interrupt it, the add ons are also allocated to LP 0 & 1 since they don't ever consume enough to saturate the core but it keeps them from interrupting P3D.

I have settings pretty high and my 4K TV is set to 60Hz but I use RTSS on Scanline x/2 with -1 for the tearline. I also limit FPS in P3D to 32 to keep it from trying calculate max FPS. I'm not sure that really impacts anything but I'm very happy with my results. 

YMMV.

Bruce

On 12/12/2019 at 12:39 PM, mikeymike said:

30.5 FPS locked in Nvidia inspector 

Are you running unlimited within P3D?

Anyway, reset Nvidia back to defaults.

On 12/12/2019 at 12:39 PM, mikeymike said:

running all cores for everything  asp4  Asca P3d etc etc 

What is etc., etc. and and at what setting(s)?

What are you settings in ASP4? What are your settings in P3D?

You've got a lot of variables at work here mikeymike. All those need to be looked at prior to considering an AM addition/change. 

The true resolution here (from the Latin meaning it's a lot of work) is to remove your addons, rebuild the .cfg and add them back one by one and observe, with settings in P3D at default except your resolution. I can say with a fairly high degree of certainty that you will find the problem and after the work done above is complete, and the problem will reveal itself. Those who have the smoothest running machines have done the work up front and the time spent troubleshooting is now available for flying.

Now, back to my new Dash 8 Professional 😁

Now THERE's a problem solving environment! That VNAV is killin' me. I think I need and AM!

Cheers,

Mark

 

 

7 minutes ago, newtie said:

Are you running unlimited within P3D?

Anyway, reset Nvidia back to defaults.

What is etc., etc. and and at what setting(s)?

What are you settings in ASP4? What are your settings in P3D?

You've got a lot of variables at work here mikeymike. All those need to be looked at prior to considering an AM addition/change. 

The true resolution here (from the Latin meaning it's a lot of work) is to remove your addons, rebuild the .cfg and add them back one by one and observe, with settings in P3D at default except your resolution. I can say with a fairly high degree of certainty that you will find the problem and after the work done above is complete, and the problem will reveal itself. Those who have the smoothest running machines have done the work up front and the time spent troubleshooting is now available for flying.

Now, back to my new Dash 8 Professional 😁

Now THERE's a problem solving environment! That VNAV is killin' me. I think I need and AM!

Cheers,

Mark

 

 

Running unlimited in p3d

asp4 settings default apart from 3 cloud layers as oppose to 5.

p3d settings moderate.

tonight I will post pics as I will be on my pc.

 

 

 

mike

16 minutes ago, bbuckley said:

I have settings pretty high and my 4K TV is set to 60Hz but I use RTSS on Scanline x/2 with -1 for the tearline. I also limit FPS in P3D to 32 to keep it from trying calculate max FPS. I'm not sure that really impacts anything but I'm very happy with my results.

Have you tried running unlimited framerate in P3D while using RTSS?  My experience has been that both are not needed, and that locking framerate in the sim will cause it to make look-ahead frames (which takes resources from the system... especially the CPU).

Regards,

Greg

1 minute ago, lownslo said:

Have you tried running unlimited framerate in P3D while using RTSS?

This is what I do.

1 hour ago, lownslo said:

Have you tried running unlimited framerate in P3D while using RTSS?  My experience has been that both are not needed, and that locking framerate in the sim will cause it to make look-ahead frames (which takes resources from the system... especially the CPU).

Regards,

Greg

I have usually run with unlimited in the sim but just recently tried limiting FPS there. As I said I wasn't sure what impact that has (good or bad) so now I know 😀. I'll go back to unlimited , thanks!

With my previous I 7 4790k I have unlimited FPS in sim and ran my 4k tv at 30hz

bow unlimited in sim and 30.5 locked In Nvidia inspector is the better option now 

In order to determine performance there are considerations such as, we must ask; is the simulator working properly so that we see true results in our testing?

When I'm testing performance, I'm looking at various ways of setup, some only suitable for testing but not for general use - the considerations are complex, I've tried to include some ideas for those following the subject. If you can't find help you need in older posts, or want to exchange information and experiences, please PM me and we can have a look at things in more detail...

 

With P3D in mind it is a windowed application which is governed by the desktop settings. Most games that are fullscreen are in Exclusive mode, as is FSX, and respond to vertical sync settings on the GPU control panel. But P3D when in fullscreen is not exclusive mode, instead it is a maximized window with caption and borders removed, and does not respond to the GPU settings the same way. With P3D we have the VSync and TB settings in Display Settings. 

When using P3D Unlimited and with VSync=Off we can see fps above the monitor frequency, if detail settings allow it. With this setting the next frame follows the previous frame right away. Incidentally, we may see flashes or flicker on the monitor that way, when fps drops below the monitor frequency. Setting TB=On might help that flicker depending on hardware. VSync = On steers the GPU output frequency of the simulation frames to be close to the Refresh frequency of the monitor.

So with that understood, with Unlimited on the slider and VSync = Off we have a kind of test mode in that we can determine the maximum fps capacity of the set-up. However, we must be careful to understand that this does not dictate the possible fps when we are set up for the Simulator in use.

With fps above the refresh rate of the monitor, we would set VSync=On, for use of the simulator, so that the system has Overhead. When the system does not have overhead we see objects building into the scene, even though we have high fps. We see slightly lower fps when the background tasks are running more efficiently because there's more object quantity and quality in there earlier.

So with Unlimited and VSync=Off the simulation has the least time for fill-in. With overhead in the system we find fill in is quicker, reducing fps slightly but improving the experience overall. Beware of comparing fps figures.

When looking at Task Manager graphs remember these are averaged and smoothed and don't show all the sharp peaks. However we can see a lot there. When we are flying and the simulator comes across more objects to fill in the scene, we see the back-end tasks rise in demand. If these tasks are hitting 100% CPU on their cores (or combined LPs on HT systems) then we have a case for adding cores to the AM. If we only see small variations in the cores running the back-end tasks, then we have a case for reducing the number of cores.

As is with any complex system there will be an optimum setting. With motherboards CPUs RAM and SSDs all being slightly different we must look at each system as unique.