Sign in to follow this  
0Artur0

Unparking CPU cores

Recommended Posts

Can somebody please explain what is this and does it really help? I found this suggestion in this guide: http://aviationwb.com/p3dset.html

Some people are claiming that their stutters are gone when doing this thing but I'm a bit cautious since I have no idea what this "Unpark CPU cores" does. Any other side effects of using this unpark thing?

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Hello all,

 

I am also curious.  Does this apply to FS9.1 as well?  I already have smooth frames at 30FPS(limited) but if this can make things easier for my sim so much the better.

 

At the very least, this is interesting and I am wondering if it has any impact on the 64bit sims coming on the horizon

 

Regards

 

Tony

Share this post


Link to post
Share on other sites

Interesting his advice is to also disable HT. Relevant to our discussions in the Kaby Lake thread.

Share this post


Link to post
Share on other sites

I use it all the time in games like Battlefield where with i7s it can add 10-15FPS.

In FSX:SE it has no effect what so ever for me.

 

The idea behind it is to utilize full CPU at all times for faster access in multicore applications.

Simple tool with a on/off switch and works like a charm :)

Share this post


Link to post
Share on other sites

If they are unparked already how can unparking them help? Parking them reduces the available CPU bandwidth so leave them unparked. :fool:

 

If you get a highter temperature with HT enabled, that's because it's doing more work, maybe not increasing the fps by much but it does if tests on a professional test harness are properly carried out. The gain with HT enable is to background tasks, disk, networking, security, If you can't turn on HT because it gets hot you're too far up the heat curve. :fool:

Share this post


Link to post
Share on other sites

Hello all,

 

I am also curious.  Does this apply to FS9.1 as well?  I already have smooth frames at 30FPS(limited) but if this can make things easier for my sim so much the better.

 

At the very least, this is interesting and I am wondering if it has any impact on the 64bit sims coming on the horizon

 

Regards

 

Tony

Interresting!

I tried it at once, and it looks better. More fluid with some frames added.

I see a temp increase, but not much to be afraid of.

More stable fps.

 

But need to do a full flight to check it better. Could be placebo!

Share this post


Link to post
Share on other sites

Put it this way; these FSX based simulators have dozens of concurrent processes all running in the background, some take many seconds to complete irrespective of Frame Rate. If we increase the frequency of the CPU we can increase slightly the available FPS. If we decrease CPU bandwidth we don't affect the FPS much but those background processes finish LATER. You need to be able to account for the trade off of increased frequency for reduced CPU bandwidth. In tests it's better to go for bandwidth, not a few FPS. Other programs and games often work in a different manner to the FSX type of programs and how a different trend when adjusting the CPU performance characteristics.

 

With HT enabled beware of apps and processes that make double the use of the CPU because they see double the core count unaware these are actually pairs of HT cores.

 

We can simplify (very simply) the CPU core into two parts the data unit and the compute unit. An HT core has two data units and one compute unit shared between them. If you look at a four core with HT enabled and an 8 core with HT disabled, the main difference is the four core only has four compute units shared between the eight data units, the eight core has eight compute units (would still work better with its expensive HT mode enabled).



Interresting!
I tried it at once, and it looks better. More fluid with some frames added.
I see a temp increase, but not much to be afraid of.
More stable fps.
 
But need to do a full flight to check it better. Could be placebo!


No not a placebo! Parked cores reduce the CPU throughput so leave them unparked.

FSX:SE works out what to do with HT enabled but P3D will utilise each logical processor as if it were a real core so it is recommended to use an affinity mask for P3D to keep the main two processes on two real cores otherwise quite obviously we get a reduction in performance. It's one of those things that's a little too hard to grasp without a lot of thought.

Also some other processes on the PC as I said just now may make more use of the CPU when HT is enabled and so reduce the available bandwidth to the sim, this is not a reduction in CPU performance it is an undesired increase in use.

The easy thing to do is disable HT. Like driving slower because of poor brakes.

Share this post


Link to post
Share on other sites

Steve, I was testing on FS9.

Less fluctuations in fps and more smooth is what I saw.

