Hi Mitch,

if it works for you, well fine but please don't convince people to use definitely wrong or useless settings. I prefer the more serious approach to customize P3D v2.

Spirit

Hi Mitch,

if it works for you, well fine but please don't convince people to use definitely wrong or useless settings. I prefer the more serious approach to customize P3D v2.

Spirit

Your personal opinion in play, as everybody else...   No problem.

 

Oh..."definitely wrong or useless settings"..... by whose authority?   Yours?

 

Cheers!

If P3D is like FSX in it's CPU loading,  it stands to reason that distributing the load over the last three (real) cores and leaving the first core free for Windows stuff, has some merit.

 

That is why some of us use AM=14 for a non-hyperthreaded quad, and AM=84 for a hyperthreaded quad.

AM=84  equals clear and strong graphics on a four core in HT.  The others...straws...

Your personal opinion in play, as everybody else...   No problem.

 

Oh..."definitely wrong or useless settings"..... by whose authority?   Yours?

 

......

Common knowledge but you can also check the P3D v2 manual.

Spirit

If P3D is like FSX in it's CPU loading,  it stands to reason that distributing the load over the last three (real) cores and leaving the first core free for Windows stuff, has some merit.

 

That is why some of us use AM=14 for a non-hyperthreaded quad, and AM=84 for a hyperthreaded quad.

In order for these to be equivalent performance-wise in a quad core w/ and w/o HT would have to be an assumption that P3D/FSX is unable to do more work with two 'virtual' cores than one 'real' core.    About the only way we can measure CPU work in these sims other than subjectively is thru sensors like ASUS Suite that display CPU utilization AND temperature change (Core temp for this actually).   I can say w/o equivocation HT on w/ 10 cores available for texture loading (hexacore w/ HT on), definitely implies more work is being done as evidenced by higher total CPU utilization, and perhaps as or more importantly, higher temps.  This is also corroborated in my experienced w/ consistently best texture update rates, w/o a doubt.  Hexacore HT on AF of 4094 leaves one virtual core for non-P3D processes, and one virtual core for the main thread, and 10 as texture loaders.   In the highest demand scenarios it is common for me to see all 10 of these pegged near 100% use.   As we all observe the OS rarely uses more than a few % utilization while P3D runs, so to turn over what amount to two virtual cores really doesn't add anything, and loses one core theoretically.   One other fascinating discovery I made recently that is completely compatible w/ other assumptions above:  prior to this test I had REX4 assigned to 'all cores', all 12 virtual cores, on the basis that the OS would allocate processes where it needed to best of these 12 cores.  I noticed during weather loads the usual slight flickering was occurring, but importantly, P3D video quality began to stutter along w/ the pulsing flickering behavior during weather loading.  So in Task Manager I then deselected Core1, P3D main thread virtual core, from REX4, leaving the other 11 virtual cores for REX4 to be able to use.  As predicted, the stutter stopped w/ weather loading, implying to me REX4 when left to be able to work on Core1 was enough to interfere w/ P3D in flight.

 

The quad core equivalent of 4094 is 254, and I would argue *should* behave best over 84 when HT is on.  I can say w/ certainty which doesn't happen often in these sims that this theory completely fits w/ what's happening empirically:  best texture update rates, corroborated by higher reported CPU utilization, corroborated by higher temperature.

There is a saying: "Too many cooks in the kitchen"..

 

It is not at all clear to me if FSX/P3D is able to use more than 3 cores effectively.

 

Sure it will generate heat, but that is not necessarily equivalent to a smooth, stutter-free

flight.

 

Project management basics say that adding more people to a project does not always

result in a better or earlier finished product...  something to ponder.

 

Separating other applications from the main flightsim core, however, always has a positive effect.

It is not at all clear to me if FSX/P3D is able to use more than 3 cores effectively.

 

Sure it will generate heat, but that is not necessarily equivalent to a smooth, stutter-free

flight.

 

Bert--I have it:  smooth, stutter-free, best possible texture update rate--and bonus, the heat is a reasonable surrogate marker for more work being done I'm convinced.   It's also certainly possible best texture update rate somehow obviates smoothness, but here it's the opposite.  I've done the comparisons of the exact same areas and witnessed the outcome.  It is rare and usually foolish to make these sorts of claims I know, but as I say I've done the comparisons and it all lines up-emperically & theoretical, every time up.   How many times have we thought we were on to something durable only to discover it really wasn't what we thought it was.  This one has been 100% consistent though, which makes it essentially situation-independent.  This being said, it's only good for what it claims to be--superior texture update rate w/ resultant best image quality out to the full LOD assigned.  This does not eliminate situations when the GPU or CPU are against hardware limits, which should go w/o saying.  So when I fly under/in dense cloud shadows at dawn/dusk, performance suffers in a way I hope LM can find the solution for--I think its a faulty (i.e., suboptimal in a big way) way of coding the process.   Or the CPU limited issue in dense metro areas is not affected by using AM=62 for HT off hexacore versus AM=4094 w/ HT on--it's the same here.

 

Flying into FTX PWN last evening into KPDX in the CS MD80 I had fabulous image quality all the way out, very dense autogen & veg.  I decided to take a peak at CPU utilization in realtime:  all 11 (1 main, 10 texture loaders) were practically pegged at 100%.  That's very uncommon in lesser areas.  So even this hit a bit of a wall, but performance didn't get visually impacted.  I think frames were around 24 or so at touchdown.   Road traffic very smooth, flight very smooth.   Not the same as being locked at 60fps using v-sync, but very smooth and freedom from un-updated, blurry textures.  It all fits quite well--theory and experience. 

