FFPS:FFTF question

[Joe L 62]

3 hours ago, AchillesP said:

FFTF Value can be written to P3D memory in any case, but as I wrote above, at unlimited frames situation, the part of the code that contains the FFTF value is ignored by LM code because it is being multiplied by the unlimited frames (which are zero in this case)

• . . .

So I am confused.  The webpage says:

Frames range option:

Suggested for unlimited frames + VSync disabled + TB disabled.  

You set the minimum and the maximum frames + FFTF range + times you want FFTF to be updated per sec to Flight Simulator.

An example can be: Min frames=24, Max Frames=28, FFTF minimum=0.05, FFTF maximum=0.33, times to update per second=1.

In this case, at 24 frames FFTF will be 0.05, at 26 frames FFTF will be around 0.19 and at 28 frames, FFTF will be 0.33. Below minimum frames set, FFTF will always be 0.05 while above max frames set, FFTF will always be 0.33.

So is "FFTF Dynamic" actually affecting anything if we run unltd frames?

[Achilles Philippopoulos 115]

32 minutes ago, Joe L said:

So I am confused.  The webpage says:

Frames range option:

Suggested for unlimited frames + VSync disabled + TB disabled.  

You set the minimum and the maximum frames + FFTF range + times you want FFTF to be updated per sec to Flight Simulator.

An example can be: Min frames=24, Max Frames=28, FFTF minimum=0.05, FFTF maximum=0.33, times to update per second=1.

In this case, at 24 frames FFTF will be 0.05, at 26 frames FFTF will be around 0.19 and at 28 frames, FFTF will be 0.33. Below minimum frames set, FFTF will always be 0.05 while above max frames set, FFTF will always be 0.33.

So is "FFTF Dynamic" actually affecting anything if we run unltd frames?

1

Do I really have to answer this one? :-)

