In this article I summarize what we have learned about FSX, and I offer advice about how best to set up FSX in the absence of a 64-bit dual core Windows Vista system. The guidelines I'm about to present actually apply to all versions of FS. However, they are especially important in the case of FSX because of its unusually low "visuals to clutter ratio".

Before I get into the details I should mention that I received an email from a fellow flight simmer who said that one of my earlier FSX articles was too complex. He's partly correct so from now on any technical article that I write will be structured like a business presentation ...

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

Summary

FSX performance will be maximized when Master File Table and FSX scenery index search times are minimized. The way to minimize search times is to use a commercial defragmentation utility such as O&O Defrag to sort the on-disk information by folder/file name. The resulting performance improvement will be greater than can be expected by simply converting from a typical single-core machine of today to a dual-core Windows Vista system, provided that care is taken to "balance" the resulting FSX setup.

To attain FSX Nirvana, here's what to do ...

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.

I do apologize but the information in this section necessarily is complex. I've already told you the solution, sort files and folders by name, but in order to be able apply the solution effectively you need to understand the rationale behind it. There is no Royal Road to understanding this material so read on, and pay attention, because FSX will be giving a quiz.

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.

Now let's consider the issue of stutter headroom in more detail: We can reasonably suppose that scenery objects like buildings take up relatively little space in the scenery cache, far less space than terrain mesh data, for example. Therefore it is reasonable to try pushing the objects detail slider all the way to the right because doing so is unlikely to induce stutter. (But be prepared to back off if on-the-ramp visuals start causing stutter.)

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.

What I've been leading up to is the concept of a balanced system. In FSX terms, such a system is one in which the scenery cache bandwidth matches the CPU rendering bandwidth which, in turn, matches the graphics card bandwidth. If any one component is slower than the others it will limit overall system performance. Conversely, if any one component is faster than the others, its excess bandwidth will be wasted unless we put the excess bandwidth to work in a controlled way.

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.

Here's the resulting FSX performance: an initial scenario load time of 190 seconds. Now, with PageFile.sys and the MFT both defragmented, and with the file system sort-by-name layout described two paragraphs back, the scenario load time is down to 45 seconds. (!)

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 ...

With these settings I had just about saturated my scenery cache, but a check of what happens at 30 fps showed that I still had spare renderer capacity. (The frame rate stayed reasonably constant. Had the CPU or graphics card been overloaded, the frame rate would have dropped.) I then fell back to 10 fps and applied part of the resulting renderer bandwidth surplus to autogen density, which I set to Normal. After that I used up more of the remaining renderer bandwidth surplus with cloud drawing, engaging the Building Storms weather scenario, using Simple Clouds with a cloud drawing distance of 100 miles. (The ability to operate stutter-free in this configuration ensures that, when I encounter weather on actual flights, clouds won't cause any stuttering.)

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

Because of the free trial offers for the UD and O&OD defraggers, you can check out everything I've said in this article without spending any money whatsoever.

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.

Now for some additional closing observations ...

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.

The (sensible) equivalent for FS2004 is

Microsoft says that there is a performance penalty for running with the menu bar and task bar showing, but I didn't observe one. Most likely they're referring to a feature of earlier versions of FS which is unavailable in FSX, at least at present. For example, with FS2004, if you edit [main] so that it reads

you will cause the system to run in a window which is much smaller than full-screen, with the FS menu bar visible. In this situation the 3D-to-2D projection is done entirely by CPU software, with no assistance from the graphics card, and there will indeed be a significant performance reduction. A related truth is that if you open, say, a top-down window, even if you're operating in full-screen mode with full graphics card assistance, that window will be drawn using CPU-only calculations. Here too performance degradation is inevitable, and this too is true for all versions of FSX.

Having opened this article with the beginning verse from Mark Griffin's disturbing cult hip-hop number "Truth Is Out Of Style", it seems appropriate to close with the recording's final verses ...

The lyrics and music are copyright Mark Griffin, 1990. Shirley MacLaine, the actress and New Age guru, happily agreed to appear in the bizarre music video. By the way, Griffin was a classically trained musician (!) who exited the music business after making three rap and hip-hop albums. It is rumored that he has since become a CFI. (!)

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

Now for some shameless self-promotion ...

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