For those that have a blurry ground texture problem...are you running a custom LOD?

[TheBoom 31]

When high LOD is used, or intense scenery, there's a case for increasing FFTF, maybe try 0.4. Use of FFTF below 0.3 reduces the usefulness of a fourth sim job. The AMs 116 (three cores) and 85 (four cores), and their equivalents (like 170 and 184), can't be beat on the four core +HT. But performance can be scuppered by allowing addon exe activity onto the core with the first unmasked bit, core zero in the case of AM-85, and core 1 in the case of AM=116. In the case of AM=116, also avoid addon exe activity on core 2 with LPs 4 and 5. Unmasking five LPs (as in AM=248) should be avoided, these always reduce performance.

Using 116 and unlimited frames yields blurries for me. FFTF only works in locked fps yes?

 

Not sure if it's just a coincidence but I notice maxed out activity in both the scenery rendering cores in line with when the blurries happen.

[SteveW 1,792]

Using 116 and unlimited frames yields blurries for me. FFTF only works in locked fps yes?

 

Not sure if it's just a coincidence but I notice maxed out activity in both the scenery rendering cores in line with when the blurries happen.

 

FFTF works all the time, it is a ratio of background to foreground processing.

 

There's very little difference going from four cores AM=85 to three cores AM=116. If you have a maxed core it cannot do any more processing. AM=116 puts job 2 and job 3 onto a core and when your scenery rendering is maxing the job 2 is idle anyway so in that way it affects the total sim performance by only a few percent to place 2 and 3 on a core together. Your problem is most likely with other processes and where they run.

[TheBoom 31]

FFTF works all the time, it is a ratio of background to foreground processing.There's very little difference going from four cores AM=85 to three cores AM=116. If you have a maxed core it cannot do any more processing. AM=116 puts job 2 and job 3 onto a core and when your scenery rendering is maxing the job 2 is idle anyway so in that way it affects the total sim performance by only a few percent to place 2 and 3 on a core together. Your problem is most likely with other processes and where they run.

CPU idle usage is normal so that isn't the likely cause. All other running addons are on core 0.

 

What I meant is that the two LPs doing the scenery are being maxed out not the core (being technical).

 

This exact config didn't yield any blurries or other issues with 3.1. Something seems to have changed.

[SteveW 1,792]

P3D has changed a bit under the hood, and slightly in the way its processes are consuming the cores. Even so it's still the same in terms of AMs applied. I've been testing 01,11,01,00,00,00=1856 (116 configuration 4LP 3 core) vs 01,01,01,01,00,00=1360 (85 configuration 4LP 4 core) on the six core just now, keeping addons out of the way on the spare cores, and it needs some care to see the differences in operation. Running a heavy load of ORBX, PMDG, Aerosoft, etc. with a high autogen, yielding around 30fps, to show small differences as larger differences, the 4LP four core configuration is barely a few percent better at handling it than the 4LP three core configuration. The main differences will come from how the other processes are laid out. However, a big overhead from a .dll can make a difference where the 4LP four core can help. Sometimes you need to go to 4LP four cores and take more care in where the addon exe's go. The fact you get some LPs maxing seems OK, unless you are hitting something buggy in code or scenery that's too much for it to chew on all at once.

[TheBoom 31]

P3D has changed a bit under the hood, and slightly in the way its processes are consuming the cores. Even so it's still the same in terms of AMs applied. I've been testing 01,11,01,00,00,00=1856 (116 configuration 4LP 3 core) vs 01,01,01,01,00,00=1360 (85 configuration 4LP 4 core) on the six core just now, keeping addons out of the way on the spare cores, and it needs some care to see the differences in operation. Running a heavy load of ORBX, PMDG, Aerosoft, etc. with a high autogen, yielding around 30fps, to show small differences as larger differences, the 4LP four core configuration is barely a few percent better at handling it than the 4LP three core configuration. The main differences will come from how the other processes are laid out. However, a big overhead from a .dll can make a difference where the 4LP four core can help. Sometimes you need to go to 4LP four cores and take more care in where the addon exe's go. The fact you get some LPs maxing seems OK, unless you are hitting something buggy in code or scenery that's too much for it to chew on all at once.

That's what I think it might be. Something in the code is bugged. Why I mention the LPs being maxed out is because in 3.0/3.1 they never maxed out at the same settings. They will hit 80-90% sometimes but never 100% like in 3.2, and I'm inclined to think this may result in the slow loading textures and blurries.

 

When you say .dll do you mean it could be fsuipc or something else that doesn't run on a .exe process?

[SteveW 1,792]

