P3D running but CPU not running at max speed

[SteveW 1,792]

2 hours ago, AnkH said:

Ok, I did remove UT2 out of my exe.xml and started it manually via .bat file. This works, the correct cores are used. However, I see no benefit at all (rather surprising), in contrast, when UT2 fires up and loads the traffic initially into the sim, it takes about 10 seconds and the P3D window gets the "not responding" tag. As soon as the traffic is loaded, the FPS are identical to the situation when UT is started via exe.xml on my rig. Additionally, when starting UT via exe.xml, the initial loading of AI traffic after P3D fired up takes only about 2 seconds and no "not responding" message.

Verdict: on my rig, running UT2 on specific cores started outside the exe.xml has absolutely no benefit at all. Now I am back to the exe.xml startup procedure...

Don't throw away the rule book. If that's the conclusion on your system than that's it for you. You can actually slow down P3D if the utl or any other simconnect exe is restricted with too few LPs.

Remember a minimum of two LPs, a maximum of how ever many you can afford. On 4 6 and 8 cores it's not going to yield that much. You are looking for balance, not an fps yield - fps yield comes mostly from not sharing the main core and not restricting addons too far if they run certain simconnect functions.

[SteveW 1,792]

With P3D think of it as two tasks, one updates the screen, the other goes around gathering information and constructing the scene.

So we can improve fps, and we can improve that background process. The slicker that gets does not mean we get more fps, maybe a few percent. What we get is smoothing out.

If you boot up the sim and seem disappointed that there's no massive fps hike, then apply the thinking, what are you expecting to gain. If you are moving stuff off of the main core expect some fps. If not, then some other redline or limit is reached elsewhere.

It's simple arithmetic in the end. More work you offload from P3D the better it gets. When you have a limit or a redline or simply no more to give then there will not be any change in performance.

Edited January 17, 2019 by SteveW

[SteveW 1,792]

...basically UTL does very little on the simconnect interface. The Ai traffic injection in P3D is also lacking in any real overhead. The aircraft activity invoked far exceeds the throughput requirement of UTL.

None the less, when we take the load off the donkey it can go farther. So whatever we do always adds up to a total, whatever effect we see with a simple observation of the sim. The performance of the overall system can't be spotted so well simply looking at fps.

Whether we need to assert affinity on UTL is more a matter of choice on that system. As Dirk pointed out an easy way to go is start the lot, including P3D from a .BAT and properly designed will render a P3D system with more capacity.

The ultimate capacity of the fps is simply proportional to the number of things we request must be done between frames. decreasing settings improves fps just like decreasing shared work on the CPU. If those settings combine to make a scene that takes longer to construct than the time between frames the fps drops. Varying fps is what gives the illusion of stutter and poor performance, not the fps count as such.

Edited January 18, 2019 by SteveW

[SteveW 1,792]

24 minutes ago, SteveW said:

As Dirk pointed out an easy way to go is start the lot, including P3D from a .BAT and properly designed will render a P3D system with more capacity.

Just to be clear: That's talking about asserting an order of things, and setting affinity on those apps that don't handle it, we're not suggesting P3D be started with affinity in that bat, just started with an AF=0, so no affinity statement is required starting that, P3D handles itself best.

The way the system is set up in the first place also plays a part in the outright performance. A lot of systems come with an SSD and a large HD. What I see is folk installing onto that slower drive. P3D system settings are stored on C: anyway. It is a slightly better system that installs onto the SSD and moves non-essential addons and scenery to the larger disk, that disk is then accessed when required. An Optane system which caches disk accesses can help in this situation since it is also a kind of RAID with more bandwidth. Even an all SSD system can benefit from that. The XEON Platinum £9000 a chip incorporates techniques like that on-chip and does not need a specialised controller for RAID. If the sim has been installed on another drive purely 'in fear' of installing to the 'proper location' as it 'causes problems' were led astray, unfortunately.

Edited January 18, 2019 by SteveW

[AnkH 2,233]

13 hours ago, SteveW said:

You are looking for balance, not an fps yield - fps yield comes mostly from not sharing the main core and not restricting addons too far if they run certain simconnect functions.

Sure, that's why I am happy now with limiting REX, ActiveSky and ProATC/X via batch file to four LPs only (Core8, Core9, Core10 and Core11) and keep UT2 as it is. Seems that for my setup, that is the way to go.

[SteveW 1,792]

Cool.

[SteveW 1,792]

In a similar vein, when we enable HT we don't change the core speed, the core in everyday use does not attract or run more threads. So HT yields not a lot of fps. Just that thread swapping is improved by having the pair of contexts to keep the speed up, and use up more cycles. No matter what, there will be threads changing out, and with HT that improves the performance a little in terms of the quality of fps, and just a little fps boost. But with all those other cores saving cycles and it adds up to a slicker 'back end' without a doubt.

With no AM we lose fps enabling HT, leading to bulging within the HT-Off-no-AM crowd.

The background tasks access resources more freely with HT enabled and with less waiting and communicate the result to the main task more sweetly. It's not so obvious when simply viewing the sim, and it's not at all obvious if any of the limits are reached within the sim.

