Udostępnij za pośrednictwem

Tweak of the Week

  • Artykuł

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.

Comments

  • Anonymous
    May 11, 2007
    Thanks, this was a great help. Lets see how it will run on my new quad core next week hopefully without this tweaking! I appreciate all the help you guys have been doing to finally make this game more enjoyable.

  • Anonymous
    May 11, 2007
    Hi - I've been following this thread with eager anticipation, and I'm glad you've finally got all (well, as humanly as possible at any rate - edit) the bugs ironed out! I can't wait to see SP1 in action on my dual core pc! First off, FSX is a fine piece of software, and its so refreashing to see the developers keeping us updated to what's being done, even if the dates do get rolled back, keeping us all in the loop, as it were, is to be commended and many other software houses should take note! Cheers for all the updates and hard work Phill Neil

  • Anonymous
    May 11, 2007
    I would love it if you would make a habit out of giving us insight from time to time about. Thruth be told, sometimes I think half the enjoyment I get out of FS is tweaking it! A while back you also posted on Avsim concerning what is going on behind the scenes with the various water level settings-- it was excellent insight into how the water and autogen settings can affect each other... maybe you could recycle that info here for a future installment. Concerning the fiber fraction I'm still intrigued by the possibility of lowering this value on dual core to ensure a higher percentage of CPU availability for rendering work at all times. (thiking of a sans-TileProxy setup) Brian Smith confirmed the possibility for benifit here: http://forums.avsim.net/dcboard.php?az=show_mesg&forum=121&topic_id=396183&mesg_id=396354 ...though he didn't sound as enthusiastic about the possibility as I am.   Concerning multi-core usage, one question that came to mind last night was that I have seen you mention on a couple occasions "the more cores the better".  While I'm really excited to see the results of the multi-core work you've done, from the work that has been described I'm having difficulty picturing enough work scheduled for secondary cores to take full use of more that one additional core.  You have the existing multi-core work which I understand to be ~ 10-15% 2nd core usage (I don't actually have my DC yet to have seen it in action).  Then you have the D3D batching... the impression I have is that we are probably looking at 10% additional usage tops. That's 25% usage, max.  Then you have the texture processing: Given a fiber time setting of .33, from Adam's explanation it follows that with RTM, at most 25% of core 0's time had been devoted to texture processing.  Granted, this is probably the sort of work where there is often more that could be done, but since at least some of the texture work must still occur on core 0, it seems that even if you were doing 3 times the texture processing with SP1 vs RTM, you still wouldn't be fully using the remaining 75%+ from the first additional core. Anyway, my mood has improved immensely now that SP1 is within reach-- and I'm sure the same goes for you.  Thanks to you and Adam for putting together this info for us, and I look forward to additional tweaking posts in the future.

  • Anonymous
    May 11, 2007
    Hi Phil, So your on the final test today, Has it gone with all your expectations and will release next week sometime ? You and your team have done an amazing job with FSX and to give us the opportunity to be able to squeeze more from it is unbelievable, Thanks again for your dedication it's well appreciated Mark

  • Anonymous
    May 11, 2007
    Hi Phil, I've been experimenting with 30cm photoscenery lately and sometimes the sim does not keep the blurries away (as it would with lower resoloution scenery under the same settings), so it will be interesting to see the impact SP1 has on that.  Sounds like the multi core work will help, and if you think 1.2m is visually amazing (and it is), just wait until you see higher. So for multi core machines, what should we do conerning FIBRE_FRAME...?  Change it back to the default 0.33, or take it out of fsx.cfg completely?  Might we even reduce the value? Finally  a future tweak blog suggestion.  There's a lot of folklore concerning TEXTURE_BANDWIDTH_MULTI.  What does it do and how can it help/impact frame rates? (Hey dreddhk - don't know who you could possibly be talking about ;-) )

  • Anonymous
    May 11, 2007
    The comment has been removed

  • Anonymous
    May 11, 2007
    Fatboysim: on a multicore machine, either leave it alone or lower it a bit. I'll see what I can find out about texture_bandwidth_multi

  • Anonymous
    May 11, 2007
    Phil: Here's you post re. water settings: http://forums.avsim.net/dcboard.php?az=show_mesg&forum=121&topic_id=391008&mesg_id=391101 (Ha! Now that I read that-- thanks! I guess you are basically doing what I half-jokingly asked for in my reply to that post)

  • Anonymous
    May 11, 2007
    Maui: talking about water is a couple weeks out, but its on my radar.

  • Anonymous
    May 11, 2007
    Thanks for this... Any extra info on FSX is helpful... However here's a basic question... I'm running FSX on a Dual core 6300, 4GB DDR2 800, ABIT AB9 PRO 800 FSB -- 500GB (at least) on disk space available. FSX rolls over and dies every chance it gets! Is SP1 addressing this?? Thanks!

  • Anonymous
    May 11, 2007
    Atguru: the data support no conclusions, and I dont really do tech support here.

  • Anonymous
    May 12, 2007
    The comment has been removed