Rob A, as I remember it, you used different AM settings when running other Fs programs.

Is this still the case ?

 

 

Rob A, as I remember it, you used different AM settings when running other Fs programs.
Is this still the case ?

 

There is no simple answer to this ... it'll depend on the other process running and what it needs on the performance front.  Have to balance whether reducing CPU count for P3D and dedicating to the other process to the now free CPUs produces the best results.

 

For example, when I used to use Fraps for recording video it preferred a dedicated CPU so I free'd on up for it as the over drop in performance was less in P3D.  But not the case for ShadowPlay since it's mostly done in the GPU with minimal I/O processing to SSD/HD.

 

Cheers, Rob.

Hi Rob,

 

My server displays the 2d cockpit without instruments.

 

Beside P3D I have running :

 

- Opus for the driving the Buttkicker ( no weather )

- IflyToFsuipc

- SIOC for driving the Overhead, flaps gauge and CDU

- Ifly Server ( for displaying the flight displays on the client pc )

- Fiber Accelerator

 

None of them will taxe the GPU.

 

So I will try with core 3 for the processes mentioned above.

If needed I can add core 4 too.

 

What do you think ?

Without a VC you'll have less demands ... as  you can see from my video the VC does "seem" to work on a single separate core than the main core and terrain/autogen cores.

 

Fiber accelerator will skew any testing you do, so best to turn that off temporarily as you test your setup.  Does Fiber accelerator adjust affinity on the fly?  But either way, you'll want to disable Fiber Accelerator while testing.

 

Cheers, Rob.

Heya Rob, 

 

Well, I am truly amazed by your flightsim, because it looks nothing like mine!   :(

 

You have no saturated cores/threads, and all of them are working towards a common goal - creating the flight environment. The more load you put on it, the more it responds.

 

My system, on the other hand, apparently has some issues. Clean install of P3D v2.4, and here is what I have (I am not even going to try to replicate your video environment!). All screen snaps taken with CPU affinity set to 2-7, so six threads total.

 

This is my CPU load, sitting on the tarmac at KTTD, parking 6, non-started, default weather. As you can see, virtual core 0 is hammered and nobody is doing anything else. The big spike is from starting P3D, after which CPU "0" is hammered while the other CPU/threads are doing nothing.

 

https://www.dropbox.com/s/feljttp8u8kc53r/Sitting%20on%20Tarmac%20-%20no%20affinity.JPG?dl=0

 

This is the same scenario, but with the "fix" that messes up the normal CPU affinity. Note that no CPU is hammered, but CPU 3 is too close for comfort.

 

https://www.dropbox.com/s/kwdkndre17z62xy/Sitting%20on%20Tarmac%20-%20affinity.JPG?dl=0

 

Here we have flying. This is the RealAir Legacy departing out of KTTD east and turning back to Vancouver, WA. This is with no affinity, i.e., normal operation for threads 2-7. As you can see, there is a bit of imbalance, and virtual core 0 remains hammered. Contrast this to your video in which your "core 0" never becomes saturated.

 

https://www.dropbox.com/s/6xqby36mvdexnu8/Flying%20-%20no%20affinity.JPG?dl=0

 

And here we have the exact same flying scenario, but with the "fix". All I can tell you is that taxiing is much more pleasant (minimal judders on turns), and flying is much MUCH smoother. You can see that no CPU/thread is hammered, which shows in the flight. 

 

https://www.dropbox.com/s/cs6i5o8if2h94bb/Flying%20-%20affinity.JPG?dl=0

 

I know you have twice the cores that I do, but the fact remains, in the scenarios that do not have the "affinity fix", virtual core 0 remains a HUGE bottleneck and there are monstrous spikes in the other. Contrast that with the affinity "fix" (which again, is just confusing the OS/P3D into what affinity really is), where CPU loads are much more benign and in-flight performance is much better.

 

All things said and done, I would trade your CPU profile for mine in a heartbeat, but apparently my P3D sim is in cardiac defrib in normal operation!!!

If I'm not mistaken, Rob also has one CPU pinned at 100%. It's fairly easy to do this if one has a high end GPU and maxes out the IQ settings in P3d. It's just the nature of the way P3d is coded. One CPU core runs the main thread and there are just too many things that this thread is responsible for doing. But preventing P3d3 from using core 0, all one does is hammer another core. Now, if you are seeing improved performance by fiddling with the AM, you might want to see what else is running other than P3d. Prior to running P3d, Windows is showing 99% idle processes. Even if I mask ASN, the GTN Lite app, the Traffic Optimizer and any other add-ons to their own core, it makes very little difference on my setup. Preventing P3d from using core 0 does nothing for me either as the OS process scheduler in Windows just moves the P3d main thread to another core.

 

The only ways to prevent one CPU core from maxing out are to either turn up settings that are GPU-intensive or turn down settings that are CPU-intensive. Unfortunately other than that, we will either have to wait until P3d is optimized better or buy new hardware.

 

 

If I'm not mistaken, Rob also has one CPU pinned at 100%.

 

Under load, I'm usually around 80% per my video with a few short spikes to 100% on the main thread, the other cores fluctuate with load as expected.

 

 

 

All things said and done, I would trade your CPU profile for mine in a heartbeat, but apparently my P3D sim is in cardiac defrib in normal operation!!!

 

I don't know John, seems like you got your system working much better with P3D.

 

Like I said, I think the only thing people can come away with for this thread is that there is no golden rule for Affinity settings.  The only way to discover what works best for any given system is to experiment ... just too many variables to be able to define a "rule".  But sharing one's discovery can help others move in a direction if they are having performance issues/blurries/etc.  So it's all good.

 

Cheers, Rob.

 

 

Under load, I'm usually around 80% per my video with a few short spikes to 100% on the main thread, the other cores fluctuate with load as expected.

 

True, but since you made that original post, you've turned down a few settings, like having cloud coverage at medium. BTW, I've done the same and I get about the same result that you do. But it is easy to pin core 0 at 100% if you want to do so.

 

 

But it is easy to pin core 0 at 100% if you want to do so.

 

Absolutely ... but usually only if I'm using 3rd party products ... on a clean install I wasn't able to do it.  Not that it's relevant as very few run without any 3rd party products.  But agree, I can pin primary thread core with higher settings and 3rd party.

 

Cheers, Rob.

What's interesting is that pinning core 0 doesn't seem to be a frame rate bottleneck. Try running an aircraft that is a resource hog, for example the Milviz Baron B55 with dual VC GTNs. Then do nothing different but change to aircraft to the twotter (I have the GTN 750 installed in the VC for comparison) .

 

Both will pin core 0 at high IQ settings but the twotter will have more than double the frame rate. Rather odd.

 

 

Try running an aircraft that is a resource hog, for example the Milviz Baron B55 with dual VC GTNs. Then do nothing different but change to aircraft to the twotter

 

I'll test that out, but your version of P3D has the Select Vehicle bug so my version may not exhibit the same behavior.

 

ON a side note: I need to test out the my GTN 750 ... with the global terrain database I getting OOMs which so far seems to be specific to me as others report no VAS issues with the GTN 750.  So need to figure out what I'm doing different.

 

Cheers, Rob.

I have the global terrain database and I haven't seen any impact on VAS. I'm not sure how much additional VAS P3d would even use with the GTNs since they are powered by their own app, the GTN Lite Simulator, which runs in it's own 4GB address space.

 

What exactly is the "Select Vehicle bug"? Do you mean the amount of time it takes to parse all the AI and non AI aircraft when you select a new vehicle? How does that impact performance of user aircraft? Are some aircraft loaded differently?

 

In any case, I'm surprised that an aircraft like the Twotter is so efficient under P3d, when compared to even the more recent A2A offerings. The Twotter has a lot of bells and whistles and it certainly isn't a new product. It doesn't surprise me that most of the default P3d aircraft produce acceptable frame rates, but most 3rd party aircraft don't. Maybe someone should track down why this is so. Do certain aircraft run on a single CPU thread? Or are some just tough on the CPU altogether? Or maybe it's just the bitmap resolutions being so different.

 

 

What exactly is the "Select Vehicle bug"?

 

It's now fixed in v2.5 ... the bug was that you will eventually run out of VAS by just selecting different aircraft in the Vehicle Select screen (don't need to load the aircraft, just select different aircraft).

 

