Look in:

C:\Users\[you]\AppData\Roaming\Lockheed Martin\Prepar3D v3

 

see exe.xml, open in notepad, it's what the sim uses to find the exe files to run. It looks very much the same as dll.xml, you will see entries in there that start .exe files when the sim starts. Make a .bat for those exe's and make an entry for your .bat (like my example but with your path and name).

 

...the dlls listed in dll.xml, we can't do anything more with those.

I have never seen any of these (exe addons) ever uses more than 2-3% of my CPU time

Problem is they consume CPU cache and look ahead prediction.

I mentioned earlier, addons dll or exe, generally invoke a simconnect client, which in turn invokes the network resources. There's no need for other processes on a core to run at high percentages to get the main thread sawtoothing. But a weather engine doesn't do much for 15 minutes then injects a load of data into the sim, it wants to be off the main sim core when that happens.

 

 

The dlls loaded by the sim run in the affinity of the sim, and make a simconnect client.

 

I've spent all week moving addons around and yes they do definitely 100% make problems. I do my homework.

 

Where did I say they don't cause problems? They definitely do, but they moving them do not solve all problems either. 

 

Would moving these dll created simconnect clients off to other cores make things any better?

The one you got to be sure to give the whole core to is the first sim job. The simconnect clients will run up on threads within the cores of the other jobs. Keep anything you can off of the main core. Since addons run when the sim runs we can at least keep them off it. If we have any purposeful exe threads running on the core with the main sim thread it gets problems.

The one you got to be sure to give the whole core to is the first sim job. The simconnect clients will run up on threads within the cores of the other jobs. Keep anything you can off of the main core. Since addons run when the sim runs we can at least keep them off it. If we have any purposeful exe threads running on the core with the main sim thread it gets problems.

 

The simconnect clients are essentially conhost.exes right? They run on the same affinity as Prepar3d. Will try moving those off the main job.

Problem is they consume CPU cache and look ahead prediction.

Maybe you could explain that in more detail. My Xeons have 12M of multilevel L3 cache which is shared among the 6 physical cores. A 4790k (a CPU often discussed here) has 8M.

Well, you've got more than most! If the core has to keep swapping threads it loses the associativity the usefulness of the branch prediction is lessened.

 

...That's improved when using HT mode of course. In the link you supplied a few posts ago, the LM dev explains that to be wary of HT mode because the sim will place the first two threads onto the one core, and so the example AM=14 in the manual (the default AM he mentioned) shows how to avoid placing two jobs on the first HT core by utilising the masking of one LP.

Yes sort of. The Windows jobscheduler always runs and takes care of those threads. The AM in the cfg is utilised by P3D and FSX to lay out the initial thread jobs - P3D makes as many jobs as there are LPs. What you are seeing is that by unchecking some LPs in Task Manager, the threads on those move onto the least used cores of those still checked. When you do that you are de-stressing those cores that you moved the treads off of. This allows the JS to put threads there it can move around. The threads corralled together don't harm each other, the result of these looks different top what you would expect, you don't see the pegged 100% job as you would not if you set vsync and have a 24Hz refresh. The problem comes if any of those bunched together start to ask for more than 50% each, then they are restricted in their performance. In tests, this can work a little depending on how much system resources are utilised, how many simconnect clients are created and so on. Usually it's best to start with the proper AM. In my posts I show that starting with four produces the best performance on regular scenery, 6 can work better on heavy scenery. On a four core, no matter how many LPs are allocated, there are only four cores.

 

Regarding the VAS; every thread created takes up a little memory from that available to the process. Around 3.5Gb is available to P3D on a 64bit system. Each 32 bit thread takes a little bit more than a 64 bit thread, since each 32 bit thread invokes the WOW64 process that is a slight overhead too. But anyway, if we start P3D with a four core HT on and AM=85 (4 LPs of 8), or we start P3D with no AM on a four core HT Off (4 LPs of 4), it uses the same VAS. The HT version performs slightly better but uses the same VAS as the non HT version.

 