Maybe, Dlls load up the sim in the LPs allocated in the AM.

[TheBoom 31]

Maybe, Dlls load up the sim in the LPs allocated in the AM.

I suppose there is no way to shift them to other cores is there? Might update fsuipc and give it another shot. Could be the objectflow.dll from Orbx too unfortunately there's no real way of determining the culprit in this case.

[SteveW 1,792]

On the four core +HT AM=221 (11,01,11,01) gives 6 LPs, and it's possible it can help with those dlls. Job 1 goes to core zero like with AM=85, puts jobs 2 and 3 onto core 1, load up addons on core 2 and 3, LPs 5,6,7. Without addons this would not beat 85 or 116, but presents a wider affinity space for the sim sub-processes and less to the addon exe's.

 

...there's still only four cores used by the sim, it's just some jobs will have the advantage of hyperthreading, so it's not a lot but it can work a little in some cases.

[TheBoom 31]

On the four core +HT AM=221 (11,01,11,01) gives 6 LPs, and it's possible it can help with those dlls. Job 1 goes to core zero like with AM=85, puts jobs 2 and 3 onto core 1, load up addons on core 2 and 3, LPs 5,6,7. Without addons this would not beat 85 or 116, but presents a wider affinity space for the sim sub-processes and less to the addon exe's.

 

...there's still only four cores used by the sim, it's just some jobs will have the advantage of hyperthreading, so it's not a lot but it can work a little in some cases.

 

Thanks for all the help. Will give it a go if the blurries persist.

 

Right now doing a bit of testing with LOD=6.5 set and AM=184 (same as 116 with first job on 2nd LP instead), no blurries yet. ASN, GSX and EZCA set to Core 0. Scenery threads not peaking out yet. 

 

Might have been the LOD=8.5 that ruined something.

 

Edit : Nevermind, spoke too soon. Blurries right under my wing.

[Peter Webber 339]

Steve, I have AM 116. My scenery is clear until towards the end of a flight....where it begins to blur...what affinity do you think I should use for addons while using P3D....i.e. which cores to use?

[ErichB 3,642]

 

 

My scenery is clear until towards the end of a flight

 

How long are your flights Peter?

[SteveW 1,792]

Peter, 116 should be good, use LPs 0,1 for all addons exe's, but you can also try 0,7 and 1,7 for some addon exe's if they only run a main first thread, most do. All programs will in turn kick off processes as a result of utilising system resources, especially networking (think simconnect). LPs not included in the masks will be interesting to the jobscheduler to run other processes. How things play out is very complex.

[Peter Webber 339]

Peter, 116 should be good, use LPs 0,1 for all addons exe's, but you can also try 0,7 and 1,7 for some addon exe's if they only run a main first thread, most do. All programs will in turn kick off processes as a result of utilising system resources, especially networking (think simconnect). LPs not included in the masks will be interesting to the jobscheduler to run other processes. How things play out is very complex.

ok..will give it a try...thanks..

How long are your flights Peter?

Flights of approximately 2 hours....I have even tried flying at low levels (10000ft) to view the effect and the scenery is perfect throughout the flight....up to the point of approach..i do use ASN, Proatc-x. As Steve suggests, I'll run them on LP's 0 and 1 and see how it goes....otherwise my scenery is perfect with AM 116. It's not a huge problem for me...just odd that the scenery should blur at that time.

[glider1 90]

 

 

suppose there is no way to shift them (DLL's) to other cores is there?

 

Does the new FSUIPC allow us move DLL addon processing away from the LP's that the sim uses? I didn't think we had any options on that (only for external exe addons). Would be nice.

[glider1 90]

 

 

Does the new FSUIPC allow us move DLL addon processing away from the LP's that the sim uses? I didn't think we had any options on that (only for external exe addons). Would be nice.

 

I'll answer my own question then by refering to the latest FSUIPC build notes:

 

• 69. The FSUIPC facilities for running programs at start up has been extended in two ways:
• · The number of both “RunN=” and “RunIfN=” parameters have both been extended from 8 to 16.
• · A processor code affinity mask can be specified for each, individually, with an extra parameter in the form AM=n with n in decimal or AM=Xn with n in hexadecimal.

So it looks to me as if FSUIPC can only change the affinity of external apps, not DLL's that are loaded by DLL.xml.

 

Question to anyone that understands this. If a DLL is loaded via DLL.xml, does that mean that its processing competes with the simulator for the same LP's, or does the operating system move the processing automatically to lesson the load on the simulator? I can understand that external apps can be manually tweaked by affinity, but not understanding internal DLL's operation on the loading down of the simulator.