Any time I see 100% on an LP, none of the settings matter a jot, and the advantage of the techniques I'm discussing goes out the window. That is so easy to do that every time I hear a situation of taking weight out the bag does not reduce the weight of the bag, there's definitely a limit already reached.

Even though  moving UTL seems to do nothing, it will be something. Whether it's worth doing is the same as any configuration, are there enough cores, what else is more important.

After all if we allocate more cores than we need for P3D that does in a way enable more addon activity within those cores, when we start the addon with P3D, as then they can only run on those inside the AM of P3D.

The fact is, we must assert the best partitions for the best results, *if we want them*, even though with recent rigs the sim performs 'adequately' just slapped on and forgotten.

[Cruachan 705]

Hi,

Interesting read which compliments Steve’s explanations:

https://en.m.wikipedia.org/wiki/Hyper-threading

One question:- Should we be referring to each logical core within a hyperthreading-enabled CPU physical core as a logical core or logical processor? Does it matter so long as we include the word ‘logical’?

Mike

 

[SteveW 1,792]

33 minutes ago, Cruachan said:

Hi,

Interesting read which compliments Steve’s explanations:

https://en.m.wikipedia.org/wiki/Hyper-threading

One question:- Should we be referring to each logical core within a hyperthreading-enabled CPU physical core as a logical core or logical processor? Does it matter so long as we include the word ‘logical’?

Mike

 

Some CPU's have four or more HT 'Logical Processors', whereas our desktop CPU's usually only have two LPs. They are LPs because no matter how it looks to Windows, there's only one core. The 'Logical' part of the name is that it 'fools' the software into appearing like two real cores. In effect the apparentness of HT is only to us, the machine doesn't really know the CPU is using cores to emulate double the amount. It's a good trick to do, with only a simple inclusion of the context stack, but overcomplicates the configuration. 

[jagabom 21]

Ray, how is that CPU 8087 working.  Frames etc.  I am looking at one myself.  

Jim

CYWG

[Ray Proudfoot 8,927]

54 minutes ago, jagabom said:

Ray, how is that CPU 8087 working.  Frames etc.  I am looking at one myself.  

Jim

CYWG

It’s an i7-8086K. Very pleased with it. No point giving frames without describing all my settings. And I don’t know what card you’re using.

[Nyxx 6,993]

On 1/16/2019 at 11:46 AM, Dirk98 said:

Lol,

David, since you are on v4.4 already, could you check  11.11.10.10 affinity on your system (which is =250 JobScheduler)

Thanks,

PS: there were very positive comments about arranging 2 first cores like that xxx.10.10

Hi Dirk.

I just spent an hour testing AM=250, I had more cores working with AM=250 ofc but with high P3D setting the active cores were maxing out and I got texture loading problems.

AM=250 was a bit smoother, but I went back to 85 as only 3 cores are working hard plus 1 around 25-30%, but unlike AM=250 the cores topped out around 85-90% with no bad texture loading. So thank you for the thought and I enjoyed testing AM=250 for myself.

Cheers

David.

 

[Nyxx 6,993]

@Dirk98

I think I've just got what I've been looking for since 4.4. 

4.4 has been running so well. Been enjoying the PMDG -8 and the NG. But not been enjoying the FSL 319 at all, to the point last week I deleted it. It did not matter what I did I could not stop the nasty FPS jumps from my Locked 26 to flashing to 7-8 FPS or more often 14-18 FPS. It was almost rhythmic to watch it, I looked out the VC at 90 degrees to the left. It was very frustrating. 

After all the testing above and settling on AM=85, I took a deep breath and installed the FSL A320/A319. I stopped the app from removing my AM. Now what I've seen in all my tests with the NG/-8F is with AM=85 only 3 cores work hard and core #3 (01,01,01,01) like I said above sits at 25-30%. 

I loaded up my test flight once more and repeated the same test I always do. But this time the FSL ran like a dream. Because I was watching all my cores at work I saw one huge difference from the countless testing with all other aircraft.

Now Core 3 was working at around 75-80% constantly. Never dropped below 70 and never went over 90%. 

I can only conclude that having no AM was bottle necking the cores that the FSL used/needed. But with the AM it's freed it up and what a difference it makes. 

Am now so happy I read @SteveW finding and along with your thoughts, doing so has not only freed up a few more FPS but more importantly made the sim run so smoothly even with the FSL. 

Just to finish off, I took of from EGNX my home airport and the one I use for all testing. I turned south to run the sim and watch what was happening at a height of 10,000ft. I Ended up close to Aerosofts EGLL, I turned to swing by it, to  the south but very close to it, then flow right over the city of London. FPS never dropped below my new LOCK 28 FPS for the Bus. If it can handle EGLL and the city of London that's as good a test as I need to do.

Thank you both very much. You have made me very happy with my sim. I just wanted to express my gratitude to you both. 

Edited January 18, 2019 by Nyxx

[SteveW 1,792]

9 hours ago, Nyxx said:

@Dirk98

 I stopped the app from removing my AM.

But this time the FSL ran like a dream. 

It is not the remit of an aircraft package or any kind of addon to adjust, or assert some kind of bad AM theory on the poor user. Removing an AM from a highly tuned system can blow it.

[SteveW 1,792]

With no AM the system will allocate every LP to P3D which pushes out the resources the FSL modules are actually using.