In the example of starting with no AM in the cfg and unchecking LPs, P3D creates a job per LP (as was stated many times, I'm thinking of you TheBoom lol), and then those threads of those jobs are moved onto the remaining LPs still checked in the Task Manager details. When I tested that (on a professional test harness) the scenery loading speed came down since the scenery loaders were now sharing less cores with more threads.

Thanks for the explanation Steve there is a lot of useful info in it. I still think that the P3D jobscheduler entry is not working properly with HT mode because although it is masking off what LP's may be used, it is putting other internal sim jobs on top of the main sim job on the same LP in some cases. I'm very stubborn on that until I am absolutely sure I am wrong.

 

I think it could be because of an interaction between the operating system and the simulator where the main sim job is inactive during boot up and something in the sim or operating system then thinks that it is acceptable to put other sim jobs on that same LP as the main sim job. Then the main sim job comes to life but the other jobs are not shifted off, and all of a sudden we have an LP that is pegged at 100% load and although it works properly, it creates issues (mainly potential for stutters but also rendering).

 

Sorry if you have already addressed this. I actually want to be wrong so that I understand. I put theories up that can be disproved and then hopefully this helps with understanding.

No apology necessary, I'm reading every word you say I have taken note and I'm looking into the possibilities. It's an observation that is correct in what you claim to see. I'm still sure that this is simply down to the fact that the minutest sleep to the main thread puts it way off the near 100% it appears to be shown at in Task Man, and that the freed core is de-stressing the system (in terms of cache not bandwidth). I'm getting plenty of good data from others and I'm doing some more testing to see if I can be more sure about it.

@NBVA30 don't know if you already get the answer why you had this blurry textures? I only searched the sites after this two tweaks you had in the .cfg, but no one has mentioned it.

 

 

You had two tweaks in your cfg which caused this problem.

 

[GRAPHICS]

ENABLE_MEMORY_OPTIMIZATION=1

 

^^This doesn't exist by default, i think the naming says already what it does.

 

[sCENERY]

MaxRegionsPurgePerFrame=32

 

^^This exist by default but, the default value is 16.

 

Hope this gives some clarity  :smile:

 

 

MaxRegionsPurgePerFrame=32

 

Changing this value is to be done only if you are running into VAS issues ... increasing this value will shift CPU resources to memory disposal, BUT at the cost of reduced time on terrain loading.  In FSX this value default was 4, in P3D it's 16 default, only reason to increase this is if you have a VAS problem and/or run many logical cores.

 

Cheers, Rob.

Changing this value is to be done only if you are running into VAS issues ... increasing this value will shift CPU resources to memory disposal, BUT at the cost of reduced time on terrain loading.  In FSX this value default was 4, in P3D it's 16 default, only reason to increase this is if you have a VAS problem and/or run many logical cores.

 

Cheers, Rob.

 

Does it work both ways? If say, we change it to 8 would that reduce terrain loading times?

 

 

Does it work both ways?

 

Yes, but at the cost of higher VAS ... there are also other factors where changing this value may have no impact at all, pends on how hardware balanced your PC is and where you have bottlenecks.  Not something I recommend, but no harm in experimenting.

 

Cheers, Rob.

Changing this value is to be done only if you are running into VAS issues ... increasing this value will shift CPU resources to memory disposal, BUT at the cost of reduced time on terrain loading.  In FSX this value default was 4, in P3D it's 16 default, only reason to increase this is if you have a VAS problem and/or run many logical cores.

 

Cheers, Rob.

 

Thank you Rob i didn't know that.

Everyday you learn something new  :smile:

Yes, but at the cost of higher VAS ... there are also other factors where changing this value may have no impact at all, pends on how hardware balanced your PC is and where you have bottlenecks.  Not something I recommend, but no harm in experimenting.

 

Cheers, Rob.

 

Thanks, but I seem to have fixed the blurries and had problems with VAS instead, so I went up instead to 32 and it seems better.