BLURRY TEXTURES !

[TheBoom 31]

So I just did a little test with changing the affinity while in flight and I noticed two things.

One, blurry scenery all around instantly started clearing up.

Two, I might have been wrong about VAS usage. I didn't see any noticeable increase. Unless it happens over time. If that's the case there may be something else going on affecting VAS. Could be related to AM or not. Problem is I already have everything tuned for minimal VAS.

 

Edit/Update :

 

So upon changing the affinity mask externally to use all cores, I think I just had the best flight/experience in 3.2 thus far. This was in the PMDG 777 from EGCC-LOWW with all the standard addons.

 

The only remaining issue is VAS, came incredibly close to running out but luckily did not.

[Raven9000 272]

That's because FFTF does not set the ratio of rendering to scenery loading, which is what you are suggesting. The threads collecting data run fibres, and it is the ratio of time those fibres communicate their data to the time they collect data, roughly speaking.

 

As I say in other posts, the background processes can take seconds but the sim must carry on a sensible frame rate at all times.

 

The four core guys will find that HT Off no AM produces nearly the best performance all the time. Switching on HT and utilising an AM=170 or AM=85 means the sim sees a four core CPU, the same as it does with the four core HT Off no AM, exactly. It is other processes and code that is scuppering the performance in HT mode, not P3D.

