The OP and any other can happily opt out of a thread if he has no interest in further discussion, of notes arising from the thread, or other points of interest that might occur.   :wink:

 

It was a joke. Don't get me wrong, Steve, I enjoy your discussion with npole.

...I thought it probably was - lol

LOL I am here 

I dont know what to do with the AM...

I did some testing with a 6 core and I would say you can ignore the AM, or if you like in the P3D Prepar3D.cfg I would put:

[JOBSCHEDULER]

AffinityMask=60

I did some testing with a 6 core and I would say you can ignore the AM, or if you like in the P3D Prepar3D.cfg I would put:

[JOBSCHEDULER]

AffinityMask=60

 

Isn't that 4 jobs spread over 2 cores? Won't it be worse than 116 for example?

Its a 6 core 6 thread CPU, so AM=60=111100 and utilises the last four cores and leaves two up front for the system and addons.

As another entry into the "each system reacts differently" pool - I have finally concluded that what is working best for me is HT on AM=255.

 

I tried HT on/off, AM's from 14, 15 84,85,116 - Process lasso enabled/disabled and keep coming back here.

 

What's puzzling to me though - if I use AM=255 I get best results - if I remove the AM entry - it should default to 255 correct? But why is my performance different when no AM is present, all else being equal.

 

The other thing I noticed, simply using task manager to watch the cores - HT on - AM=255 - no process lasso or other add on core assignment -  running PlanG, ASN and TrackIR - 

 

LP 0 stays pretty well maxed while LP1 about 10% - but lp's 2-7 stay about 60% across the board.

 

This is on the [email protected] with 970's SLI.

 

So far the other things tried result in either slight stutters or slight blurries.

 

Just an observation of what works on MY system.

 

Vic

 

 

What's puzzling to me though - if I use AM=255 I get best results - if I remove the AM entry - it should default to 255 correct? But why is my performance different when no AM is present, all else being equal.

 

Excellent test well done. I agree with you. If you put AM=255 it should be identical to deleting the jobscheduler - but it isn't. Why? Answer - take a look at your CPU traces.

 

