Mike's Musings #4: FSX Nirvana

By Mike McCarthy (6 January 2007)

1. Tell them what you're going to tell them.
2. Tell them.
3. Tell them what you told them.

Summary

Begin with an optimum hard drive defrag and file placement. As discussed in Musings #3, ideally you will use both Ultimate Defrag and O&O Defrag to accomplish this, though I must tell you that my UD installation degraded over time, and reinstalling it did not fix my problems. I eventually backed UD out entirely, but you might have a different experience, and I'm going to continue to write here as if my UD problems had never arisen. Trial versions of both products are available, so you can run your own tests without making an up-front investment. Still, I now suggest that you try O&OD all by itself. If you're satisfied with the results, don't bother with UD.

For a given setting of the sliders, and for a given hard drive, and for a given graphics card setup, doing an optimum file placement will minimize index search times, thereby maximizing scenery cache throughput, in turn staving off stuttering as best as can be achieved. See below for what the surprise optimum file layout turns out to be.

Having laid out the file system as discussed below, initially push all of the sliders all the way to the left. This will reduce the load on the scenery cache to the absolute minimum, thereby maximizing what I will call "stutter headroom". Now we must decide what to do with this headroom.

To use the stutter headroom optimally we must first consider which data gets imported into the scenery cache versus which data is generated internally by FSX, the idea being that internally-generated data (clouds and instrument panels, for example) places no load on the scenery cache, though it does place a load on the renderer, as discussed below.

The FSX Options-Display menu choice helps us by revealing three important tabs, Scenery, Weather and Graphics. To a first approximation these tabs respectively classify visual data into imported, CPU-generated, and graphics card-related. With file layout treated, the sliders for imported data can be walked to the right until stutter is encountered. Assuming optimally laid-out files as discussed below, there is no point in trying to get more aggressive than this with respect to imported data. In fact, attempts to do so will hurt rather than help. It will be possible, however, to do a tradeoff among the various importation sliders, according to your taste, as long as the system stays below the stutter threshold.

We now turn our attention to the graphics rendering subsystem. The throughput of the renderer is a function of both CPU speed and graphics card throughput capacity. As long as there is unused renderer capacity we can keep nudging the graphics and weather sliders to the right until the system starts consistently dropping below our target frame rate. When this happens we will know that we have saturated the CPU and/or the graphics card.

Finally, within the graphics card itself there are operations which, to a first approximation, can be performed without placing a load on the CPU. These include projecting 3D objects onto the 2D screen, edge filtering, and so on - - most of the operations listed on the graphics tab. (It is widely believed that DirectX 10, in conjunction with DirectX 10 capable graphics cards, will allow even more work to be pushed out of the CPU and into the graphics card.)

An exception here is frame rate, which is really a directive to the CPU-resident software about how frequently to cycle not only the renderer but also the aircraft flight model. I personally can tolerate 10 fps, but 20 fps makes for smoother flight dynamics. You must make your own personal taste tradeoff here between system visual and flight dynamics smoothness versus visuals detail.

Next, as an example we consider terrain mesh size. The finer the mesh the more data gets imported, but as long as stutter is not encountered we can continue to reduce the mesh size. Doing so will cause 3D surfaces such as mountains to have their contours rendered with increasing fidelity. Note, however, that there will be a corresponding increase in the load placed on the renderer so we must guard against an unintended decline in frame rate.

Now consider detail radius: The further out we look, the more detail data must reside in the scenery cache, crowding out other kinds of data. Not only that, even the distant data still must be pushed through the graphics card's 3D-to-2D projection logic, soaking up card bandwidth that might be more productively spent on improved close-in detail.

You should run these kinds of experiments yourself on your own configuration. Depending on the relative and absolute speeds of your disk drive, CPU and graphics card, and depending on how much memory you have, your results will differ from mine in detail, though the principles of maximizing performance will remain the same.

Evidently, to achieve system balance we must play with defragmentation, with file system layouts, and with the sliders, till the headroom of each component is just about to be used up. Once balance has been achieved, given a constant hardware configuration and graphics card setup, and given a constant file system layout, there will be nothing more we can do to increase overall system performance.

Now for the surprise: Aided by Ultimate Defrag (while it was still operable on my system), the file system layout which proved to be most effective was to move the Windows and System Volume Information files to my hard drive's high-performance outermost tracks, along with the Addon Scenery, Autogen, Scenery, Texture and Weather files. At the same time, to speed index searches I directed that all folders be moved close to the MFT. (This is because folders themselves contain sub-indexes and therefore can be considered to be extensions of the MFT.) I also directed that any file or folder which hadn't been accessed within the past day be "archived" - - moved to the low-performance inner tracks of the drive.

Finally and most importantly, in addition to folder/MFT adjacency I directed that the folders and files of the overall system be sorted by name. This not only affects file placement, it also causes the MFT entries themselves to be organized alphabetically, significantly reducing both MFT and FSX index search times.

O&OD can also do folder/file name sorting, but it lacks the MFT adjacency feature of UD. My experiments showed that UD's MFT adjacency feature did make a modest performance difference so it is too bad that I had to abandon Ultimate Defrag. But you might not have to abandon it. You can try UD out for free for seven days, or for $10 US for ninety days. However, as discussed in Musings #3, you would still want O&O Defrag for a clean defrag of PageFile.sys and certain other system files. O&OD is available as a thirty-day no-cost trial.

