What AM are you setting, and what is your CPU?

Let's assume you're using a four core HT enabled with no AM. P3D will utilise 8 LPs, the first one is the main job, then job 2 on LP1 shares core zero with the main job, job 3 also takes part in scenery loading with jobs 4 to 8. So compared to the four core HT Off no AM we have an extra lean use of core zero for example. If we go to HT On, we need to mask one of those LPs of core zero otherwise the sim will place the second job on core zero. That's not an error, it's because P3D is provided with proper control of the CPU with HT enabled. FSX is not the same.

Thanks for your explanation above. I am aware of what you say.

 

I'm on W10-64 P3D32 i6700k HT on.

 

When I use the jobscheduler with whatever AM, the main sim job pegs at 100% on it's own LP.

 

I close the sim, remove the jobscheduler entry and manually assign an AM in the task manager as this: 0010 1110 during the initial startup loading of the sim (specifically at the dll.xml entry point).

 

When the simulator puts me in the VC, the main sim job does not peg but sits between 50-95% depending on load.

 

I put my addons on 1100 0000 regardless of jobscheduler.

 

 At some stage I'll upload two comparison graphs.

OK, GOT IT! Will do some testing.   :smile:

Normally I would do a series of tests but I did three off the bat one after the other after running a scenario through twice first. The result was fairly conclusive. Simply starting the sim with an AM=116 (0010 1110), outperformed changing to 116 from no AM or AM=255. Addons on 192 (1100 0000), two simconnect panels and the data logger.

Also I tried with addons on 3 if that's what you had going. Same thing happened, best setup was simply to set AM=116 put addons on 3. With my six core I could improve that slightly with AM=85 and addons on 3072. Loading two separate scenarios timed as only three seconds between all the setups I tried, 44-47s across all the tests with the faster loading from the AM=255 changed to 116, we always get a slight improvement when adding more that four ones to the mask. Essentially starting with no AM then changing to another AM with less LPs than the first resulted in worse performance in the fps and fps stability, slightly faster loading by 6.5% over the worst loading speed result (116 addons on 192). The cores all gained in activity and produced no better result with that method. More activity showing is all those jobs corralled onto fewer LPs. I made all tests with vsync and AA off, unlimited setting on the slider, setup producing around 80fps, repeated saved scenario just entering a turn leaving an airport overlooking the departure. The change in loading capacity, or hardware can be a big factor in seeing different results.

http://www.prepar3d.com/forum/viewtopic.php?f=6312&t=117651&p=130912&hilit=affinity#p130912

That's not an error, it's because P3D is provided with proper control of the CPU with HT enabled. FSX is not the same.

I concur. Seems to me they couldn't do much more.

Here are my results. I'm only interested in showing how the main sim job is pegged at full load 100% when using the jobscheduler.

 

Jobscheduler AM=58 (equivalent to AM=116) but addons put on last core not first core:

https://dl.dropboxusercontent.com/u/67140225/P3D/Jobscheduler%20AM%3D58.JPG

 

 

AM set to 58 in the task manager with the jobscheduler entry removed from the config file:

https://dl.dropboxusercontent.com/u/67140225/P3D/Task%20Manager%20AM%3D58.JPG

 

Notes:

• using the jobscheduler causes the main sim job to be pegged at 100% causing slow drawing textures and terrain.
• setting the AM externally and not using the jobscheduler causes all the jobs to bob up and down according to load as you would logically expect. Even the main sim job can drop to 50% or less in light loads. The renderer jobs respond as they should according to need.
• setting the AM externally causes textures and terrain to draw normally
• setting the AM externally is doing what the jobscheduler should do but doesn't because it is busted.
• I am setting the AM externally, by pausing the sim during it's loadup using the dll.xml file to ask whether I want to load any dll. At that point I set the AM in task manager affinity dialog.

It is very important that the jobscheduler is sorted out because it is not good enough to allow the operating system to decide where addons should go in relation to the simulator. Doing that causes unnecessary stuttering.

It's interesting because you are starting eight jobs, but then unchecking LPs in task manager moves them onto four LPs on three cores, this leaves an entire core free for system processes. Starting with eight jobs increases the loading rate for scenery. Certain scenery may respond well to eight or even more jobs in total. If they are not able to process at over 50% then two per core would run near 100% but not fight for throughput. It's a reasonable technique.

 

If the scenery doesn't require lots of jobs, then this excess of jobs actually negatively impacts on the sim performance.

Using the jobscheduler is overloading the main sim job which is why it is busted in my opinion. Notice that it uses less threads but dumps the rendering jobs onto the main sim job. This causes weird effects with terrain drawing, texture and stutters. When people complain about problems, they are told it is their fault and to go and reduce their settings when that is not the problem. They want to use the jobscheduler because it makes sense to use it, but are punished for doing so as it stands with P3D32. When I set the AM externally, the simulator performs as if it had the computer to itself.

 

 

By the way, I don't think AM=58 is that good, I just used it because it is a shifted version of AM=116 good for comparative testing. The best is this one: 00101110 because it keeps off the operating system jobs as much as possible. The operating system insists on using the first LP of each core even with HT on. It is as if there is some code running in the system that is unaware of HT even if it is turned on. The reason the addons are on the last core is because for some reason, the simulator needs to run using the first core onwards in P3D32 which could be a side effect of the busted jobscheduler issue.

You mean using the jobscheduler section in the cfg to assert an AM doesn't work properly?

 

That works fine as far as I can tell.

 

By the way, if you give it AM=58 is not equivalent to 116 at all, since 58 groups the third and fourth jobs onto a single core. Jobs 3 and 4 regularly max out and require full throughput but don't get it, they get 50%. Instead 116 is quite important because it groups jobs 2 and 3 onto a core, that's because jobs 2 and 3 don't regularly max out together.

 

The best is this one: 00101110

Yep that's 116. Now you are talking.

In my opinion in P3D32 the jobscheduler is busted whenever it decides to keep the main sim job pegged at 100% load. It should drop back down but doesn't. It works, but there is something internally in the threading messed up. Check out the thread count in my graph results above. The jobscheduler has put the rendering threads onto the main job and decreased the total thread count. It works, but the simulator has no capacity to absorb dynamic changes in load.

...trouble is, when you uncheck those boxes the result of where the jobs go is mixed up to how they would start. I needed 212 for the better result to get the LP with the main activity onto a core of its own, 116 was no good.

 

Starting with 116 putting addons on 3 was still the major title holder of the night testing here.

I think you guys are talking about two different issues here. Steve, if you never had blurries then the tests you did probably won't show the difference between setting AM internal and externally. Except for fps and smoothness because that will definitely vary depending on the method used to set AM

 

However if you had blurries like glider then you would see how an external AM seems to negate the issue, but no matter what AM you set with the jobscheduler will yield blurries.

 

One thing I've noticed with setting an external AM is that VAS usage is a lot higher. I have HT off on my 6700k with settings tuned for minimal VAS usage but it OOMs on a 2 hour flight from an addon airport to another. This doesn't happen with a internally set AM.

 

Again a trade off I guess. Seems like the best option is to use HT off no AM and live with a few blurries here and there.