Share this post


Link to post
Share on other sites

Steve, I was testing on FS9.

Less fluctuations in fps and more smooth is what I saw.

What did you do? Unpark cores? Leave them unparked.

Share this post


Link to post
Share on other sites

Yes, thats the thread about, unparking them.

Two where parked, unparked them and rebooted.

 

Does this from now on always be unparked ? or do I need to repeat this all the time ?

Share this post


Link to post
Share on other sites

 

 


FSX:SE works out what to do with HT enabled but P3D will utilise each logical processor as if it were a real core

 

Is there a citation on this? I believe the kernel is doing this.

 

All the AffinityMask setting does is call a Windows API call directly with the bitmap value to give the kernel scheduler instructions on what cores to use. Any modern Windows kernel should already be aware of the differences between cores and schedule accordingly. IIRC there was a kernel update years back when the AMD K10s came out to handle their interesting core model.

 

Cheers!

Share this post


Link to post
Share on other sites

I would have said they are unparked in default setup, you would have to park them to unpark them. Don't download any old software to mess around be sure it's malware free.

Is there a citation on this? I believe the kernel is doing this.

 

All the AffinityMask setting does is call a Windows API call directly with the bitmap value to give the kernel scheduler instructions on what cores to use. Any modern Windows kernel should already be aware of the differences between cores and schedule accordingly. IIRC there was a kernel update years back when the AMD K10s came out to handle their interesting core model.

 

Cheers!

 

Not true Luke, understanding how to utilise Windows threading and multicore is a commercial asset. I'll discuss some of this with you by PM if you like.

Share this post


Link to post
Share on other sites

 

 


Not true Luke, understanding how to utilise Windows threading and multicore is a commercial asset. I'll discuss some of this with you by PM if you like.

 

I'd prefer to have a public conversation. That way those who follow us can learn.

 

Here is the API call I was referring to: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686223(v=vs.85).aspx Note that the format of the parameter is exactly the same as the value you put in the FSX/P3D config.

 

Where am I mistaken? I'm genuinely curious.

Share this post


Link to post
Share on other sites

I'd prefer to have a public conversation. That way those who follow us can learn.

 

Here is the API call I was referring to: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686223(v=vs.85).aspx Note that the format of the parameter is exactly the same as the value you put in the FSX/P3D config.

 

Where am I mistaken? I'm genuinely curious.

 

That's the standard API call to *reconfigure* the app across the cores.

 

So you start FSX and then what? At some stage as it starts it reads the fsx.cfg and finds a value in the AffinityMask item. So then what does it do? Already it has started under the authority of the jobsheduler with the default AM=0. Now what?

 