The second number, 45 seconds with all sliders to the left versus the original 190 seconds, is a direct measure of the speed with which the various XP and FSX indexes are now being searched. In fact, based on my professional experience developing operating systems, I will state without qualification that this is a greater performance increase than would have resulted from my simply changing over to a dual-core Vista system.

Anyway, with faster index searches there should now be stutter headroom where none existed before, and so there is. Using the FSX 2D 737 panel, with the pedestal and radio stack.windows open, and with my own product running in the background, on my 2 Ghz office computer I am now able to do the following with only occasional minor stuttering, and that only at extremely low heights above detailed mountainous terrain ...

Now I was down to the issue of graphics card throughput capacity. To soak up some of the excess here I engaged Mesh Complexity 40 with bilinear filtering. Note that while Mesh Complexity is listed on the Scenery page, my experiments showed that it actually behaves like a combined CPU and graphics card issue, perhaps because a polynomial curve-fitting algorithm is being used by the CPU software to generate topographical detail for the graphics card. There are additional checkboxes on the Graphics page but I didn't evaluate them.

Finally, I stress-tested the whole system by making a low-level pass over the mountains west of Denver, looking right and left occasionally so as to stress the scenery cache look-ahead logic. The results? In the immortal words of Chuck Berry in Maybelline, "the Fo'd got hot an' wouldn' do no mo". In other words, I had balanced the system and had taken performance as far as it could be taken.

Given my hardware, for reasons of personal taste you probably would make a different set of slider decisions, but that's not important. What's important is that by taking the all of the steps necessary to reduce index search times, a viable set of slider choices emerges.

Regarding slider choices, if you didn't follow my balance-the-system reasoning, FSX default settings should be tried as they may in fact achieve balance on your particular machine. Another thing to try would be the newly-announced Tweak FPS for FSX, discussed in this NOTAM available for purchase at the Pilot Shop.

Conclusions

We have seen what a dramatic difference name-sorting of the MFT and folder/file placements can make to FSX performance. I claimed that this performance increase is greater than would be achieved just through upgrading to a dual-core Windows Vista system. Here's why I make that claim ...

First, the availability of two CPUs for "hyper-threading" is not going to even double computational throughput or scenery cache throughput. FSX's use of the second CPU to prefetch scenery data will help, but it won't make the world safe for flight simmers. I will guess that a sixty to seventy percent performance increase could be attributed to dual-core hardware, but not more than that. Windows Vista probably will be required if even those results are to be achieved.

Second, Vista is not going to make hard drives seek faster or spin faster. Vista may incorporate an improved file caching scheme, and if so this should reduce somewhat the overall frequency of hard drive read/write head positioner strokes involved in running FSX, but I'll guess that at most a ten percent improvement can be hoped for here, because the main issue is the time spent in indexes and not the time spent actually accessing the files pointed to by the indexes.

Ignoring the issue of DirectX 10, dual-core Vista systems therefore might provide a seventy-five percent increase throughput, but we can already do better than that just through optimization of the on-disk file structures as earlier discussed. Of course in the future we will be able to take both steps, and if we do so it is likely that excellent performance will be achievable by a year from now on what will have become the new typical computers. Things will get even better when all of the DirectX 10 software and hardware issues have been sorted out, and when DirectX 10 hardware prices come down.

All of the FSX unpleasantness will be over in a couple of years but at present the situation is painful, especially for the many users who bought new computers only to find that they had been better off with FS2004. I hope this article will have helped you folks salvage your investments.

First, the new defragmentation and file layout procedures of course benefitted not only FSX but also FS2004. My office machine is now able to run FS2004 with all sliders to the right, with no stuttering whatsoever. The resulting visuals are as good as they ever get in FS2004, in some respects better than my FSX visuals, because I can't usefully push all of the FSX sliders all the way to the right.

Second, with no edits to the [main] section of the fsx.cfg file, FSX will be operating in full-screen mode with the menu bar toggled via the alt key, but with the task bar not displayable at all. If you want to make both the menu bar and task bar visible at all times you must edit the [main] section so that it (nonsensically) reads.

Anyway, in my opinion, when it comes to Microsoft's list of hardware prerequisites for FSX, truth most definitely is out of style.

Earlier I said "with my own product running in the background." I'm perhaps a year away from formal announcement of the product but I want to get the names of the product versions out in public to establish the trademarks and to generate some early share of mind.

The FS version of the product will be called "AirBoss™". A somewhat different version, usable with certain Windows-based games such as Half-Life, will be called "GameBoss™". Both products represent a new approach to the human interface of Windows-based games. The trademarks are owned by PC Game Controls, LLC (TM), which will publish the products.

I will have more to say about the products in an upcoming series, "The Making Of AirBoss." The official announcement will be made exclusively here on FlightSim.Com, and the AirBoss version will be available only through the Pilot Shop.

Mike McCarthy
xxmikexx@qwest.net

Discuss This in our Outer Marker (Feedback) Forum.