I described the general FS code concept. I can only say that I do some tricks in order FFTF to work also with unlimited frames. Can not say more. Sorry :-(

[Cruachan 705]

2 hours ago, SteveW said:

I didn't instruct you to move the sim from your favourite core Mike. If for some very odd reason you can't move it off core zero that's fine. Did you try the AM configurations I was talking about from core zero then? Your results smack of some other thing altering the performance of your sim in that staggered way since you should be able to get smooth results on less that 8 cores any day. Did you try the HT off then On test I described?

Hi Steve,

I know I must appear at times to be a pain in the derrière! I’m only relating what occurred during my testing however problematic that testing sequence might have appeared to the experienced eye. 

You may recall those mysterious results reported a couple of years back when, and quite accidentally, I applied an AM of 21760 to Prepar3D v3.x with HT disabled. This produced a strange randomised allocation of a core to the main P3D thread each time the sim was started. This AM was being tested with HT=ON and I had forgotten to remove it after switching to try with HT disabled. Whatever the reason, and there was much speculation and doubts expressed at the time, the resultant smoothness in operation of the sim was impressive and encouraged me, against all logic, to stick with it.

Perhaps I am finding myself to be in a similar position now in that the AM of 21845 appears to be the best choice on my setup despite everything said to the contrary. Incidentally, I referred to your advice as suggestions rather than instructions and, yes, I did  try everything I could think of short of disabling HT. Hyperthreading enabled seems to be the sweet spot without excessive heat generation while running all my gaming software. I know, I have resisted this in the past, but now it does seem to be the case and I have accepted it. Prepar3D v4.2 performs well enough with HT enabled and no AM, but it does not match the silky performance witnessed with an AM of 21845. I cannot take the credit for trying this configuration as I had noted Rob had tried it with good results with his i7-5960X. At the time it seemed a neat solution and has allowed me to enjoy the benefits of running HT enabled while, at the same time, configuring P3D to use 8LPs which seems to be optimal according to my testing. That said, I believe I do understand your doubts and I accept all that has been said. However, all that notwithstanding, I believe I have to go with what works for me even if it might be viewed as being less than ideal. Who knows, perhaps I will be forced to revisit this again sometime in the future!

Regards,

Mike

[SteveW 1,792]

Exactly it was only a couple of years ago I said about  "No AM HT Off" guys would have something else to say once they got hold of many cored systems. As you say I did a lot to try to get you into it a long time ago, seems good that Rob has gone that way too. I'm not surprised. I've only ever seen slightly better results HT On than Off  but it's always there. That's why I always said if you don't get the expected results, expect you got something wrong and try again.

If you understood me you asked about your stutter problem so I suggest you try a couple of things. Indeed you are a challenge and I'm always hopeful that one day you do try something I suggested on the day.

What would be helpful is to find the optimum number of cores, and then LPs to enable the fastest loadup time. Irrespective of how the sim performs or looks forget that for the test. If it's 8 then you have it don't you - 01,01,01,01,01,01,01,01. If it is 7 you have a spare core don't you?

But it would be a good place to start knowing how many are needed, then find your best layout for it. If you need more spare cores you can double up in some not all - it's what's done to find the optimum setup.

You like to mention the Jobscheduler but that presents the view of the CPU if you will, so your AM of 8 01,01,01,01,01,01,01,01 looks like 11111111 to P3D. It is what P3D does inside those and what it connects with counts.

For it is when you demonstrate for example that the same number of cores produces different results you have demonstrated to yourself that it is not the AM that is the problem, the AM merely moves the problem around.

As i said before make sure you got no anomalies, like getting rid of the shader folder, that's goofy unless you know it needed rebuilding, and then you needed to be sure all the shaders are rebuilt before testing. Just mentioning that because some might get the wrong idea about it.

Another thing, aircraft with special gauges and dlls might throw you off the scent, so run a stock AC like the Baron. Show yourself how many cores makes no difference in loading times and see if there's any difference to the display if you change it from there.

Edited March 25, 2018 by SteveW

[Cruachan 705]

35 minutes ago, SteveW said:

If you understood me you asked about your stutter problem so I suggest you try a couple of things. Indeed you are a challenge and I'm always hopeful that one day you do try something I suggested on the day.

What would be helpful is to find the optimum number of cores, and then LPs to enable the fastest loadup time. Irrespective of how the sim performs or looks forget that for the test. If it's 8 then you have it don't you - 01,01,01,01,01,01,01,01. If it is 7 you have a spare core don't you?

But it would be a good place to start knowing how many are needed, then find your best layout for it. If you need more spare cores you can double up in some not all - it's what's done to find the optimum setup.

You like to mention the Jobscheduler but that presents the view of the CPU if you will, so your AM of 8 01,01,01,01,01,01,01,01 looks like 11111111 to P3D. It is what P3D does inside those and what it connects with counts.

For it is when you demonstrate for example that the same number of cores produces different results you have demonstrated to yourself that it is not the AM that is the problem, the AM merely moves the problem around.

Hi Steve,

I believe I did in as much as I started from scratch by deleting Prepar3D.cfg and, yes, also the content of the shaders folder which I accept was probably unnecessary. Then I slowly built up the load until the stutters started to reappear. My images reflect the best settings arrived at for general use and these include my having switched to 8xMSAA along with the abandonment of NI and SGSSAA.

As to the optimum number of cores I believe it to be 8 using LPx1 per core. Leaving one core entirely free brought back the micro stuttering.

The periodic and somewhat persistent stuttering/juddering is no longer an issue and I attribute this to my revised settings and alternative AA solution.

The vehicle used during testing was the default F-22 Raptor. It is agile and allows rapid changes of attitude during flight. I suspect many reports of smooth flight apply to straight and level configurations. I aim a little higher by seeking to eliminate those hesitations during rapid turns and while rolling back and forth. In that I have been moderately successful.

Regards,

Mike

[SteveW 1,792]

Again Mike that doesn't answer my question because you tipped in your favourite maximum rightward settings and looked for stutter. I was suggesting you don't worry about that for the test and concentrated on the value for a particular reason. The amount of time it took to load, before looking at your settings. And therefor does not allow the enabling of a core if you can spare it. Ah well. Perhaps another day. Let's say then that you do seriously need all 8 cores. That means you might only need 8 LPs on seven cores and double up a pair of LPs on one core - leaving a core free and improve your performance overall - no idea what I am on about and I am not getting through - right?

[joepoway 241]

9 hours ago, Avidean said:

 

 

Edited March 25, 2018 by joepoway

[SteveW 1,792]

...and Mike, if you can get the same load time out of 8 LPs on 7 cores, then maybe you can improve it with 9LPs on 7 cores? Anyway, load time does not equate exactly with outright available performance but it's a consistent indicator that puts you in the ballpark.

[joepoway 241]

2 hours ago, Achilles Philippopoulos said:

Do I really have to answer this one? :-)

