No reason to doubt this program but my scenario that gives best terrain loading is high resolution textures to 1 and then 1.35V HT=on  my I7-4770K@running 4,6-4,5-4,5,4,5  4K Crisp 

But i also accept the FSL A320 with less demanding loading 

 

Thanks

Michael Moe

 

Just to make sure I’m understanding this correctly, if I am runnng Vsync/Tb ON, w/unlimited, then the FFTF entry in the .cfg file is ignored, and FFTF defaulted to .01?? Even if I am running with Vsync=ON?

From some of the info in this topic, any locked FPS entry, in a Vsync=on scenario is ignored.

so does that mean FFTF effectively cannot be used with Vsync=on??

Or, does the FFTF & unlimited discussion only pertain to a vsync=off scenario.

Thanks,

mike

1 hour ago, pmb said:

As far as I recall (it was some time ago), I added just 0.01. Running unlimited. Without much result, if any.

Kind regards, Michael

1

Gentleman,

With unlimited frames at P3Dv4, Fiber Frame Timer Fraction has no effect whatever you have inside .cfg file. It simply ignored by P3Dv4. This is my finding from LM code. Fiber Frame Timer Fraction part code looks not to respond. I guess they added a multiplier so multiply something with zero simply gives zero. So, with limited frames and FFTF=0.01, you are actually very close to zero which gives you a result like you are at unlimited frames.

But what is the difference between locked and unlimited frames? Actually, there is a difference.

Frames setting, is the internal timer code, means how many times the code will loop(executed) per some specific time. Locked frames mean that we lock the internal code to be executed x times per x specific time, while unlimited means that the code will loop as quickly as possible. 

While the tasks inside LM code are asynchronous, having unlimited frames simply put staff in the line and waiting to be executed. In this case, we may have stutters (while the time of a big task in the line has to be executed like many effects or many buildings). While all of the tasks are on hold until they take their place to be executed, you simply put more and more. When a task is easy to be executed, frames are jumping up and when a task is very heavy, frames are going down.

With limited frames, things are totally different. If we have locked frames at 30, and we actually have 30 frames, means that there are no tasks into the asynchronous table. This is why FFTF exists from FSX times. When you change FFTF value, you simply change the multiplier of the time that will be devoted to the scenery load part code. Scenery loading is one of the most demanding codes inside FS. It is being executed tile by tile and we have plenty of them. When FFTF is low as 0.01 we simply tell this part of the code to stay very little time here and to continue to the execution of the rest code parts. When it is very high, happens the opposite.  

So, why to devote high cpu resources to the ground scenery load while we are on the ground and we can not see it optically? Lets simply give the cpu resources for the rest things like traffic, scenery effects and etc.  

When we are leaving the scenery, actually we have more cpu resources and we can assign them to the ground scenery load just increasing the FFTF value. 

Can we have stutters in this case? Of course, if a big task came suddenly (like immediately show 1000 building) but not so noticeable as in unlimited frames. Sometimes we do not feel them.

Can we have blurries? It totally depends on CPU + GPU + FFTF. Lower CPU and GPU power theoretically need bigger FFTF value.     

Can we have Scenery black boxes? I personally never had, but I suspect bottleneck between disk and motherboard especially with high-resolution graphics tiles.

Finally, reading this thread from the first post till the end, I can assure that some things can be done and some not without forcing the scenery to reload.

Regards.

Achilles Philippopoulos

 

Hi.

I installed FFTF and I cannot run P3D4 anymore. I uninstall FFTF and P3D starts normal. I reinstalled FFTF and P3D won't start. HELP. 

Thanks 

Update.

I cannot start P3D anymore. With FFTF or without it. The only changes was done installing FFTF. P3D was working perfect before. 

Edited March 24, 20188 yr by skysurfer

17 minutes ago, AchillesP said:

Gentleman,

With unlimited frames at P3Dv4, Fiber Frame Timer Fraction has no effect whatever you have inside .cfg file. It simply ignored by P3Dv4. This is my finding from LM code. Fiber Frame Timer Fraction part code looks not to respond. I guess they added a multiplier so multiply something with zero simply gives zero. So, with limited frames and FFTF=0.01, you are actually very close to zero which gives you a result like you are at unlimited frames.

So, while the FFTF setting does nothing for fps set to unlimited, the FFTF Dynamic tool is able to adapt the value, just outside the prepar3d.cfg mechanism - right?

Kind regards, Michael

8 minutes ago, skysurfer said:

Hi.

I installed FFTF and I cannot run P3D4 anymore. I uninstall FFTF and P3D starts normal. I reinstalled FFTF and P3D won't start. HELP. 

Thanks 

Hi Edward,

Not sure why that is happening but you could try starting P3D4 first, load a flight and, once stable, start the FFTF Dynamic utility. I found I could start and stop the utility as often as I wanted while P3D was running. It changes the FFTF variable on the fly and there appears to be no requirement to start it first.

Regards,

Mike

