Noticed this today. Anyone else understand what is happening here.

If I fire up P3D4.4 as normal and go flying, when I check Taskman it shows all 12 cores on my PC being used nicely, but core0 is at 100% usage all the time. The rest are churning along between 20 and 50%.

Yet if I go into the CPU affinity settings and tell it not to use core0, then core0 as expected stops being hammered at 100%, and the 100% hammering does not transfer to another core.

However, if I then within the same sim session I re-enable core0 for P3D, core0 now acts just like all the others, jogging along nicely at 20-50% exactly like all the other cores. The 100% hammering is gone, yet the sim continues to work just fine with no visible difference in performance.

Has this been discussed before? Anyone know what is going on here? Is this some legacy bad programmed from FSX days - FSX alwasy hammered one core at 100% regardless of what you did to affinity, at least in my experience on exactly the same machine.

It would be nice to get to the bottom of this and get it 'fixed', because obviously something is not quite right in this department.

I can't offer an answer , but confirm that your experience is correct as I can reproduce it. Also it is not always with core0 , if you mask core0 on start with an AM , the next core will be maxed out , repeating the process it will use all cores equally.

 

Jorge

This was discovered quite some time ago with varying degrees of effect.

I suspect that the way P3D was designed included core 0 at or about 100% for whatever reason. Just because that core is at 100% does not mean that something is wrong or it needs to be fixed.

But, you never know.

Cheers,

Mark

Ultimately, the assignment of threads to specific CPUs (physical and/or virtual) is done by the operating system, not by the application.  The application (P3D in this case) only has limited input into that process, e.g. which cores the OS should be allowed to use, but beyond that, this is OS behavior.

The OS will assign threads to cores (within the affinity mask constraints) based on the processor loading at the time, so when P3D first loads up on an idle PC, it assigns the first thread(s) associated with the processor-intensive main program to core 0, more than likely because not much else is running and it's the first available core.  When you change the CPU affinity after it's already running, those threads from the main program are likely being reassigned based on the core loads at that time, which is going to look quite a bit different than an initial load from idle.

That said, I don't think there's anything here to fix.  Looks like a normal multi-processor OS at work.

Regards

There has been some debate about how much control P3D has over which cores to use for its various threads, but the behavior that you noted is indeed typical. It looks to me that the first two available cores are specifically assigned by P3D, and the remaining cores get used as required for scenery loading tasks.

If you go and reassign the affinity, you change this behavior.. whether that is for the better or the worse I do not know..

Edited March 30, 20197 yr by Bert Pieke

I would like to disagree to a certain extent here about "the assignment of threads to specific CPUs (physical and/or virtual) is done by the operating system, not by the application."

Besides the OS (operating system) also coding in applications for multiple cores is a factor. Some games and applications are better or worse optimized to take advantage of multiple cores usage, even LM (P3D) acknowledged that they improved multicore usage in our game. Unfortunately not good enough and they still have issues (mostly related to a core being at 100% saturated that is causing stutters etc) 

I'm a P3D user since day one and still, I'm not ready to switch to XP11 where XP11 has a far better core usage across the software and fewer issues related to core optimization.

Even you can use affinity mask settings, unfortunately, you always will have a core at 100% (on P3D) and that one will create some issues because of improper load balance.

We always can hope for a fix or to switch to something else with fewer headaches. 

This is a bit tangential but I've used my old SB-E w/ HT on w/ an AM of 4084 versus HT off w/ essentially the same AM (111110) for my 6 core non-HT and in the exact same flight, while the non-HT config runs about 4C cooler, it's not nearly as smooth as w/ HT enabled I had a truly perfectly smooth flight, side-to-side panning, taxiing.  With HT off while I was able to O'C 0.12gHz more ultimately the flight was considerably less smooth.  For my next upgrade I am considering I9-9900K just to have headroom for better multicore utilization. Near as I can tell the future for developing is exploiting multicore and GPU so having at least 8 physical cores w/ HT potential is the way to go for today.