A2A aircraft have been good to me on frame rates as has the TwinOtter.  There was an issue with A2A cherokee smoke effects (when mixture was incorrect) which would cause drops in fps ... think I ended up just renaming A2A engine smoke effect so it wasn't used.

 

Cheers, Rob.

Rob, do you still use AM and if so what value ?

I have read some threads about AM icw with a 6 core processor.

 

HT is an option for CPU cores to let threads pass in a way it makes better use of a physical core. That is not being arranged by FS or any other program but the Intel chipset, CPU and drivers.

 

 

Summary :

 

4085 --> 1111 1111 0101 --> first 2 HT cores are turned off

by turning the first two HT cores off one might avoid a reoccurring "collision" between threads.

 

1364 --> 0101 0101 0100 --> no HT cores used and first core for Windows

advised by Saul from LM

 

1020--> 0011 1111 0101 --> first HT core turned of and last core for other Fs programs

used by Rob in april 2014 when recording with Fraps and using Track IR

 

4081 --> 1111 1111 0001 --> ?

used by Rob when flying with Track IR and using Fraps

 

4092 --> 1111 1111 1100 --> first core is left for Windows

Used by Rob when using Fraps

 

4094 --> 1111 1111 1110 --> core 0 for Windows

Used by Rob when flying with Track IR

 

4093 --> 1111 1111 1101 --> ?

Used by Rob when betatesting v2.3 on advice by LM

 

4095 --> 1111 1111 1111 --> everything turned on

Used by Rob when flying without additional programs

 

 

And more info from the LM team:

 

V2 is smarter about generating its default affinity mask, but if you want to tinker with it yourself you still have to add the entry to the config file. P3D is still better off with one thread per physical core, so it generates an affinity mask that puts one thread on each physical core of a processor. If you have 4+ physical cores, the application will bump itself off of the first core to free up the processor for the OS and other applications. Thanks,

 

Zach Heylmun

Software Engineer - Prepar3D® Team

Finally, just to show you how weird things can get, I had micro-stutters after my "fix" that were just distracting. Turns out the combination of my GTX 780 and 2560 x 1440 ASUS monitor is incapable of holding down 60 hertz, but was only producing 59. Using NI I changed to match and viola, no more micro stutters.

Hi John,

 

Thanks for this thread, always interesting to see how others are getting on.

 

I've reached the point where I'm getting micro stutters and thought your above quoted paragraph quite useful.

 

Firstly, how did you find out you were only outputting 59Hz?

Secondly, what did you 'change to match' in NI (Nvidia Inspector I assume)?

 

Many thanks,

 

Ian