Mike. I cannot even start P3D anymore. I uninstalled FFTF and P3D is dead. P3D was working great till I installed FFTF. No other changes were made to P3D for many weeks except FFTF installation.

Thx 

3 minutes ago, pmb said:

So, while the FFTF setting does nothing for fps set to unlimited, the FFTF Dynamic tool is able to adapt the value, just outside the prepar3d.cfg mechanism - right?

Kind regards, Michael

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)

 

2 minutes ago, Cruachan said:

Hi Edward,

Not sure why that is happening but you could try starting P3D4 first, load a flight and, once stable, start the FFTF Dynamic utility. I found I could start and stop the utility as often as I wanted while P3D was running. It changes FFTF on the fly and there appears to be no requirement to start it first.

Regards,

Mike

FFTF can be started before or after P3d. It does not matter. It will recognize if P3D is running in any case.

34 minutes ago, pmb said:

So, while the FFTF setting does nothing for fps set to unlimited, the FFTF Dynamic tool is able to adapt the value, just outside the prepar3d.cfg mechanism - right?

Kind regards, Michael

Hi Michael,

My understanding is that the FFTF default value of 0.33 is assumed by the sim as there is no entry in the config file. The address of this value can be accessed by the FFTF Dynamic utility and said value modified on-the-fly as circumstances change in the running sim. Not sure what happens if an entry has been added manually to the config file although the assumption would be that this too can be modified as it is only read once into memory while the sim starts. So, whether it is 0.33, 0.01 or, indeed, anything else does not matter. The value will be changing as you go while FFTF Dynamic is running.

Regards,

Mike

 

Edited March 24, 20188 yr by Cruachan

4 minutes ago, Cruachan said:

Hi Michael,

My understanding is that the FFTF default value of 0.33 is assumed by the sim as there is no entry in the config file. The address of this value can be accessed by the FFTF Dynamic utility and said value modified on-the-fly as circumstances change in the running sim. Not sure what happens if an entry has been added manually to the config file although the assumption would be that this too can be modified as it is only read once when the sim starts. So, whether it is 0.33, 0.01 or, indeed, anything else does not matter. The value will be changing as you go while FFTF Dynamic is running.

Regards,

Mike

 

Hi Mike,

If the FFTF value does not exist inside .cfg file, then by default this value is 0.33. 

If it does exist, then will be the value you have edited. 

When FFTF dynamic starts, reads your value (0,33 or whatever) keep in as backup inside the utility, changes the fftf value on the fly, and when the utility is closing or p3d is closing, the utility writes back your original one inside P3D memory. 

If I do not write back the value, then you will see it inside your .cfg file, because P3D write .cfg file at every exit.

9 minutes ago, skysurfer said:

Mike. I cannot even start P3D anymore. I uninstalled FFTF and P3D is dead. P3D was working great till I installed FFTF. No other changes were made to P3D for many weeks except FFTF installation.

Thx 

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

 

7 hours ago, Cruachan said:

My attention then turned to the Affinity Mask (AM). Steve’s suggestions were followed and it quickly became apparent that the Prepar3D Main thread did not ‘like’ being moved away from Core 0 on my chip.

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?

What you described first Mike I gave you an idea how to problem solve with an example of an AM with HT OFF to compare with the HT On variant. If I didn't happen to put the first number one on your maximized core then you should put it there not ignore the idea. It was for problem solving. Then I showed how you can free up cores by moving some of the ones to double up. This is good advice I'm continuing to push irrespective of your test results..

 

Clearing up some confusion surrounding HT On or Off:

 

With HT On there is still only one core. Enabling HT and using '11,' configurations still only uses one core.

 

With HT On Affinity Mask configurations -  '01,' or '10,' can and will utilise 100% of that core if the process demands it. Only one LP need be enabled if the task is monolithic and wants up to 100%

 

P3D splits out its tasks over as many LPs as it sees so enabling HT with No AM means you get split out to double the tasks.

 

Since the split out is to enable the task to get its own entire core we use as many '01's as we can hence Mike finding that eight '01,'s to be a good AM (it is after all the most basic choice and works every time)

11111111 vs 01,01,01,01,01,01,01,01 will produce the same result except that HT enabled will complete all the tasks sooner meaning loading quicker - however the main task is still on the same one core, it will be 'fed' more efficiently and might see a few fps gained - that is all.

The staggering is usually something as simple as a panel device driver and this kind of thing in the wrong place can play around like the stutter on Mikes system.

 

I said several times we might see a slight drop in fps when the system is running just right it goes along with the way FFTF works. It is getting fed more efficiently and we make room for those other exe's my combining ones where it is safe.

 

 

Edited March 24, 20188 yr by SteveW

To test an app like this 'fairly', the system would need to be tuned to and tuned with it, it shouldn't be thrown into a current system and especially while all sorts of other settings and AMs are tried at once, that's not a fair test. Read Gerard's notes there's a specific use that might be suitable. But it can't replace lack of power, for that we have to relent our rightmost settings, choose lower textures, and expect lower fps.

 

Edited March 24, 20188 yr by SteveW