LOD_RADIUS=15 but it's NOT about distance

[Bert Pieke 7,591]

Just to toss in some more testing I did on my system. I'm running with HT ON and CPU is 6 real cores (so 12 Logical cores).

 

Affinity = 14 (which according to the other's is not correct for a 6 core HT setup)

I get consistently better FPS but at the cost of delayed photo scenery loading, changes to Fiber_Frame_Time_Fraction make no difference (from 0.1 to 0.99)

 

Affinity = 62

I get lower FPS but photo scenery loading is much faster and it will respond to changes in Fiber_Frame_Time_Fraction, using a value of 0.99 will decrease FPS but ensures the photo scenery tiles get loaded (using a high LOD like 9.5).

 

I'm keeping an excel spreadsheet of all this testing, BUT I think it will be difficult to determine what exactly happens with the Affinity settings across all variants of hardware and OS. Win8.1 does a better job scheduling than Win7 which does a better job of scheduling than WinXP ... I'm using Win7 currently.

 

So I guess I have no conclusions, I don't really know or understand what is really going on with the Affinity settings in FSX and given that HT design across different Intel CPUs is NOT the same it further adds more variables to the FSX equation. Sometimes I think it would be easier to solve the grand unification theory than to figure out how FSX Affinity will work across all the variances in OS and hardware. It's once again is "try it and see" how it works on my specific setup.

 

AF=14 gives you a total of 3 active cores for FSX, which is good on a quad core processor (leaving Core0 idle and available for OS related tasks)

 

AF=62 gives you a boatload additional active cores, which can used for texture loading, and seem to indeed improve scenery loading on your system.

[Guest]

I think I've finally found FSX.CFG nirvana (the perfect balance for my system) ... using AffinityMask = 680 now.  All I have to do now is adjust LOD_RADIUS pending aircraft type to make sure I don't OOM ... these settings are working great for me for AutoGen, Photo, and extreme weather even at FSDT airports.  Finally I've got one FSX.CFG for all situations and keeps me at a consistent 30 fps.

 

[GRAPHICS]

MultiSampleQuality=4

MultiSamplesPerPixel=16

NIGHT_THRESHOLD=4096

DAY_THRESHOLD=32768

SHADER_CACHE_PRIMED_10=1693500672

STALE_BUFFER_THRESHOLD=2147483647

HIGHMEMFIX=1

ForceWindowedVSync=1

TEXTURE_MAX_LOAD=2048

NUM_LIGHTS=8

AIRCRAFT_SHADOWS=1

AIRCRAFT_REFLECTIONS=1

COCKPIT_HIGH_LOD=1

LANDING_LIGHTS=1

AC_SELF_SHADOW=1

EFFECTS_QUALITY=2

GROUND_SHADOWS=0

TEXTURE_QUALITY=3

IMAGE_QUALITY=0

See_Self=1

Text_Scroll=1

D3D10=1

ForceFullScreenVSync=1

 

[JOBSCHEDULER]

AffinityMask=680

 

[bufferPools]

UsePools=0

Poolsize=0

 

[FSDREAMTEAM]

AntiPopUp=1

AltitudeCull=1

ViewOptimization=0

GroundTraffic=1

 

[sCENERY]

ObjectsToBatchPerFrame=50

MAX_ASYNC_BATCHING_JOBS=4

SmallPartRejectRadius=1

LENSFLARE=1

DAWN_DUSK_SMOOTHING=1

IMAGE_COMPLEXITY=5

 

[TrafficManager]

AirlineDensity=10

GADensity=10

FreewayDensity=10

ShipsAndFerriesDensity=10

LeisureBoatsDensity=5

IFROnly=0

AIRPORT_SCENERY_DENSITY=3

 

[TERRAIN]

SWAP_WAIT_TIMEOUT=2

IMAGE_PIXELS_FOR_AUTOGEN_POLYGONS=2048

BATCH_AUTOGEN2=1

LOD_RADIUS=9.500000

MESH_COMPLEXITY=100

MESH_RESOLUTION=25

TEXTURE_RESOLUTION=29

AUTOGEN_DENSITY=5

DETAIL_TEXTURE=1

WATER_EFFECTS=4

TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=4500

TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=3000

 

[DISPLAY.Device.NVIDIA GeForce GTX Titan.0]

Mode=2560x1600x32

Anisotropic=1

AntiAlias=1

 

[Weather]

WindshieldPrecipitationEffects=1

DisableTurbulence=1

CLOUD_DRAW_DISTANCE=12

DETAILED_CLOUDS=1

CLOUD_COVERAGE_DENSITY=8

THERMAL_VISUALS=0

 

[Display]

TextureMaxLoad=27

InfoBrakesEnable=False

InfoParkingBrakesEnable=False

InfoPauseEnable=False

InfoSlewEnable=False

InfoStallEnable=False

InfoOverspeedEnable=False

BLOOM_EFFECTS=1

SKINNED_ANIMATIONS=1

TEXTURE_BANDWIDTH_MULT=80

UPPER_FRAMERATE_LIMIT=30

WideViewAspect=False

 

[Main]

FIBER_FRAME_TIME_FRACTION=0.66

DisablePreload=1

HideInfoText=0

Maximized=1

 

[PANELS]

VIRTUAL_COCKPIT_TEXTURES_SCALE=2.0

IMAGE_QUALITY=1

DEFAULT_VIEW=0

QUICKTIPS=1

 

[Noel 4,563]

 

 

[JOBSCHEDULER]
AffinityMask=680

 

Have you tried 4089 when HT is enabled on hexacore?

[padolamap 7]

Have you tried 4089 when HT is enabled on hexacore?

AffinityMask, only improves load simulator, once you started the simulator does not divide the load on each core but performs work in parallel without having a higher performance, higher temperature will only have. I use 1364 as a value and I have I7 3930K processor

[DAL1850 51]

I think I've finally found FSX.CFG nirvana (the perfect balance for my system) ... using AffinityMask = 680 now. All I have to do now is adjust LOD_RADIUS pending aircraft type to make sure I don't OOM ... these settings are working great for me for AutoGen, Photo, and extreme weather even at FSDT airports. Finally I've got one FSX.CFG for all situations and keeps me at a consistent 30 fps.

 

Very very similar to mine ('cept I don't have the hex core). 680 is what I would go with though (it's the analog of 84 which is what yields the best result on a quad). Do you find that FSX capitalizes by using all of those cores (on my system, cores 1, 2, and 3 are pegged at 90-100%...core 0 bobbles around as expected). Your FFTF is also a lot higher than mine, but maybe you can capitalize on that with more cores shovelin' coal into the furnace. I had to pull mine back to 0.20 to get any kind of joy from the T7 w/ complex scenery.

 

I thought this was an interesting comment from Phil Taylor:

 

 

On multi-core machines in SP1, we moved many fiber jobs off of the primary thread and onto secondary threads. Since FIBER_FRAME_TIME_FRACTION only affects scheduling of jobs on the primary thread, it will have less of an impact on the performance of Flight Sim on multi-core machines. In fact, we moved so many jobs off of the primary thread that there probably isn’t enough fiber work left to soak up the full time allowed by the default value of 0.33.

 

Therefore, on multi-core machines, there’s very little reason to tweak the fraction because it really only impacts performance of single core machines.

 

Doesn't seem to be the case in practice though from my experience.

 

BTW, what is the effect of this tweak in Panels?

 

VIRTUAL_COCKPIT_TEXTURES_SCALE=2.0

[Noel 4,563]

padolamap, on 26 Oct 2013 - 8:26 PM, said:

load on each core but performs work in parallel without having a higher performance, higher temperature will only have.

What is the theoretical basis of higher temperature? People here say higher temps, but I don't see it when I run HT enabled and 4089 which distributes work in all 12 threads. The only way I could see higher temps happening is if:

 

1. More work being done or

2. The work being done is done less efficiently, hence more watts are required to do the same tasks.

 

Also if you will, what are you trying to accomplish w/ AM of 1364?

[Pete Dowson 558]

Also if you will, what are you trying to accomplish w/ AM of 1364?

 

1364 is 0x554, or binary 010101010100, which appears to enable "real" cores 1,2,3,4,5, leaving core0 free and avoiding the hyper-threaded cores. At least that is so if each alternate core bit is an HT-enabled one, as has been stated.

 

It's the eqivalent of using 84 (01010100) on a 4-core HT-enabled processor.

 

Pete

[Noel 4,563]

1364 is 0x554, or binary 010101010100, which appears to enable "real" cores 1,2,3,4,5, leaving core0 free and avoiding the hyper-threaded cores. At least that is so if each alternate core bit is an HT-enabled one, as has been stated.

 

It's the eqivalent of using 84 (01010100) on a 4-core HT-enabled processor.

 

Pete

Can you speak to why, if so, 1364 would be theoretically superior to 62 w/o HT enabled on a hexacore?

[Dougal 165]

Ahhhhhhhgggg...........  My head hurts;-)

 

Thanks for the great insight though fella's.  Its just for numpies like me, it all gets a bit heavy;-)

[DAL1850 51]

Can you speak to why, if so, 1364 would be theoretically superior to 62 w/o HT enabled on a hexacore?

 

It's not. If HT is disabled, 62 is your friend (on a hexacore).

[Pete Dowson 558]

Can you speak to why, if so, 1364 would be theoretically superior to 62 w/o HT enabled on a hexacore?

 

As DAL 1850 said, it isn't. 1364 is only relevant to a hexacore with HT enabled.

 

62 is binary 111110 which gives you the identical 1-5 cores allocated, core0 reserved. So 1364 HT == 62 non HT.

 

Pete

[Guest]

 

 

Have you tried 4089 when HT is enabled on hexacore?

 

Yes, seemed to increase frequency of black squares (textures not loading).

 

 

1364 is 0x554,

 

Yes, also tried this setting, it's a little better (a few less black squares).

 

Have also tried 4095, 30, 60, 1365, 682, 126, 4080, 4092, 4102, 1020  with and without HT enabled in BIOS.  For whatever reason, 680 seems to work the best with minimal black squares (text load failures).  I did all testing at LOD 9.5 to make sure I was applying some stress.

 

Also keep in mind that I use FRAPS for video recording (real time) so I always factor that into CPU equation ... recording at 2560 x 1600 does take 2-3 fps away and has a tendency to saturate the bus.

 

 

VIRTUAL_COCKPIT_TEXTURES_SCALE=2.0

 

I believe this is supposed to improve clarity of cockpit textures ... I think the default value = 1.0

[Noel 4,563]

So 1364 HT == 62 non HT.

 

Yes, this was my question.  So, why do some people choose to use 1364 HT?  Not even a theoretical rationale?

[Pete Dowson 558]

Yes, this was my question.  So, why do some people choose to use 1364 HT?  Not even a theoretical rationale?

 

Because they have HT enabled. Otherwise they'd use 62 as I said.

 

Pete

[Noel 4,563]

 

 

Otherwise they'd use 62 as I said.

 

Let's try again...why do people choose to use HT as it relates to FSX?