1 hour ago, killthespam said:

Unfortunately not good enough and they still have issues (mostly related to a core being at 100% saturated that is causing stutters etc) 

Even you can use affinity mask settings, unfortunately, you always will have a core at 100% (on P3D) and that one will create some issues because of improper load balance.

You always have a core at 100%?

Are you using P3Dv4.4?

Hmm. With 12 cores available, having one at 100% and the rest merely jogging along has to be bad programming/OS assignment/whatever.

It certainly cannot be a good thing in a real-time critical app like a simulator.

I'm always amazed in the forum world when people try to defend and explain away plain simple bad things like bad programming from a multimillion dollar company. This 100% core0 thing has existed since MS programmed FSX many years ago. The fact that the sim runs very nicely with all cores just jogging along after a simply disable/enable core zero, and thereafter for the rest of that sim session, shows that something is wrong, probably in the startup assignment of threads, and it needs fixing.

Or do you recommend that we keep the 100% core0 and all continue to buy more and more expensive CPU's to cope with the core0 demand, while we have plenty more cores not even breaking a sweat?

Especially when it appear a quick line of code after sim start to disable/enable core0 might well cover this issue with 5 minutes of coding.

I'm pretty sure core0 is getting hammered for very good reasons.. programming across multiple cores isn't just some straight forward thing and yo don't jus give more cores and the code handles this in a nice and orderly way. Core0 is no doubt doing the heavy lifting, making calls and trying to orchestrate all of what you see going on in game by getting other cores to do some of the work, but ultimately it is that one base core that's running the show.

It would be ace if you could just add more cores and things simply got faster and better, but sadly this is most definitely not the case.

I'd also check how the sim is running after you mess with the affinity settings whilst it's running. I'm pretty sure it's detrimental to the overall running of the sim.

Sure. I'm still testing this. I still think it's legacy coding from FSX. I have plenty of other detailed graphical games which manage photoreal scenery without any one core taking a beating.

With hardware VSync and a 30 Hz (4K) monitor, my core 0 in P3Dv4 typically sits around 70% on the ground with complex acft/scenery and AI, and often in the mid 30% range inflight, certainly not 100%.

@SledDriver--do you have 12 cores, or are you running a 6-core CPU with hyperthreading?  There is a significant difference between a physical core and a virtual CPU on an HT-enabled processor.

@killthespam--a good multi-threaded application enables the OS to spread its workload out by splitting the workload across threads.  Unfortunately, with real-time processes with lots of thread dependencies (like P3D), that's a lot harder than it sounds. 

Regards

6 minutes ago, SledDriver said:

Sure. I'm still testing this. I still think it's legacy coding from FSX. I have plenty of other detailed graphical games which manage photoreal scenery without any one core taking a beating.

That's why I mentioned that LM (p3D) needs to find a way of optimizing the core usage properly, not as it is now.

2 minutes ago, w6kd said:

 

@killthespam--a good multi-threaded application enables the OS to spread its workload out by splitting the workload across threads.  Unfortunately, with real-time processes with lots of thread dependencies (like P3D), that's a lot harder than it sounds. 

Regards

1

Bob,

That's why I mentioned that IMHO it's not optimized properly when in their coding one core gets 100% hammered and other barely 40 or 50%. And when 1 core gets saturated that CPU as a whole is not working properly anymore, overheating, stutters etc, based on what I did see on my PCs with 8700K, 8086K and 9900K with a  GTX 1080Ti or RTX 2080 TI. Same PCs running XP11 or other games I did not notice this issue. 

 

4 hours ago, killthespam said:

I would like to disagree to a certain extent here about "the assignment of threads to specific CPUs (physical and/or virtual) is done by the operating system, not by the application."

Besides the OS (operating system) also coding in applications for multiple cores is a factor.

There is no disagreement. The application as its coded can divide the work between separate threads. What CPUs those threads are executed on is up to the OS.

Cheers!