That{s actually the opposite of what I have read everywhere...

 

They say the value of FFTF determines the ratio between time used for loading textures... so the lower the value less time for that and more blurries... Recommended is to RAISE that value to dedicate more to loading textures (hurting fps of course).

 

Is all that wrong?

[SteveW 1,792]

You are saying that P3D starts 8 jobs on a 4 core HT off?

Of course not - you have read none of my posts! LOL

 

 

Like I said P3D makes a job on each LP, that's 8 on an four core HT on, and 8 on an 8 core HT off - got that you guys!

 

 

 

Is all that wrong?

Yes.

 

FFTF is the *FIBRE* frame time lol!!

 

 

Hi Steve - thanks for you explanations, if you have the time...

 

Here is a theory for you.

 

I think what is happening, is that when using the task manager, the operating system decides where the sim jobs go, only limited by the task manager affinity.

Yes sort of. The Windows jobscheduler always runs and takes care of those threads. The AM in the cfg is utilised by P3D and FSX to lay out the initial thread jobs - P3D makes as many jobs as there are LPs. What you are seeing is that by unchecking some LPs in Task Manager, the threads on those move onto the least used cores of those still checked. When you do that you are de-stressing those cores that you moved the treads off of. This allows the JS to put threads there it can move around. The threads corralled together don't harm each other, the result of these looks different top what you would expect, you don't see the pegged 100% job as you would not if you set vsync and have a 24Hz refresh. The problem comes if any of those bunched together start to ask for more than 50% each, then they are restricted in their performance. In tests, this can work a little depending on how much system resources are utilised, how many simconnect clients are created and so on. Usually it's best to start with the proper AM. In my posts I show that starting with four produces the best performance on regular scenery, 6 can work better on heavy scenery. On a four core, no matter how many LPs are allocated, there are only four cores.

 

Regarding the VAS; every thread created takes up a little memory from that available to the process. Around 3.5Gb is available to P3D on a 64bit system. Each 32 bit thread takes a little bit more than a 64 bit thread, since each 32 bit thread invokes the WOW64 process that is a slight overhead too. But anyway, if we start P3D with a four core HT on and AM=85 (4 LPs of 8), or we start P3D with no AM on a four core HT Off (4 LPs of 4), it uses the same VAS. The HT version performs slightly better but uses the same VAS as the non HT version.

 

In the example of starting with no AM in the cfg and unchecking LPs, P3D creates a job per LP (as was stated many times, I'm thinking of you TheBoom lol), and then those threads of those jobs are moved onto the remaining LPs still checked in the Task Manager details. When I tested that (on a professional test harness) the scenery loading speed came down since the scenery loaders were now sharing less cores with more threads.

[TheBoom 31]

 

 

Of course not - you have read none of my posts! LOL


Like I said P3D makes a job on each LP, that's 8 on an four core HT on, and 8 on an 8 core HT off - got that you guys!

 

I was well aware of that. But you obviously did not read my post!!

 

I said that I have HT OFF on a 4 core. Which means 4 jobs 4 cores with no AM. You said I was moving 8 jobs onto 4 cores which is why I said you were wrong.

 

No hard feelings lol.

[SteveW 1,792]

Number of cores or LPs wasn't the point in focus though. It was about moving them, however many you or whoever was talking about. But you knew that.

 

The graphs in Task Manager can show 100%, but even the tiniest sleep to the thread can show as 50% in the graph, and the HT mode makes it even less obvious what's going on. But the example we were talking about, unchecking LPs, shows that when the thread is moved it is stalled, however slightly.

[SteveW 1,792]

 

The upshot of starting with no AM and subsequently unchecking the CPU boxes in Task Manager is this: we have the no AM configuration of each LP has a job started on it by P3D, unchecking the CPU boxes results in those threads moving to the least used LPs of those remaining, the threads of those jobs run in the same protection as apps and are unaffected by each other, until those on a core total demand is more than 100% throughput between them, depending on which threads are affected the sim is affected to a greater or lesser effect, the graphs don't show 100% because the main thread is stalled, the other graphs show more work since they have more threads now, they don't affect each other until they exceed 100% on a core.

 

The only improvements seen are in the scenario loading speed due to starting with as many jobs as possible. With four jobs (e.g four core HT Off, no AM) there are two main scenery gatherers one on the third core and one on the fourth core. If we turn HT on, we get six scenery loaders, on the second third and fourth cores, two per core. Each contends with another for throughput of the core. So in this way when scenery is loading, you may see all six graphs at 100%, they are pairs at 50% each of the available core throughput, yet show 100% of the LP throughput. It's still only one core, and we can only get 100% out of it. The net result of more threads collecting scenery has diminishing returns, adding more and more results in less performance.

 

When we start P3D on a four core HT disabled, P3D is unaware if we turn on HT and set an AM=85, or any AM that unmasks only one LP per core, those are still full cores, P3D starts four jobs one per core. With HT Off we still get other processes on those cores, but with HT on they get the benefit of faster switching.

 

I mentioned it before but when the threads are moved off a core, that core is freed up and the jobscheduler can transfer other threads there. When this improves performance of the sim, that is only because the activity of these threads was interfering with the sim before they moved off. By intensifying work onto certain cores, the jobscheduler finds it easier to avoid adding more processes onto those.

[TheBoom 31]

Number of cores or LPs wasn't the point in focus though. It was about moving them, however many you or whoever was talking about. But you knew that.

 

The graphs in Task Manager can show 100%, but even the tiniest sleep to the thread can show as 50% in the graph, and the HT mode makes it even less obvious what's going on. But the example we were talking about, unchecking LPs, shows that when the thread is moved it is stalled, however slightly.

 

Actually the topic was about VAS usage when setting an external AM. But whatever.

 

I'm more keen in figuring out if this could be a temporary solution to the problem at hand. So far so good. I just need to figure out whats causing the VAS usage changes.

 

 

 

I mentioned it before but when the threads are moved off a core, that core is freed up and the jobscheduler can transfer other threads there. When this improves performance of the sim, that is only because the activity of these threads was interfering with the sim before they moved off. By intensifying work onto certain cores, the jobscheduler finds it easier to avoid adding more processes onto those.

 

This. I think this is the underlying problem many of us have with 3.2. Using the job scheduler seems to put threads in conflict with each other, and when we move them off or simply "re-allocate" them externally then the issue seems to go away. Just an opinion though.

[SteveW 1,792]

^^^^^^^^^^^^^^^^^^^^

someone mark that post up! lol

 

 

I said earlier that it is the addons and other processes that prevent the sim working as well.

 

Moving threads frees up a core, it's an OK technique to start with more threads and use less cores. If this helps the sim, even though the threads of the sim are on less cores with less available bandwidth, it shows us that it is the free core that soaks up activity that would otherwise delay or destabilises the flow of the sim.

 

 

We must look to managing our addons and where they play. Keep the addons away from the core hosting the first sim job - look at the examples I gave earlier:

 

"Sim on 4 cores, HT On, AM=253=11,11,11,01 (loading speed) or AM=85=01,01,01,01 (performance), FFTF 0.1-0.2

addons on 160 Dec=10,10,00,00=A0 Hex"

 

As can be seen with 253, we have two jobs per core on the second third and fourth cores, and we can run our addons on them (third and fourth cores), we need not move them from where they start.

[SteveW 1,792]

 

So far so good. I just need to figure out whats causing the VAS usage changes.

I think what you see as changes to VAS used initially, is simply that of changed allocations. The sim uses a precise amount, but can allocate space for any amount at any time, irrespective of actual usage of that memory.

[TheBoom 31]

^^^^^^^^^^^^^^^^^^^^someone mark that post up! lolI said earlier that it is the addons and other processes that prevent the sim working as well.Moving threads frees up a core, it's an OK technique to start with more threads and use less cores. If this helps the sim, even though the threads of the sim are on less cores with less available bandwidth, it shows us that it is the free core that soaks up activity that would otherwise delay or destabilises the flow of the sim.We must look to managing our addons and where they play. Keep the addons away from the core hosting the first sim job - look at the examples I gave earlier:"Sim on 4 cores, HT On, AM=253=11,11,11,01 (loading speed) or AM=85=01,01,01,01 (performance), FFTF 0.1-0.2addons on 160 Dec=10,10,00,00=A0 Hex"As can be seen with 253, we have two jobs per core on the second third and fourth cores, and we can run our addons on them (third and fourth cores), we need not move them from where they start.

Yes but the problem with that is the addons I can move (ie the exes) don't solve the problem. You said once before that there many other addons that run on dlls that can't be moved and I'm quite certain those are the ones causing the conflicts. Maybe reapplying the AM forcefully (externally) reshuffles those addons within the same cores and alleviates the issue.

 

I think what you see as changes to VAS used initially, is simply that of changed allocations. The sim uses a precise amount, but can allocate space for any amount at any time, irrespective of actual usage of that memory.

Understood. Again seems like a balancing act now.

[jabloomf1230 2,445]

Yes but the problem with that is the addons I can move (ie the exes) don't solve the problem. You said once before that there many other addons that run on dlls that can't be moved and I'm quite certain those are the ones causing the conflicts.

 

 

I can confirm what you stated. I have the following exes running with P3d:

 

1. Traffic Optimizer

2. TrackIR

3. Active Sky Next

4. Super Traffic Board

5. VLC Media Player (needed to make LAAP real life ATC work)

6. GSX/ couatl.exe

 

I have never seen any of these ever uses more than 2-3% of my CPU time and none ever averages more than a percent or so. And rarely does the combination of all of them even exceed 5%. And  all of the OS tasks rarely use more than a few % CPU either. Unfortunately, what these statements mask is that P3d spends a lot of time in bursts maintaining the SimConnect channel, with those apps and other DLL  libraries (FSUIPC4, etc.) that P3d calls. For a time I was using Project Lasso to isolate these 3rd party apps to their own cores, but then I realized that it doesn't really help all that much. When ASN decides to push weather to P3d, it's hit or miss as to whether a minor stutter will occur or not. 

[SteveW 1,792]

I mentioned earlier, addons dll or exe, generally invoke a simconnect client, which in turn invokes the network resources. There's no need for other processes on a core to run at high percentages to get the main thread sawtoothing. But a weather engine doesn't do much for 15 minutes then injects a load of data into the sim, it wants to be off the main sim core when that happens.

 

Yes but the problem with that is the addons I can move (ie the exes) don't solve the problem. You said once before that there many other addons that run on dlls that can't be moved

The dlls loaded by the sim run in the affinity of the sim, and make a simconnect client.

 

I've spent all week moving addons around and yes they do definitely 100% make problems. I do my homework.

[Riche 5]

So using a .bat with A0 to start add ons & AM=85, HT on 4790k this seems the best configuration I have found for my system so far, my question is add ons like UT2.services & GSX/Couatl.exe start with p3d how would you start those like I start the other add ons with a .bat

Cheers

[SteveW 1,792]

Yes that should work well, the other configuration (253) would load the scenario faster and possibly with certain scenery help prevent blurriness, but wouldn't maintain the same fps. Check out FFTF values between 0.1 and 0.3, probably 0.1 to 0.2 would be near the spot.

Addon exe's traditionally started with exe.xml by the sim, these can be started by the exe.xml but put the name of the starting .bat instead of the .exe into the exe.xml file:
 

..
    <Path>C:\My Bats\addonstart.bat</Path>

[Riche 5]

..

<Path>C:\My Bats\addonstart.bat</Path>

 

?? Sorry Steve my tiny brain can't work that one out. ?