I described the general FS code concept. I can only say that I do some tricks in order FFTF to work also with unlimited frames. Can not say more. Sorry :-(

Not to beat a dead horse as they say but from what I think you are saying is this:

If we set Unlimited frames in P3D no matter what entry we put in the config file for FFTF it is ignored and does NOTHING and the sim runs as though it were 0.01?

But if we run Locked frames with no entry the default is 0.33 but IF we add an entry into the config file the new value will be used (obviously not dynamically).

So therefore FFTF entries into the config file are only applicable when using Locked Frames (something I never knew)

HOWEVER through some "tricks" FFTF altered values do work in Unlimited mode (and obviously locked frames mode) with this Dynamic app.

So your bottom line is if you want "modified" FFTF values when running Unlimited frames it's only possible with this app and we are accomplishing nothing by changing that value in a config file mod IF we run Unlimited frames, Correct?

Joe 

[SteveW 1,792]

26 minutes ago, Cruachan said:

...I slowly built up the load until the stutters started to reappear...

Good grief, i just realised what you are saying Mike. If you increase the glamour settings till it just starts to stutter and then change anything like the CPU arrangement and re-test you will find it a problem.

Can't you see that's like building a house of cards and saying look if I touch anything it falls down.

Instead find out how to arrange the best throughput of your setup and then see what it can do on top of that. If it turns out to be 01,01,01,01,01,01,01,01 then that's good to know. Instead, you might just be just head above water, somewhere, rather than knowing you have the best arrangement supporting that load.

[SteveW 1,792]

Good evening Joe and Achilles, I'm enjoying your conversation also.

[SteveW 1,792]

Remember I said that that the small climb in fps with high FFTF values is due to less 'linkage' time the main thread is stopped a lot less often.

The time taken to load the sim shows clearly the differences that we get with changing the FFTF value set in the Prepar3D.cfg

Here are the graphs captured of those simple changes to FFTF on a system guaranteed to reproduce the same scene each rerun.

 

Clearly setting FFTF to 0.9 loads the scene fastest and we can see a small rise in fps, 0.1 takes ages. Sure enough looks like the 0.33 value is the same as no value. This is in Unlimited, no Vsync, No TB. Misty rainy view cross cockpit to tower, lots of clouds thunder, light buildings and autogen.

 

[skysurfer 76]

9 hours ago, Cruachan said:

Hi Edward,

I think that must be a coincidence and not caused by the installation of the FFTF utility. First I would try deleting Prepar3D.cfg and allow P3D, assuming it will now run, to build a new file. If that fails I would uninstall the P3D Client and then reinstall same from the download from your LM Account. Hopefully that should fix it.

Regards,

Mike

 

I did client reinstall and P3D still fails to start. 

[skysurfer 76]

Update. After running CCCleaner and reinstalling Client I was managed to start P3D. I started P3D several times and P3D stared OK. After that I installed FFTF back again P3D fails to start again. After uninstalling FFTF P3D failed too start. This is definitely FFTF causing P3D to fail to start!!! I am gonna call for refund. 

 

Edited March 25, 2018 by skysurfer

[GSalden 4,657]

4 hours ago, joepoway said:

Not to beat a dead horse as they say but from what I think you are saying is this:

If we set Unlimited frames in P3D no matter what entry we put in the config file for FFTF it is ignored and does NOTHING and the sim runs as though it were 0.01?

But if we run Locked frames with no entry the default is 0.33 but IF we add an entry into the config file the new value will be used (obviously not dynamically).

So therefore FFTF entries into the config file are only applicable when using Locked Frames (something I never knew)

HOWEVER through some "tricks" FFTF altered values do work in Unlimited mode (and obviously locked frames mode) with this Dynamic app.

So your bottom line is if you want "modified" FFTF values when running Unlimited frames it's only possible with this app and we are accomplishing nothing by changing that value in a config file mod IF we run Unlimited frames, Correct?

Joe 

Correct Joe.

@Mike : regarding the amount of cores

Record a flight of 4 minutes over a terrain with a large city and a rural area.

You can play it back with a different amount of activated LP’s and run Fraps for 3 minutes to measure you min/max/average framerare.

Then you can test and see what is best for your system.

 

Edited March 25, 2018 by GSalden