On 8/26/2018 at 6:31 PM, SteveW said:

An OK test Mike but not the way it should be done precisely.

Not taking note of single LP performance growth is a mistake.

Go first by increasing by '01's and not '11's.

When you have all '01's only NOW you can you start adding '11's but only those that can do it with proper performance AND in so doing looking to reduce some '01's on some cores to leave free.

Hi Steve,

Phew! Well, here are the next test batches which I have spread over 2 posts:

Same setup as before.

Affinity Mask (01's)

2 CORES
00,00,00,00,00,00,01,01
AM = 5
Loading Time: 92 secs

3 CORES
00,00,00,00,00,01,01,01
AM = 21
Loading Time: 78 secs

4 CORES
00,00,00,00,01,01,01,01
AM = 85
Loading Time: 73 secs

5 CORES
00,00,00,01,01,01,01,01
AM = 341
Loading Time: 71 secs

6 CORES
00,00,01,01,01,01,01,01
AM = 1365
Loading Time: 66 secs

7 CORES
00,01,01,01,01,01,01,01
AM = 5461
Loading Time: 63 secs

8 CORES
01,01,01,01,01,01,01,01
AM = 21845
Loading Time: 61 secs

Affinity Mask (11's)

On best performing cores from (01's)**

2 CORES
00,00,00,00,00,00,11,01
AM = 13
Loading Time: 93 secs

-----------------------------------------------------------------------

3 CORES**
00,00,00,00,00,11,11,01
AM = 61
Loading Time: 78 secs

4 CORES**
00,00,00,00,11,11,01,01
AM = 245
Loading Time: 74 secs

5 CORES**
00,00,00,11,11,11,01,01
AM = 1013
Loading Time: 67 secs

6 CORES**
00,00,11,11,11,11,01,01
AM = 4085
Loading Time: 63 secs

-----------------------------------------------------------------------

7 CORES
00,11,11,11,11,11,01,01
AM = 16373
Loading Time: 61 secs

8 CORES
11,11,11,11,11,11,01,01
AM = 65525
Loading Time: 60 secs

It's interesting to note that when 3 Cores are in play, LP2 is not being used for loading scenery. 4 Cores and upwards Core 2 (LP2 and LP3) is/are not being used. Would this allow suitable addons to be assigned to Core 2? The affinity mask for LP2 could be removed to free up the Core completely for this purpose:

(8a)

11,11,11,11,11,11,00,01
AM = 65521
Loading Time: 60 secs

(7a)
00,11,11,11,11,11,00,01
AM = 16369
Loading Time: 61 secs

 

Regards,

Mike

So when you get up around 5 cores gives you the big increases over less in loading speed but adding more only yields a second or two.

 

That's why the loading speed test is vital - it's the easiest metric to find first but as I said it's not the final outcome of best setup that requires some work but gives you an idea of spare cores..

 

We could run a video encoding process that alters frames of a movie. Looking at HT Off first, that program might use all the cores, each one processing a frame and moving to the next - if you will.

So an 8 core will get through the movie in half the time of a four core. That's easy to understand In testing, however it's not double maybe 15% - 30% less because the 8 core system becomes baulked with internal bandwidth since these are more or less the same hardware.

But then we turn on HT with the 4 core and the app will process 8 frames at a time but nowhere near double, perhaps 6-15% faster. So when I speculated 6% gains overall with HT enabled we are really talking about the possibility of more than that - plenty more in fact if we can get it or the app can use it. And that's all a very big point - can P3D use it like that? To some extent yes with the background tasks, and not with the special tasks these major tasks are individual concerns and require the maximum throughput of a single core - as we mention for one the rendering task on the first LP.

So the best system for P3D is a relaxed system, not a maximum overclock system, (well we can have that if we wish)  but generally hours upon hours of flight will require a more reliable system tuned for good life expectancy. And that system has set at least one LP off on the first core.

So there's no calculator required - anyone can do '01' or '10' on the end of an AM. With HT disabled we have no worries.

With four 11,11,11,01, six 11,11,11,11,11,01 and so on, that's the easy part. All those '11's start to build heat and use up all the shared CPU cache but no gain to performance worth having after a number.

We have started to see real 'many cored' systems that can't continue with best performance past a certain number of cores.

Allocating too many cores or LPs turns into several problems. This is a fact which I feel does not require a thorough knowledge of these systems. This was well predicted back in FSX days, as can be seen from dates on my site, but why it appears to be a new discovery today is because it was mocked then and it continues today.

 

 

 

12 hours ago, newtie said:

I have been flying for quite some time now with 213, unlimited w/vsync and a few other small adjustments. 

Which cores do you put your add-ons on then with P3D running on 213-AM?

Thanks.

I want to talk about fps because it's often not seen in the way it should be.

These simulators don't work like older games that rendered the view through software. Back when FSX came out we had started to introduce Shader techniques as seen in Doom 3 curved surfaces for example when Doom 2 before it was a software renderer with straight edges (actually a very clever technique for the hardware available at that time).

So FSX came out also with some very clever coding along with shaders; Tessellation of the Earth model sphere which as a software process was at the time pushing it a bit, but we simply must have a spherical Earth.

Actually those in the know realise the earth is slightly squashed and that too is taken into account in FSX. The simulator (and top planners) must be accurate and can get within a few inches of the real location with fairly problematic maths to run at high speed but they did that too.

Now we have P3D and that's using much more of the GPU side and that helps out a lot, even so there's plenty of code running there too.

In fact it pretty much defines your fps capability when hooking a particular GPU into a particular CPU.

So the way I look at fps is that it is only a result of the capacity of the hardware and "can't change". Unless we overclock the CPU and overclock the GPU.

So we are left with ensuring we have the best foundation for that because we can only reduce fps with poor set-up. That's the work I've done to produce real results in real systems and continue to get a lot of correspondence that supports it.

So when I say we can't gain fps that's really what I mean. Instead when problem solving poor fps I'm looking for why performance is not in that machine. Start with low settings and build up to a point whereby you have overhead on show in those graphs. It won't get so hot and you won't see such stutter or other artefacts.

This has done the rounds before - from my site:

 

[SCENERY]

..
..
SmallPartRejectRadius=3

This will reduce the glittering from small parts in the scenery without having to resort to Anti-Aliasing. Adding this line to a typical setup resulted in 4% more throughput capacity.

Remaining objects that persistently glitter as we approach an airport may in fact be the reflective quality of objects such as parked aircraft.

 

 

 

 

Edited August 28, 20187 yr by SteveW

7 hours ago, SteveW said:

So when you get up around 5 cores gives you the big increases over less in loading speed but adding more only yields a second or two.

 

That's why the loading speed test is vital - it's the easiest metric to find first but as I said it's not the final outcome of best setup that requires some work but gives you an idea of spare cores..

 

So... the idea of this loading speeds test is to find the least amount of cores that are needed to get the almost best (not THE best) loading time? As soon as the loading time only change a little bit, you should stick to the amount of cores that still made a noticable difference. Right? So that would be 5 or 6 cores in Mike's test. And in my case (looking at my tests from yesterday) that would be AM 85...?

AM 1 (00000001) = 68 seconds
AM 5 (00000101) = 58 seconds
AM 21 (00010101) = 50 seconds
AM 85 (01010101) = 41 seconds
AM 93 (01011101) = 40 seconds
AM 125 (01111101) = 40 seconds
AM 253 (11111101) = 37 seconds

Correct me if I am wrong. 😉 And then the next step would be... to assign various addons to various unused cores...? In my case that would be all logical cores. (I may not use the words 'core' and 'logical' correctly here.) Still correct? If so, how do I figure out which addon to put on which logical core? And how I assign cores automatically at startup?

Feel free to correct me if I am talking rubbish. 😉 

6 minutes ago, J van E said:

AM 1 (00000001) = 68 seconds
AM 5 (00000101) = 58 seconds
AM 21 (00010101) = 50 seconds
AM 85 (01010101) = 41 seconds
AM 93 (01011101) = 40 seconds
AM 125 (01111101) = 40 seconds
AM 253 (11111101) = 37 seconds

Is this a 4-core CPU with HT On, Jeroen?

AM 253 works best for me on i7-6700K HT ON @4.6GHz.

Thanks.

9 minutes ago, J van E said:

And then the next step would be... to assign various addons to various unused cores...? In my case that would be all logical cores. (I may not use the words 'core' and 'logical' correctly here.) 

No. A free Logical Processor (proper nomenclature LP - look in Task Manager) is not a free core.

The point is that again:

1. We have a process type that we can share a core with one on each LP 

2. We have a process type that we don't want to share and only want to occupy one LP of a core.

Say we have 11,11,11,01 the second character in from the right a zero - that's not a free core that is an unavailable LP1 of a core (LPs 1 and 0) that will have the main process on it followed by the next important process on core 1 (LP2) followed by the next process on LP3 sharing core 1 with LP2.

So don't put the addon exe on that spare LP on core zero. Use two LPs minimum not one for addon exe apps or that's a hit in performance too.

 

Look guys - It's all been discussed before in huge detail and there's tons on my site from FSX days still more or less the same thing. AND oh yes - I do get it that P3D is newer *don't panic*.

The thing I see way too much is those that are 'unsure' being so often put off by those that worry them over HT and AMs being some kind of a route to problems. These are due to poorly understood settings and incorrect use of good kit by those that should know better.

Thanks to all the advice in this thread I settled on AM=16212 (0011111101010100) 9 threads with SMT on.

Addons (REX Skyforce, Track IR & UTL client, on 1100000000000000. ASP4 and AH2 are on networked mode) This offers the best balance between loading time and actual smooth stutter free experience while flying. 

I found the with SMT on or off the fastest loading time was always with no AM. But as has been said, that does not necessarily translate into smooth stutter free performance. So you need to find the right compromise for your system. 

 

 

 

 

 

 

Edited August 28, 20187 yr by djbully

5 hours ago, djbully said:

the fastest loading time was always with no AM.

 

That could mean you have something that uses up more time with HT on - rather than saying the sim loads faster that way, which it cannot. It could simply be less obstructed by other processes less errant with HT off. Difficult to tell, but I would guess so.

There's no way loading time can improve with HT Off it's the same hardware. All that can happen is that there's more stuff taking advantage of the HT mode sapping time from the sim. That condition is going to be worse with more cores until software catches up. That's why it's best to start with HT Off make the comparison and if it's very slight then the HT mode will probably win over. Assuming the system is not excessively clocked then at some point the curve of rage of GHz will pass the curve of improvements with HT.

22 hours ago, Cruachan said:

It's interesting to note that when 3 Cores are in play, LP2 is not being used for loading scenery. 4 Cores and upwards Core 2 (LP2 and LP3) is/are not being used. Would this allow suitable addons to be assigned to Core 2? The affinity mask for LP2 could be removed to free up the Core completely for this purpose.

Hi Steve,

I’ve given this a bit more thought and am wondering whether the behaviour, as observed, is a reflection of Windows job scheduler activity thereby ensuring sufficient resources are allocated for the operating system. This being the case then I would suggest that attempting to assign addon exe’s to the LPs of the second Core (Core 1) would not be a good idea. Is this correct?

Regards,

Mike

Note: Apologies to anyone who may have been confused by my referral to Core 2 in the quotation of my text in the source post, whereas, in fact, I should have written ‘the second core’ which is usually specified as Core 1. The first Core is, of course, Core 0.

2 hours ago, Cruachan said:

Hi Steve,

I’ve given this a bit more thought and am wondering whether the behaviour, as observed, is a reflection of Windows job scheduler activity thereby ensuring sufficient resources are allocated for the operating system. This being the case then I would suggest that attempting to assign addon exe’s to the LPs of the second Core (Core 1) would not be a good idea. Is this correct?

Regards,

Mike

Note: Apologies to anyone who may have been confused by my referral to Core 2 in the quotation of my text in the source post, whereas, in fact, I should have written ‘the second core’ which is usually specified as Core 1. The first Core is, of course, Core 0.

The jobscheduler will look for spare % and go there in no specific order. You're right the second task is often slack and might attract the jobscheduler. The current o/s is pretty good at observing you  have a game running so will basically avoid the rendering core assuming it's active when other stuff happens. That's why we make sure all stuff happening is set up in the right order on the right cores and there's little to start up mid-flight. Problem is - with some apps or addons they simply start using resources without any kind of care about what the JS does so pop up anywhere rather than keep to a reserved LP. Mostly if we start those apps with the bat (or a decent app) they will keep to their specified cores. Generally the O/S isn't the killjoy, that's more likely some other thing running you installed didn't know came with some other thing or addon.

On 8/28/2018 at 10:48 AM, SteveW said:

When problem solving poor fps I'm looking for why performance is not in that machine. Start with low settings and build up to a point whereby you have overhead on show in those graphs. It won't get so hot and you won't see such stutter or other artefacts.

 

That has to be the single, most important paragraph in this thread! We should all take note, use it as our guiding mantra, and act accordingly. Suppress those understandable, but irrational desires to max everything out, adopt a far more prudent approach and success is virtually guaranteed.

Thanks Steve.

Regards,

Mike