Seems like the best option is to use HT off no AM and live with a few blurries here and there.

 

My experience too, using a 4790K @ 4,5 GHz and 980TI with HT off.

My experience too, using a 4790K @ 4,5 GHz and 980TI with HT off.

Same here with 4790k @ 4.7 2x 970 HT off, tried HT on & different affinity masks but still ended up HT off & no tweaks, but do get micro stutters ?

I do notice though if I use a FFTF of 0.1 with no other tweaks textures do seem to load in slightly quicker but still blurry when first looking.

Same here with 4790k @ 4.7 2x 970 HT off, tried HT on & different affinity masks but still ended up HT off & no tweaks, but do get micro stutters

I do notice though if I use a FFTF of 0.1 with no other tweaks textures do seem to load in slightly quicker but still blurry when first looking.

 

That's odd, using a lower FFTF should have the opposite effect.

That's odd, using a lower FFTF should have the opposite effect.

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.

 

 

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.

 

So would this mean if used a AM=170 or 85 HT on I could then use lasso to put things like trackir on the free cores?? But I have noticed more vas usage with HT on but would that AM 170 or 85 use same vas as HT off?

Cheers

Riche

TheBoom, on 11 May 2016 - 3:54 PM, said:

One thing I've noticed with setting an external AM is that VAS usage is a lot higher. I have HT off on my 6700k with settings tuned for minimal VAS usage but it OOMs on a 2 hour flight from an addon airport to another. This doesn't happen with a internally set AM.

 

That is a major finding Boom pretty interesting. The big question is what is going on. With external AM, there are more threads created where you control exactly what cores you want the jobs to be on, why would that have a VAS implication? I was of the belief that an external AM means that you get the equivalent of AM=OFF with the benefit of your own personal choice of cores. EDIT: there is no way I'm going back to the jobscheduler in 3.2.

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.

 

So would this mean if used a AM=170 or 85 HT on I could then use lasso to put things like trackir on the free cores?? But I have noticed more vas usage with HT on but would that AM 170 or 85 use same vas as HT off?

Cheers

Riche

those are not free cores, all the cores are used with 170 or 85

 

HT on and 170 or 85 the sim is the same as with HT off, no difference. It is other stuff making problems if there are any.

 

No need to lasso addon exe's, start with a .bat if you want to control their affinity, they only need start up with that.

 

That is a major finding Boom pretty interesting.

It is not a Major Finding, he's making 8 jobs and corralling them onto four LPs, that's nothing new.

It is not a Major Finding, he's making 8 jobs and corralling them onto four LPs, that's nothing new

 

I'm not understanding you. Why would setting the AM externally produce more jobs? Shouldn't P3D see only the LP's that it is given from the operating system, then build the jobs as if it was existing on a computer with only that many LP's? For example, if externally setting four LP's using the operating system not the jobscheduler, P3D should think that it exists on a four core system isn't that logical? Why then does it produce more jobs that blows the VAS?

 

Just a genuine question no offense intended. Just want to understand.

 

EDIT: if this is an old question that is already been answered - sorry.

It's not how P3D works. When you start P3D it makes as many jobs as there are unmasked LPs. So if that's no AM or AM=0, that actually is AM=255 on four core HT enabled. These eight jobs, the threads thereof, are moved onto the remaining LPs by unchecking the CPU boxes in Task Manager while holding up the sim at the load dll.xml stage. The jobscheduler moves any threads of the process to the remaining processors. This is an OK technique, in the example given it frees up a core and that produces slack for system resources to function more freely. Problem is we mount extra threads together onto cores that more readily contend for throughput.

 

 

The main problem I see is that addon exes interfere with the sim.

 

 

Those with four cores wanting to go for an HT setup can try:

 

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

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

 

or

Sim on three cores, AM=116 (heavy addons), FFTF 0.2-0.3

addons on 3 Dec=00,00,00,11=3 Hex

 

 

to start addon exe's make a new file - .txt, then edit and rename to .bat:

 

make a text file edit in notepad

save somewhere useful as "somename.bat"

drag a shortcut to it onto the desktop

 

 

content of addons.bat:

 

start /B "" /affinity A0 "C:\Program Files (x86)\WeatherAddon\WeatherAddon.exe"
start /B "" /affinity A0 "C:\Program Files (x86)\TrafficAddon\TrafficAddon.exe"

 

 

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.

 

FIBER_FRAME_TIME_FRACTION=0.33

