I was doing some testing last night to try to improve performance while recording with FRAPS and noticed that the default Affinity being used for my system was 1364 (all good).  For the most part this works well, but when FRAPS is recording I can get some stutters here and there (you'll notice them in my videos every once in a while especially with TrackIR also running).

 

So I started looking at AffinityMask and did some testing.  What I discovered is that Core 10 (real CPU) is not always doing any work ... it's very inconsistent ... sometimes it'll be working sometimes not (does nothing, not even a blip).

 

So I messed around with AF values and found that 2388 will always work all the selected Cores all the time during a session -- (Core 2,4,6,8,11) - and FRAPS seems to like that setting also.

 

I'm not making any revelations here, but for those of you running 6/12 core setups with HT enabled, could I ask you test out AF=2388 and report back your results?  Even better if you can run FRAPS at 2560 x 1600 @ 30 fps.

 

Thanks, Rob.

 

 

 

Just a heads up: 2388 is 1001010100

Which if you count carefully, you will notice that CPU10 has a 0 (CPU11 has a one).  As for which is these bits is the 'real' cpu10 is 100% semantic.  From a core standpoint, considering each core has 2 execution threads (ie. virtual cpus), the 'real' core is core5 (counting from zero, as all programmers do).

 

 

Which if you count carefully, you will notice that CPU10 has a 0 (CPU11 has a one)

 

Yes, that's why I'm puzzled ... if I set the HT Core it will operate consistently, if I set the real core (10) it doesn't process consistently ... sometimes it'll task sometimes not.  But if I use Core 11 (HT core) it will process consistently.  By process, I mean I'll see threads executing on it.

 

Example: 1364

Core 0 (real CPU)

Core 1 (virtual)

Core 2 (real CPU)  - enabled, threads execute on it

Core 3 (virtual)

Core 4 (real CPU) - enabled, threads execute on it

Core 5 (virtual)

Core 6 (real CPU) - enabled, threads execute on it

Core 7 (virtual)

Core 8 (real CPU) - enabled, threads execute on it

Core 9 (virtual)

Core 10 (real CPU) - enabled, threads NOT executing on it sometimes

Core 11 (virtual)

 

Example: 2388

Core 0 (real CPU)

Core 1 (virtual)

Core 2 (real CPU)  - enabled, threads execute on it

Core 3 (virtual)

Core 4 (real CPU) - enabled, threads execute on it

Core 5 (virtual)

Core 6 (real CPU) - enabled, threads execute on it

Core 7 (virtual)

Core 8 (real CPU) - enabled, threads execute on it

Core 9 (virtual)

Core 10 (real CPU)

Core 11 (virtual) - enabled, threads execute on it

 

For whatever reason, the real core (10) doesn't always execute threads ... it's very inconsistent.  I don't know if this is an OS issue, hardware issue, or LM issue.

 

Cheers, Rob.

I have 12 physical cores and using 4095 (HT off) P3d 2.2 makes use of every core, almost evenly. It varies a bit from core to core, but not much.

 

As a test, I would try to turn HT off and then use an AM=63 as a check. Personally I'm very leery of how LM has implemented the AM, especially using every even core with HT on. If anything, I would either set the AM with Process Explorer or with the Win Start command line. I can't hurt to experiment.

4095=111111111111

  63=      111111

 

These masks would allow all logical processors, which is the same as not applying a mask.

 

So a mask of 1=111111111111

 

2388=100101010100

1364= 10101010100=110101010100

 

Which shows as your discrepancy around 10.

 

 

 

Which shows as your discrepancy around 10.

 

I think I'm not being clear I know 2388 is not using core 10, it's using HT core 11.

 

Going with Decimal since that's what Prepar3D.cfg uses:

 

All Cores Enabled 4095:

Core 0 = 1 (1)

Core 1 = 2 (1)

Core 2 = 4 (1)

Core 3 = 8 (1)

Core 4 = 16 (1)

Core 5 = 32 (1)

Core 6 = 64 (1)

Core 7 = 128 (1)

Core 8 = 256 (1)

Core 9 = 512 (1)

Core 10 = 1024 (1)

Core 11 = 2048 (1)

Bin=111111111111

 

2388

Core 0 = 0 (0)

Core 1 = 0 (0)

Core 2 = 4 (1)

Core 3 = 0 (0)

Core 4 = 16 (1)

Core 5 = 0 (0)

Core 6 = 64 (1)

Core 7 = 0 (0)

Core 8 = 256 (1)

Core 9 = 0 (0)

Core 10 = 0 (0)

Core 11 = 2048 (1)

Bin=100101010100

 

1364

Core 0 = 0 (0)

Core 1 = 0 (0)

Core 2 = 4 (1)

Core 3 = 0 (0)

Core 4 = 16 (1)

Core 5 = 0 (0)

Core 6 = 64 (1)

Core 7 = 0 (0)

Core 8 = 256 (1)

Core 9 = 0 (0)

Core 10 = 1024 (1)

Core 11 = 0 (0)

Bin=010101010100

 

Please re-read what I'm saying ... my point is that using 2388 I see activity on core 11 (as expected, fits the mask).  Using 1364 I'm NOT seeing consistent activity on core 10.

 

Cheers, Rob.

 

 

I would either set the AM with Process Explorer

 

I've been doing both ... and for some strange reason Core 10 (when enabled - 1364 - will not always show activity - sometimes it will sometimes it just stays idle and never shows activity for the entire P3D session).  However, in contrast, 2388 will always showing activity on the correct cores.

 

I'll try turning HT off and see what happens.

 

Cheers, Rob.

Was there activity on logical processor 11 when using mask=1364?

Was there activity on logical processor 11 when using mask=1364?

 

None.

 

EDIT: Just ran some quick tests with HT OFF ... was not good, stutters up, terrain loading slower.  2388 seems to be work very well -- more testing.

Heh, what I had in my minds eye and what you were describing were two different things. Yes I see your point, could be just Windows organising threads and things come out different, but there's another change elsewhere in the cores.

Why are you using Fraps? Since you have Titan you should be using shadow play. It works great with the new beta drivers and now you can record in window mode. I use it with p3d and fsx and it works great

 

 

Heh, what I had in my minds eye and what you were describing were two different things

 

Well to be fair, my thread title could have been worded better ... I didn't communicate well if two people missed the meat of my post.

 

Just ran some tests using 2388 and it's a dramatic improvement for my setup when recording with FRAPS (and even when not recording with FRAPS).  Hard to say if this is an LM issue or just some strange BIOS/Hardware/Win7 isssue?

 

 

 

Why are you using Fraps?

 

Not using the Beta drivers, will wait for certified release then try Shadow Play again.

 

Anyone else using a 6/12 core i7 39xx series willing to test out AffinityMask 2388 and let me know how it goes (or doesn't go, or no difference).

 

Thanks, Rob.

Here is a quick video I made from my AffinityMask setting of 2388 (also includes some AutoGen LOD testing I did for someone else):

 

 

If it's looking choppy on YouTube you can download the video file here: https://drive.google.com/file/d/0Bw0Q-fAfEZwybTBjU1RIM25aNWs/edit?usp=sharing

 

I'm going to be sticking with 2388 value, it seems to be working well for me.  Will not report to LM unless I see a lot of people confirming the issue.

 

Cheers, Rob.

Could this mean core 10 is actually your windows-core and windows has scheduled all services on the least primary core to give most benefit to programs, since old programs don`t always like running on triple/quad or more core systems.

 

So Rob could you also test. 2389

 

 

Could this mean core 10 is actually your windows-core

 

Doesn't look like it, core 10 flat lines ... core 0/1 shows minor activity (small blips here and there) which is consistent with OS doing it's thing.

 

Cheers, Rob.

I've been running a process spawns threads, they fill all the Logical Processors. Cut back on the threadcount and alternate LPs shut down. So I think what's happening is there's not such activity for Windows to utilise all the available LPs. When you alter the Mask, the order of use of the LPs changes and so you may find a different layout shows up an unused LP or not. I would leave HT on since threads with commonality can run on the same cores for increased efficiency through HT, many of the OS functions do this, for example the networking which P3D/FSX is network bound. AffinityMask can only mask LPs or cores from use. The reason for AM is to distribute high intensity threads to keep heat under control.