(To be honest I'm surprised you think you need to explain that API to me.)

Share this post


Link to post
Share on other sites

 

 


That's the standard API call to *reconfigure* the app across the cores.

 

Exactly.

 

So you start FSX and then what? At some stage as it starts it reads the fsx.cfg and finds a value in the AffinityMask item. So then what does it do? Already it has started under the authority of the jobsheduler with the default AM=0. Now what?

 

It calls SetProcessAffinityMask() with the value from the config and tells the kernel what cores it wants to be scheduled on. What do you think it's doing? Do you think it's calling SetThreadAffinityMask()?

 

Cheers!

Share this post


Link to post
Share on other sites

It calls SetProcessAffinityMask() with the value from the config and tells the kernel what cores it wants to be scheduled on. What do you think it's doing? Do you think it's calling SetThreadAffinityMask()?

That (SetProcessAffinityMask) simply causes the jobsheduler to move the app onto the unmasked cores and won't work as you intended. Nuff said here don't you think?

 

So if you start FSX with AM=0 and go into task manager and uncheck some cores, that's the API you mention in action. It doesn't take long to see that the outcome to doing that is completely different to what FSX does with an AM value.

Share this post


Link to post
Share on other sites

 

 


That (SetProcessAffinityMask) simply causes the jobsheduler to move the app onto the unmasked cores and won't work as you intended.

 

I read the document differently:

 

A process affinity mask is a bit vector in which each bit represents a logical processor on which the threads of the process are allowed to run.

 

But this is all a distraction. Can you provide any sort of citation for the claim that FSX:SE and P3D schedule their threads differently? I am genuinely curious.

Share this post


Link to post
Share on other sites

I read the document differently:

 

A process affinity mask is a bit vector in which each bit represents a logical processor on which the threads of the process are allowed to run.

 

But this is all a distraction. Can you provide any sort of citation for the claim that FSX:SE and P3D schedule their threads differently? I am genuinely curious.

Why don't you write some code and see what these things do? FSX, FSX:SE and P3D all work slightly differently and as I said it's a commercial asset understanding what goes on under the hood there.

 

Here's another fly in your ointment; start FSX with an AM and when it's running go to task manager and see that it still appears to have an AM=0 as all the cores are checked. Do the same with P3D and you can see the masked cores are unchecked. So quite obviously they don't work the same.

 

I read the document differently:

 

A process affinity mask is a bit vector in which each bit represents a logical processor on which the threads of the process are allowed to run.

No I don't think so, you got it right in one. That's what I am saying when I say "causes the jobsheduler to move the app onto the unmasked cores" since that's what the AM represents, masked cores are not used so anything already there moves onto the unmasked (available) cores.

 

Once FSX has completed starting up with a specified AM value the jobsheduler is finally furnished with the AM=0 so that the jobsheduler is free to start subsequent threads anywhere on the CPU. P3D leaves the AM in place after it has started and so subsequent threads can only start on the unmasked cores.

 

It's best to realise that FSX, FSX:SE, FlightSchool and P3D all work differently in this regard and this information can be obtained simply with the use of Task Manager in an afternoon.

Share this post


Link to post
Share on other sites

Here's another fly in your ointment; start FSX with an AM and when it's running go to task manager and see that it still appears to have an AM=0 as all the cores are checked. Do the same with P3D and you can see the masked cores are unchecked. So quite obviously they don't work the same.

 

Thank you for the suggestion and pointing out the difference. I did actually write some code (with the disclaimer that it's managed, but I expect that the System.Diagnostics namespace is calling the API functions behind the scenes). If I set the process affinity, I see that reflected in Task Manager. If iterate through all of the current processes' threads and set their affinity, that isn't reflected in Task Manager.

 

 

 

No I don't think so, you got it right in one. That's what I am saying when I say "causes the jobsheduler to move the app onto the unmasked cores" since that's what the AM represents, masked cores are not used so anything already there moves onto the unmasked (available) cores.

 

I think you have it backwards. As the documentation states, the mask controls what processors are allowed to execute the process/thread. If I set a mask of 5, I am allowed to run on cores 0 and 2, and no others.

 

 

 

Once FSX has completed starting up with a specified AM value the jobsheduler is finally furnished with the AM=0 so that the jobsheduler is free to start subsequent threads anywhere on the CPU. P3D leaves the AM in place after it has started and so subsequent threads can only start on the unmasked cores.

 

From my example, what P3D is doing is consistent with it setting the affinity mask for the entire process, whereas FSX does not appear to be using this mechanism. It's definitely obeying the affinity mask, so it may be that the individual threads are getting the mask set, rather than the process.

 

What I'm not seeing is that there's any additional scheduling of threads beyond telling the kernel "execute on these particular processors". Again, I'm curious to see why you feel differently. I recognize it's closed-source and not something either of us have seen, but you seem to feel strongly that FSX:SE understands logical and physical cores differently (and better) than P3D. I don't see any evidence of that.

 

Cheers!

Share this post


Link to post
Share on other sites

You are making mistakes of mis-reading there again Luke. By *Un-Masked* look at your AM=5=0101 and so from the right to left core zero and core 2 are used because they are unmasked, core 1 and 3 are *Masked* and not used... no?

 

So you admit you see a totally different situation between FSX and P3D. Enough said about that then. Getting into conversation about actually programming this I'm not entering into.

 

Again, I'm curious to see why you feel differently. I recognize it's closed-source and not something either of us have seen, but you seem to feel strongly that FSX:SE understands logical and physical cores differently (and better) than P3D.

Here you are making statements for me which I've not claimed that somehow FSX is better than P3D in this respect. That's a leap of understanding you made. P3D is a professional app and that it offers us control of that aspect.

 

You seem to be talking about individual threads. There are more than 50 threads making up four "jobs" the simulator makes use of available *unmasked* cores as it sees fit. If you look at the documentation when these simulators split into four parts (with four logical processors unmasked) the main rendering stage is leanest. In other words if we allocate less than four cores the sim will group these jobs together. If we allocate more than four cores the sim splits the background tasks over those.

 

I hope this conversation has proved enlightening for all.

Share this post


Link to post
Share on other sites

The Affinity mask documentation is clear. The threads run on the masked processors.

 

Take your own advice please; write some code. Set your process affinity to 64 and do an infinite loop. You'll notice CPU utilization on core #7 spikes. Adjust affinity mask to match your core count. ;)

 

 


Here you are making statements for me which I've not claimed that somehow FSX is better than P3D in this respect. That's a leap of understanding you made.

 

Please go back and read post #7 in this thread. You might be familiar with the author. ;) I'm enclosing the relevant section below:

 

FSX:SE works out what to do with HT enabled but P3D will utilise each logical processor as if it were a real core

 

I'm just curious as to the basis for this claim. Through our investigations (thanks for the suggestion) it looks like P3D is setting the processor affinity process-wide, and it appears that FSX is doing so per-thread. Beyond that, they're leaving the ultimate scheduling up to the kernel. I don't see anything to suggest that P3D or FSX care about logical/physical cores.

 

You obviously feel differently. What should I look for as evidence that FSX is determining core types?

Share this post


Link to post
Share on other sites

Luke admit it you didn't know the difference between FSX and P3D. Also when I use an AM=64‬

...when I use an AM=64=01000000 there's only activity on core #6. The mask having only one one - the unmasked core.

 

As I already said the jobscheduler takes responsibility for where threads start. I think you found out a ton of know-how here.

 

(sorry for the oddness of the post; internet went down in my neck of the woods for a few minutes)

 

...I think you are mis-interpreting when I say unmasked i'm referring to those cores that available in the mask - I'm not suggesting using no mask. Perhaps that's the difficulty you are having?

 

...(still having issuers this end with internet sorry.)

 

What is a mask?

 

You put on a mask and I cannot see your face.

 

 

The Affinity Mask is used to Disable (or mask) cores!

 

The least significant bit on the right is representing core zero.

 

So with 8 LPs and an AM=64 we have a Mask of 01000000, core zero on the right shows it is masked with a zero, right up to core 6 which is UNMASKED with the One (1). I hope you got it now.

Share this post


Link to post
Share on other sites

 

 


...when I use an AM=64=01000000 there's only activity on core #6. The mask having only one one - the unmasked core.

 

Now I understand why we were talking past each other. You mask to zero, I mask to one. We're saying the same thing.

 

 

 

Luke admit it you didn't know the difference between FSX and P3D

 

I'm happy to admit I didn't know the difference between how FSX and P3D set their processor affinity. I still don't know for sure today, but it looks like FSX sets it per-thread, and P3D does it at the process level. That still doesn't say anything regarding FSX seeing logical cores differently than P3D. I really wish you'd explain why you said that rather than trying to attack me. My ignorance of a subject doesn't prove your claim.

Share this post


Link to post
Share on other sites

Well, to be honest I felt your posts were designed to shave credibility off of mine Luke. I'm stating the differences clearly but you'll have to study the thing yourself or work on a project with me to get more than that.

Share this post


Link to post
Share on other sites

Well, to be honest I felt your posts were designed to shave credibility off of mine Luke. I'm stating the differences clearly but you'll have to study the thing yourself or work on a project with me to get more than that.

 

Why are you being so cryptic?

 

You've stated that FSX and P3D handle their affinity via different API calls. I agree there. I don't see how handling it differently through API necessarily translates to a completely different scheduling mechanism.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this