So folks, is it 254 or 255? I'm getting dizzy...

 

Me too.  I ran belarc advisor and it says this is what is aboard my fairly new Lenovo X510 Erazer PC. Runs win8.1 with 3 terabytes of HD and 32 GB of SDRAM.

 

3.50 gigahertz Intel Core i7-4770K

256 kilobyte primary memory cache

1024 kilobyte secondary memory cache

8192 kilobyte tertiary memory cache

64-bit ready

Hyper-threaded (2 total)

 

 

What AM setting should I use?

 

Eric

Me too.  I ran belarc advisor and it says this is what is aboard my fairly new Lenovo X510 Erazer PC. Runs win8.1 with 3 terabytes of HD and 32 GB of SDRAM.

 

3.50 gigahertz Intel Core i7-4770K

256 kilobyte primary memory cache

1024 kilobyte secondary memory cache

8192 kilobyte tertiary memory cache

64-bit ready

Hyper-threaded (2 total)

 

 

What AM setting should I use?

 

Eric

Eric...I'd say, try them all that you have seen that is relevant to your particular CPU.  I found personally, that with my 4 core i7-975 Extreme series CPU, that 242,254,255, all will 80 percent of the time, cause a CTD at the last second of the default load up of P3D.  Also, over time, with usage, weather, different demands, altitudes, KPH, etc...there will be a texture corruption at some point.  I have AM=84 in HT mode, and have 30-40 FPS, NO defocus or deterioration of ORBX Global, and have never had a 98 percent load in and then, CTD using this AM figure. So...I have top notch FPS, fabulous video performance, and can run a flight trans-continental at any altitude, at any KPH...until  I  land, or have to end the flight due to other time-requests.  So...have at it...try them all, and take notes...see what works...and then when you find one....set and forget! 

 

Mitch

OK - here are the theories:

 

1.  FS cannot effectively use more than 3 cores

 

2.  FS can effectively use as many cores as you can make available

 

If you believe in 1. you would have HT disabled and have a pattern like:  1110 (14) or HT enabled and: 01010100 (84)

 

If you believe in 2. you would have HT enabled (on a quad) and have a pattern like:   11111110 (254) or 11111100 (252)

 

or, you would spend the money and get a hexacore CPU..

 

So, it all depends on whether you believe in 1. or 2.

 

Based on these forums, it would appear that users get smooth flight, regardless of which camp they are in. 

 

Where things go off the rails, is where an i5 user reads a recommendation and sets AM=84

 

^_^

.....

Where things go off the rails, is where an i5 user reads a recommendation and sets AM=84

 

^_^

I think that some guys are doing AM setting with a kind of Vodoo believe.

Spirit

After toying with a variety of these values AM=14 seems to work best for me.  

I'm using a quad core with HT on. I tried no AffinityMask setting as well as AffinityMask = 84, 252, and 254 and it made no measurable difference in frame rates which setting I used. So I removed the AM line from my P3Dv2 .cfg file. All of these "magic bullets", IMHO, are a big load of snake oil.

 

Scott

It is not frame rates we are trying to optimize here.. so no surprise

 

^_^

Hi Mitch,

 

Been reading this thread with great interest. Glad you have reached your flight simming nirvana. However, I'm afraid the others are correct when they state that the Bufferpools entry has no effect in Prepar3D v2..2. It did have a positive effect in Prepar3D v1.4 which closely matched the results observed in FSX. I ran my Prepar3D.CFG file through Boojote's helpful optimising and configuration tool and all the added entries are still in place. I still have v1.4 installed as it runs very well displaying Photoscenery/Treescapes covering the whole of Scotland.

 

As for the Affinity Mask tweak in P3D v2 I have never achieved better performance with any of the suggested 'appropriate' settings for my 4 core i7 2969XM. In fact the best performance is achieved without the addition of the Jobsheduler / AM lines. This implies the use of The Developer's default setting which, in the case of my CPU, turns out to be 84 (01010100), using physical cores 2,3 and 4. You can verify this in Task Manager. I am assuming the software auto detects the local CPU and sets the AM value accordingly.

 

Currently the only tweak I am using, and has proved to be of any value on my rig, is the Adaptive VSync switch in NVIDIA Control Panel set under Global Settings.

 

Anyway, just my tuppence worth (UK speak). As with everything to do with the complexity of customised flight simulators, it is likely your mileage will vary just as others are finding it necessary to hold onto various proven settings in Nvidia Inspector. In the end, does it really matter? What appears to work for you is what's important. Any changes or experimentation tend to be non-destructive in any case providing you have first recorded the settings that ensure best performance for you in the event you need to restore them.

 

It's a shame LM don't step in when such recommendations are made to the community to help separate the genuine proven findings from that which is likely to be no more than based on fanciful delusions.

 

Cheers! Always a joy to read your posts which are invariably uplifting and optimistic. More power to you, my friend!

 

Best regards,

Mike

 

Edit: Found this interesting thread:

 

http://www.flightsimworld.com/forums/topic/202278-my-affinity-mask-testing-for-best-usage-of-cpu-cores-hyperthreading/

 

I should emphasise that the testing was carried out with FSX in mind. Doubtless it will also apply to Prepar3D v1.4. Prepar3D v2 is a very different animal. However, my experience confirms that the enabling of hyperthreading is at the expense of performance.

It is not frame rates we are trying to optimize here.. so no surprise

 

^_^

 

Bert -

 

Ummmmm.... this is what happens when I read threads after a very long day at work.  You're right and I apologize for the misunderstanding.  Now that I understand what we're fixing, I'll test again  ....

 

Scott