I'm fairly sure that the jobscheduler AM entry which isn't officially supported, is unfortunately bugged. It does allocate cores (LP's) as designed and on the surface it looks the same as you would expect, but the threads are internally messed up and performance can and does suffer by using it. In your case, the jobscheduler has improved performance, but I wonder if that is just an accident?

 

It is really important to look at the CPU traces while the sim is running. In theory (and if you logically think this through) all of the sim jobs should bob up and down between 10-90% depending on load (including the main job) - but they dont.

 

In practice, the jobs get stuck on 100% even when the load comes down. I set the AM externally and don't use the jobscheduler. For me, all the sim jobs are performing as intended, even the main sim job comes down off it's 100% peak when the load drops. That doesn't happen unless I intervene in the threading allocation of the sim. I think it has to do with old code that still doesn't work properly in a four (8 LP) environment.

 

I know I am going to get hammered for saying that, but whatever. The current complaints about blurry textures are not just because people are putting their settings too high, there is an underlying problem with the threading.

 

 

The current complaints about blurry textures are not just because people are putting their settings too high, there is an underlying problem with the threading.

 

I suspect you are correct from my layman's observations but I don't have that depth of knowledge to argue one way or another. When I get into an area where I lack the official expertise, I rely on my eyes - if MY system runs well then I am happy.

 

Vic

Just realise why I think people using AM's via the jobscheduler are getting better performance. It is because the jobscheduler allocates cores (LPS) as you would expect, but the underlying threading is broken - which ironically improves performance because the renderer can't render properly any more in some situations (blurries and terrain drawing) which allows the sim to enjoy better framerates and be more smooth.

 

That is theory (1)

 

Here is another theory.

 

Theory (2) In a HT environment (maybe even HT off), with no jobscheduler, the threading is still messed up internally even if it appears to be working when you look at the traces.

 

I argue for theory (2) because when I set the AM externally so that the sim is explicitly told what the AM is via the operating system (not the jobscheduler) all the sim jobs behave as they should (bob up and down according to load). The main sim job and renderers come down off their 100% peaks when the load comes off (that is the ultimate test).

Just realise why I think people using AM's via the jobscheduler are getting better performance. It is because the jobscheduler allocates cores (LPS) as you would expect, but the underlying threading is broken - which ironically improves performance because the renderer can't render properly any more in some situations (blurries and terrain drawing) which allows the sim to enjoy better framerates and be more smooth.

That is theory (1)

Here is another theory.

Theory (2) In a HT environment (maybe even HT off), with no jobscheduler, the threading is still messed up internally even if it appears to be working when you look at the traces.

I argue for theory (2) because when I set the AM externally so that the sim is explicitly told what the AM is via the operating system (not the jobscheduler) all the sim jobs behave as they should (bob up and down according to load). The main sim job and renderers come down off their 100% peaks when the load comes off (that is the ultimate test).

Isn't the jobscheduler an OS process anyway?

 

On thread loading, the way it was with 3.1 and previous versions is that the main job peaks out at about 90-100% while the second job about 50%-90% and th rest would hover between 10-90%, at least on my system.

 

I think you are right about the scenery rendering threads but the main thread has always been at 100% from what I've known since 2.5. It should not be hovering. It's ultimately the fps and smoothness decider/limiter.

 

 

On thread loading, the way it was with 3.1 and previous versions is that the main job peaks out at about 90-100%

 

Yep agree with you. In fact I even remember it was like that with FSX and DX10. To me though, despite what people say, it shouldn't be like that - but I could be wrong. You can change the main sim job behaviour if you set the AM externally, not via the jobscheduler. Then the main sim job bobs up and down with load. To me that is curious. Steve has said that setting the AM externally breaks the threading, but from what I am seeing there is no performance loss at all, the sim is smooth and the CPU traces don't max out much except under heavy load. On my i6700k system with HT, for the first time it is possible to distinguish properly between GPU and CPU loads. In some situations the CPU is not maxed out (not even the main job) while the GPU is. In other situations the CPU is maxed out but the GPU isn't. To me that is how it should behave. Using the accepted wisdom right now, the CPU main job is always maxed out. To me that is weird to say the least. But, hey, the main consensus could be right I totally acknowledge that. It has been like that for a very long time. I'm getting better results not following the consensus though.

If we have vsync+TB and NI limit or low monitor refresh we will see the main thread job at mid throughput...

 

I've tried No AM vs AM=0 vs AM=4095 on my 6core+HT 12 threads, P3D always pans out the same on that. Will try on four core later.

 

If we move the starting location of the jobs with Task Manager and it started with AM=0 we will move jobs onto LPs already occupied with a thread job and this may not be what we intend. If we really want more jobs per core, to allocate two jobs one per LP of a same core with the starting AM is better.

When we see big changes to performance, it's the way addons are working not the AM of the sim. Even an AM=1 will perform OK, well perhaps not that brilliantly, but not as bad as we might think. Addon dll's and exe's invoke simconnect clients. These clients are network bound, run in the affinity of the sim and in turn invoke activity within the O/S resources. These O/S resources appear on cores not necessarily within the sim affinity. So what I'm saying is, it's more important to worry about the addons than the actual sim. Addons (or the sim) don't need process lasso, they just need starting with affinity to avoid the main sim job if possible, use a .bat and make a desktop link to it just like your regular icons.

I have no disagreement but there is a difference between the theory and what I am seeing.

 

If I don't change anything except to set a jobscheduler AM entry, the main sim job hits 100%, stays there, and textures can become blurry.

 

If I now repeat except delete the jobscheduler and instead set the AM using the operating system (not with lasso but task-manager), the main sim job bobs up and down with load and rarely hits 100%, there are no blurries, better smoothness and no performance loss, and I get to use AM that makes sense (all the sim jobs bob up and down in a logical way and my addons are using the external LPs I have assigned with a reasonable loading).

 

What is the reason for that? If I am seeing an illusion, fair enough, but what is the explanation for what I am seeing, I don't yet understand it. To me it is illogical that the main sim job should be pegged at 100% anyway.