Tweak of the Week
So here is an idea. Occasionally I will publish information on various "tweaks" to the product and what they do. A "Tweak of the week" if you will.
So let’s start with the mysterious sounding FIBER_FRAME_TIME_FRACTION.
There are page after page of google, I mean livesearch, hits on this term. Obviously people have been talking. That’s probably due to the post Adam, our resident terrain guru, made here.
Now we hope people don’t hurt themselves with settings that deeply affect the engine like this, because there is always the possibility of misuse. Usually that is outweighed by the value of being informed, and the great thing about the community is sometimes interesting questions do crop up out of people using these settings.
Christian Buchner, author of TileProxy, recommended that Win64 users of TileProxy set FIBER_FRAME_TIME_FRACTION to 2.0 when the base value is .33. A lot of speculation about what that would be doing cropped up.
Adam Szofran, our resident terrain guru, gave out the skinny for everyone. I posted it first on avsim.com, but wanted to repost it here so the information didn't get lost.
Here are 2 quotes from Adam, verbatim:
"
FIBER_FRAME_TIME_FRACTION determines the maximum amount of time per frame that we will run fiber jobs on the primary thread. We measure how long it took to simulate and render and then multiply that time by FIBER_FRAME_TIME_FRACTION to determine how long to run the fibers. For example, if it took 10 milliseconds to simulate and render and FIBER_FRAME_TIME_FRACTION was set to the default value of 0.33, then we would allow the fibers on the primary thread to run for up to 10 * 0.33 = 3.3 milliseconds. For fraction values of 1.0 and 2.0, the time given to fibers would be 10 milliseconds and 20 milliseconds, respectively.
The operation of FIBER_FRAME_TIME_FRACTION on single core machines has not changed since RTM.
On multi-core machines in SP1, we moved many fiber jobs off of the primary thread and onto secondary threads. Since FIBER_FRAME_TIME_FRACTION only affects scheduling of jobs on the primary thread, it will have less of an impact on the performance of Flight Sim on multi-core machines. In fact, we moved so many jobs off of the primary thread that there probably isn’t enough fiber work left to soak up the full time allowed by the default value of 0.33.
Therefore, on multi-core machines, there’s very little reason to tweak the fraction because it really only impacts performance of single core machines.
"
and
"
Please emphasize the pointlessness of tweaking this value on multi-core machines.
Further, setting it to values greater than the default value on single-core machines can increase frame rate volatility because it increases the amount of time we *might* allocate to fibers if there is adequate work waiting in the queue. When the queue is full, we’ll allocate the full amount of time to fibers but when the queue is empty, fibers get no time because there is no work to do. If the rate of new jobs entering the fiber queue is bursty and the full time allowed for fibers is large, then you can imagine how this would increase volatility.
If people feel like the fibers aren’t getting adequate resources, they would be better off leaving the fiber fraction alone and just lowering the frame rate limit slider, which helps divert more CPU time to primary thread fibers without increasing volatility.
"
I'd take those words as golden.
He also wanted me to mention that TileProxy is using a FS9 path, basically because it is the only path available for the style of source data involved. However, that path requires massive amounts of file I/O and because of the huge number of files involved it completely blows the texture cache used by the terrain texture compositor. So there is a limit to how efficient that will ever be until we rework the architecture to be more accommodating.
Another question was does photo-scenery benefit from the multi-core work, and Adams’ answer was:
”
Photo scenery loading, like loading of all terrain data, benefits greatly from our multi-core work. The more cores the better.
"
Hope this helps.