Non-Default entry. This entry will not exist in your Prepar3D.cfg file by default and must be added to the file.

Performance Tuning Tip:

This setting, which defaults to a value of .33 (33%), defines the percentage of each frame that is devoted to loading scenery. Increasing this number can reduce "the blurries", but it can cause stutters, and can also reduce the overall frame rate. Try reducing the number to the lowest level where you still get smooth scenery paging. This will vary depending on disk speed as well as the type of flying, as well as the selected scenery settings.

 

 

Not sure what to believe now lol. Unless you're saying LM oversimplified it. In which case it would affect scenery loading in a completely different way already.

 

It is not a Major Finding, he's making 8 jobs and corralling them onto four LPs, that's nothing new.

 

That would be correct if I said I was using HT ON. Read my post.

 

 

That is a major finding Boom pretty interesting. The big question is what is going on. With external AM, there are more threads created where you control exactly what cores you want the jobs to be on, why would that have a VAS implication?

 

I've seen this one before, way back in 2.5 actually. I can't remember who said it, but they said that moving the cores externally "messes up" the threading and that leads to increased VAS usage for some reason.

 

Not sure how true or accurate it is though.

That would be correct if I said I was using HT ON. Read my post.

 

HT on or off makes no difference it's not new.

 

Read my post.

Have you read any of mine? lol

"defines the percentage of each frame that is devoted to loading scenery"

 

doesn't mention "by what" though, lol. if that was between renderer and collector then setting 0.5 or more should really start to bring down the fps, until at 1.0 there would be no fps. lol.

 

 

"moving the cores externally "messes up" the threading...Not sure how true or accurate it is though."

 

Don't worry, threads don't get messed up by that because of the way the processor and operating system works.

 

I measured VAS thoughout all testing and it's the same HT on or off with the same number of LPs unmasked in the sim cfg AM.

Let's say we have an eight core HT off. We get eight jobs one on each LP. We stop the sim at the dll.xml loading stage as in the example, and unchecking four LPs in the CPU checklist in Task Manager details results in four jobs moving onto those remaining LPs. So now there's 8 jobs on 4 LPs, this works the same with P3D if we started with a four core with HT on since there's 8 LPs. Uses the same VAS. However 8 core with HT on = 16 LPs, so we would need to start with an AM that unmasks only 8 of those LPs or we would start with double the initial job count. Hence without care, HT, AMs and VAS get a bad name.

HT on or off makes no difference it's not new.

 

 

Have you read any of mine? lol

 

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

SteveW, on 12 May 2016 - 5:53 PM, said:

SteveW, on 12 May 2016 - 5:53 PM, said:

Let's say we have an eight core HT off. We get eight jobs one on each LP. We stop the sim at the dll.xml loading stage as in the example, and unchecking four LPs in the CPU checklist in Task Manager details results in four jobs moving onto those remaining LPs.

Hi Steve - thanks for you explanations, if you have the time, wondering though, it is where the jobs move that is the crucial point for reducing stuttering and even blurries. I showed in In this post, that the jobscheduler works differently to the task manager.

 

In that post, it shows that the jobscheduler causes the main sim job to be pegged at 100% load, with very little activity on the other cores until rendering is needed.

 

However, the same post shows that when using the task manager with the jobscheduler entry removed, the main sim job is not fully loaded any more, and the other rendering jobs on the other cores are taking up some of the slack.

 

To me that is a significantly better result for blurries and stuttering (but bad for VAS as you have noticed).

 

I have replicated this many times on my own system (W10 6700k). When the main sim job is not constantly bogged down, the simulator works really well (except for VAS as theBoom noticed)

 

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.

 

In my case on a i6700k on W10, the operating system sees that the main sim job is occupying the first core, and moves the other sim jobs onto other cores, ensuring that the main sim job is not overloaded.

 

But for some reason I don't understand, something about the unsupported jobscheduler entry is dumping threads on top of the main sim job, keeping it pegged at 100% load and potentially introducing stuttering issues as well as blurry issues etc.

 

On my system, something like that must be happening. My post shows exactly the same scenario (unpaused at a busy airport Brisbane YBBN RWY 01 with the engines off in rainy overcast weather) with nothing changed between them except for the jobscheduler entry. I've tried it many times so I know that I have not made a mistake.

 

What gives on that in your opinion (I mean the 100% loaded main sim job)? There could be a simple explanation that I am missing.