Texture loading + SSD vs HDD

[SAAB340 28]

It all started with me wanting to investigate how using an SSD instead of a regular HDD affects performance in FSX. But during the course I ended up looking in to a lot more as well.

 

Please see Kostas Software and hardware guide for different abbreviations and terms used and a bit more details about them.

 

I divide FSX performance in to 4 difference categories, in no particular importance:

Texture loading

Load times

FPS

Stutters

 

Please feel free do skip forward and just read the recap at the bottom of the post if you are not too bothered about how I got to my findings.

 

Load times are easy to measure with a stopwatch, FPS and stutters can be analyzed using FRAPS. Previously I’ve had quite poor methods of measuring texture loading and my stutter analyzing needed a bit of refining as well.

 

I knew I had to come up with a more accurate way of measuring texture loading inside FSX in order to properly analyze the impact of different storage. Eventually I came up with an idea that worked. To do it I’m using Hi-Res photo scenery (Horizon VFR Photographic Scenery, GenerationX, Vol. 4, Scotland: The Western Isles), my programmable Thrustmaster HOTAS Cougar joystick and a stopwatch. By using photo scenery I get no autogen blocking the ground textures from view and loads of Hi-Res ground textures that needs to be decompressed by FSX.

 

The test uses the F18 Hornet you get with Acceleration and it loads a paused flight, overhead Stornoway airfield (EGPO) at 2638 feet. With some programming of the joystick I can, with the press of one button, initiate commands that will rapidly (at the maximum slew speed of 40 000 knots) slew the aircraft away stopping it at around 4mile final to RWY 24 in Benbecula (EGPL) about 50miles away. At that point the textures are blurry. The programming of the joystick has been done so the slew is stopped 7 seconds after the button is pressed. With the flight still paused it’s just to sit and watch the texture tiles getting sharper. And by timing with a stopwatch from when the button is pressed and subtract 7 seconds I can measure how long the texture loading takes. I’m timing when a particular sandbank on the right side is fully sharpened.

 

Sharpening of the texture tiles happens in stages. From 2638 feet I can see 7 texture sharpenings but only the texture tiles closest will get the highest detailed textures. The LOD_RADIUS setting under [TERRAIN] in the cfg decides how close we will get detailed textures. The maximum LOD value we can set with the sliders within FSX is 4.500000. But even on a fully loaded scene at this setting, textures not too far away are still looking blurry on a high resolution display. What we can do is manually enter a higher value in the cfg, but it will revert back to 4.5 if we change any settings inside FSX. Having autogen is a good way to block out the blurry textures in the distance but when we use photo scenery that has no autogen we can easily see the improvement in getting sharper textures further away. I have tested using LOD of 4.5, 6.5 and 9.

 

The LOD will affect textures quite far away. When setting 6.5 or 9 during the texture loading test, the blurriest texture we start with is actually the texture we get after one sharpening at the 4.5 setting. We also get a further sharpening of the closest textures that we never see with the 4.5 setting. I don’t know how for sure how many stages of texture sharpening that actually exist, we might get even further sharpnings closer to the ground. I believe the blurriest texture we get at the 4.5 setting is as blurry as it gets. Using that blurry texture as stage 1 it’s the transition between stage 5 and 6 that is most apparent from 2638 feet with stage 5 looking blurred and stage 6 detailed. It’s only when you see stage 7 and 8 that you realize it can get even more detailed.

 

Load times are measured with a stopwatch from when “FLY NOW!” is pressed until the terrain is displayed outside the cockpit window. Hardly sophisticated but it works fine. I timed how long it takes to load the texture load test.

 

I have also developed a way to give an actual value to stutters described as average stutters/minute. To quickly compare different settings it is important with a single number. I get this value by analyzing every individual frame time given by FRAPS. If a flight is stutter free it means that every frame takes (almost) the same time to be displayed. It doesn’t matter how high or low the FPS is as long as every frame is displayed at a regular interval. If one frame takes a lot longer or shorter to display than the others this will be perceived as a stutter.

 

This is not to be confused with the slideshow feeling a low (stutter free) FPS gives. You will see the difference between a steady 20, 30 and 60 FPS. It’s just not stutters.

 

FRAPS will tell us how long time after the first frame each frame is displayed. By processing this in Excel we can find out how long time each individual frame took, but more importantly we can also see how much faster or slower each frame was compared to the next. That’s the important bit. If it’s smooth it won’t differ by much. If we have a stutter there will be a big difference.

 

For example at a constant 30FPS each frame takes 33.3333ms to display.

The values derived from the FRAPS time would than be:

 

Frame Time (ms) FrameTime Stutter

1 0

2 33.333 33.333 0.001

3 66.667 33.334 -0.001

4 100.000 33.333 0

5 133.333 33.333 0

6 166.667 33.334 0.001

7 200.000 33.333

 

As you can see the individual FrameTimes only differ with 0.001ms here so there is no stuttering going on at all.

 

If we throw in one single stutter by having one frame rendered only at 23FPS (43.4782ms) as frame number 5 this happens.

Frame Time (ms) FrameTime Stutter

1 0

2 33.333 33.333 0.001

3 66.667 33.334 -0.001

4 100.000 33.333 10.145

5 143.478 43.478 -10.145

6 176.811 33.333 0

7 210.144 33.333

 

You can see that in the stutters column we can see two big recorded numbers. 10.145 and -10.145. One actual stutter generates two big entries, one positive and one negative.

 

I have decided to show a value using “number of stutters >10ms per minute” as the unit. That means that every frame that takes more than 10ms, that’s 1 hundred of a second, longer or shorter than the next one is logged as a stutter. The stutter value doesn’t take into account how much over 10ms the stutter is, just that it’s more.

 

To get the FPS and stutter results I use FRAPS on a 2.5 minute flight where I un-pause the F18 Hornet used in the texture loading test overhead Stornoway, climbing it up to 2700feet and turning to a heading of 230 degrees while flying at MACH 0.8 over the photo scenery. So these values are not taken during the same time/flight as I time the texture loading and load time. It is two separate flights. But I found it important to show the results tied together.

 

These tests have been conducted with this hardware:

Intel i7 860 Lynnfield CPU @ 3.82GHz BCLK 191, Multiple 20

A Point of View GTX470 GPU @ stock speeds on x16 PCIe 2.0 bus

8GB GeiL Ultra RAM @ 1528MHz 7-7-7-24 2T

EVGA P55 FTW motherboard

Intel X25-M G2 160GB SSD used for both the OS and FSX.

 

Software used:

Windows 7 Ultimate 64bit

FSX with Acceleration

Horizon VFR Photographic Scenery, GenerationX, Vol. 4, Scotland: The Western Isles

Scotflight for FSX photo V2.1

nVidia 285.62 driver

nVidia Inspector 1.9.6.5

 

The tests have been conducted using these settings:

 

 

I use an unmodified .cfg adding only the BP=0, different Affinity masks, FFTFs, modifying to WideViewAspect=True and using different LOD_RADIUS. I have disabled Cores and Hyper Treading in BIOS as appropriate to test different CPU configurations and tested x8 PCIe bus speeds by taping over connectors on the GPU.

 

Before we move on lets go through the 3 main “parts” of the FSX code.

Main-thread

Texture and terrain loaders (T&t loaders)

Other-threads, (previously called fibers by myself and others incorrectly)

 

The main-thread is what is creating the FPS. So to keep the FPS as high as possible it needs to have its own dedicated CPU core to itself, not sharing it with anything.

 

I’ve described the different parts earlier here. There I refer to the “other-threads” as fibers.

 

I wasn’t sure if I should continue to use the name “fibers” or not. They technically aren’t fibers, (part of them might be) they are threads. This is what Phil Taylor (he was Graphics and Terrain Program Manager and later Lead Program Manager for the Core team at ACES) says about them when he comments on multi-core usage in FSX pre SP1:

“What we don’t do today is make extensive use of threads across cores during rendering. The threads we do have are scheduled by the OS across cores, but we don’t do that ourselves.

 

So again it is incorrect to state FSX doesn’t use multi-core. It is just a question of how much.”

The important part is that this confirms that where these threads end up is controlled by the Windows, not by FSX itself.

 

The Texture and terrain loaders were introduced with SP1. Adam Szofran (Terrain guru at ACES) released a paper describing the terrain engine in FSX. In it we can read how the terrain engine is run on fibers. These are the actual real fibers. He also says this: "Recognizing the increased availability of dual-core processors, we plan to execute some fibers in a single thread on the second core. Fiber tasks that exchange data only with other fibers on the same core can still lightweight synchronization, but any data exchange with the main game loop or other fibers running on the primary core must be fully synchronized obviously." That’s a T&t loader he is describing. Where they end up can be controlled by FSX using the Affinity Mask tweak. The AM value assigns what CPU cores (or virtual cores if we use Hyper Threading) the Main thread and T&t loaders will be on. FSX will detect your core configuration and set a default value since SP1. The default value is putting the Main thread on the first available core, and a T&t loader on the remaining ones. If HT is activated the default value will put the Main Thread on the first virtual core, and then a T&t loader on the first virtual core of each following physical core. Windows task manager will show this as every other core being used. Remember that the OS will still decide what CPU cores the “other-threads” end up on.

 

The latest update of the FSX code with Acceleration/SP2in October 2007 didn’t change much with regards to multi-core usage. It focused on bug fixes and DX10.

 

I already knew that AM settings and CPU core configuration affects texture loading but I’ve not been able to measure it before. So first of all, let’s have a look at that first before we have a look at how different storage affects FSX performance.

 

This is what the upcoming spreadsheets will display.

Texture loading:

Measured as described above (Average of 3 tests)

 

Load times:

Measured as described above (Average of at least 3 tests)

 

FPS:

Measured with FRAPS (Average of 5 tests)

 

Stutters:

The average number of stutters(>10ms)/minute as described above (Average of 5 tests)

 

Cores:

The number of cores activated in BIOS

 

Threads:

The number of treads available in the OS

 

HT:

Tells if Hyper Threading is activated

 

AffinityMask:

The affinity mask used

 

Assigned cores:

Gives you a picture of how the current affinity mask, core and HT configuration have assigned the cores as it would look like in Windows task manager. The first column to the left is the “Main Thread” and the other columns are “T&t loaders”

 

T&t loaders:

Tells you how many Texture & terrain loaders that have been assigned by the affinity mask

 

Locked @FPS

What the FPS is locked to inside FSX.

 

FFTF:

The used FFTF value

 

LOD:

The used LOD_RADIUS

 

T&t loaders remark:

Give you different remarks and configuration changes

 

 

Let’s start with what I believe most people use with FSX. A quad-core CPU without HT.

 

 

 

Here you can see that having just the main-thread and no texture loader (AM=1) gives you rubbish texture loading. Adding one T&t loader gives you tremendously improved texture loading, not much difference in load times, a good improvement in FPS and a bit less stutters.

 

Adding more T&t loaders give you even better texture loading, better load times but slightly worse FPS while the stutters remain very similar. This is just as Microsoft intended. Here is a quote from Seung-Woo Kim, senior application engineer at Intel, involved in creating SP1 from the earliest days: "There are essentially two ways to use multi-threading for the Flight Simulator. One is to increase the frame rate. Another is to increase the visual quality. Last year, the primary concern at Microsoft was both, but they were more concerned about the visual quality of the software. We decided to use multi-threading to increase the visual quality, instead of increase the frame rate."

More cores don’t equal more FPS, actually the opposite. But that doesn’t mean that FSX doesn’t make use of the extra cores or that multi core is broken in FSX. As you can see, it does just as intended. Improving the texture loading.

You can also see that AM=7, AM=11, AM=13 and AM=14 all yield the same result.

The AM=15 result (default) can however have some other effects with regards to not offloading the other-threads from the Main threads core. This is what can happen if we don’t have a spare core available for the OS to put the other-threads on. Without a spare core Windows have to schedule the other-threads either with the Main thread or with the T&t loaders, or a mixture of both. This can be seen at the worst case result we get when using the 260.99 driver. I say worst case as this doesn’t happen all the time but there is a risk of it happening. The graphics driver seems to be able to influence where the other-threads get scheduled. With the 285.62 driver all 10 benchmarks yielded the same good result. But you’ll see later that this isn’t always the case with this driver either. That’s why AM=14 (7, 11 or 13) is being recommended all the time. You don’t risk a big drop in FPS. You do however loose out on texture loading and load times.

 

Let’s now look at how FSX performs on a single-core with and without Hyper Threading and on a dual-core (without HT). It’s not that I’m saying that a lot of people still use single-core configurations, but more down to that these and the quad-core configuration were the CPU configurations available at the time of the last update of the FSX code. To be true I have to mention that there were actually 3 different Pentium 4 Extreme Edition, priced $999 each, which had Dual Core with Hyper Threading at that time as well. But they were hardly high volume CPUs and none of the planned future CPU architectures were known to be using HT together with multi-core when SP1 was developed.

 

 

 

Here you can see that activating HT on a single-core while still using AM=1 gives a big improvement in texture loading, and an improvement in stutters. While FPS and load times only get a very minor improvement. If you look in Windows task manager you won’t see much activity on the hyperthreaded second thread. So it’s not that all the other-threads get offloaded here. It’s most likely the fact that Windows can schedule and process threads that only needs a short time on the CPU on the second thread without having to interrupt the Main thread that gives the performance boost.

 

Putting a T&t loader on the hyperthreaded thread with AM=3 is fully possible and you can see this in task manager as well. It does indeed improve on texture loading a lot, but at the huge expense of load times, FPS and stutters. No wonder Phil Taylor said this with regards to Hyper Threading and SP1. “Note - hyperthreaded is not multi-core. Our current plan is to treat HT machines as single-core since we noticed extensive collisions between threads which caused stutters.”

It is fully understandable that the default AM for a single-core with HT is AM=1.

 

If we instead use a dual-core CPU with AM=1 you can see that having an extra real core instead of a hyperthreaded one does yield a slight improvement in texture loading, a very slight improvement in load time, a lot more FPS and similar stutters. Here the other-threads get offloaded from the Main threads CPU core.

Using AM=3 on a dual-core yields a lot better texture loading, a slight improvement in load times and possibly better FPS. I have two results again.

Same again, it’s understandable that the default AM we get for a dual core is AM=3.

But you can see that I have a worst case result for AM=3. This is once again down to where the OS schedules the other-threads. This time in 7 cases out of 10 they were scheduled on the core that has the T&t loader. In the other 3 cases they ended up on the same core as the Main thread reducing FPS giving us the worst case result.

When comparing a dual-core with 1 T&t loader (AM=3) with a quad-core with 1 T&t loader (AM=5) you’ll see that we get similar load times and stutters but the quad-core yields slightly better texture loading. The FPS is the same as for the dual-core best case scenario with the difference being that we always get better FPS as we’ll always get the other-threads offloaded.

 

Let us now move on to dual-core with Hyper Threading.

This configuration became mainstream on the desktop with the launch of the Core i3 Arrandale in January 2010. One year after the closure of ACES studious, so don’t expect any optimal default AM settings for this configuration.

 

 

 

Here you can once again see the effect you get on the stutters if you hyperthread a texture loader together with the main-thread (AM=3, AM=11 and AM=15). Phil Taylors words regarding HT and stutters still applies even thou he was saying “… treat HT machines as single-core…”, notice the word single-core. He is talking about the single core Pentium 4 HT, not a modern dual-core or quad-core with HT. Look at the results for AM=13. Here we hyperthread two T&t loaders on one physical core. The other-threads end up on the vacant CPU thread that also shares resources with the main-thread. Compared to the worst case dual-core AM=3 (where we don’t have other-threads offloading either) we get a good improvement in texture loading, similar load times and stutters for the same FPS.

 

What is interesting to look at is how AM=5 (default) and AM=9 differs. AM=5 produces a very irregular FPS. It varies between the worst- and best- case result for the dual-core non-HT AM=3. Looking at the Windows task manager we can see that Windows 7 constantly shifts where the other-threads are scheduled. It splits the load between the vacant thread sharing a physical core with the Main-thread, and the vacant thread sharing with the T&t loader. Sometimes all other-threads end up sharing the resources with the Main-thread killing FPS, and sometimes they all end up sharing resources with the T&t loader instead. However with AM=9 the other-threads pretty much always seems to end up on the same physical core as the T&t loader yielding the best FPS.

I would recommend AM=9 on a dual-core with HT. If texture loading is very important AM=13 is also an option but it will cost you a lot of FPS as we don’t get the other-threads offloaded.

Windows 7 has a tendency to schedule the other-threads on the “first” of the two virtual cores that HT splits one physical CPU core into. If all these “first” virtual cores are occupied the other-threads seems to be scheduled all over the place.

 

This pattern is repeated when we look at quad-core with HT. First made available with Bloomfield in November 2008, only a few weeks before the closure of ACES studious, so don’t expect any optimized AM settings for this configuration either.

 

 

 

As seen before the texture loading improves when we add more texture loaders. Even hyperthreaded T&t loaders help with texture loading. Load time also improves with more T&t loaders but here it’s the number of actual physical cores used by the T&t loaders that gives the best improvements. HT only helps a little. When it comes to FPS you can see that more texture loading also costs a little FPS. With any AM setting that leaves a whole physical core vacant (that is two threads sharing one actual physical core) the FPS remains the same (almost) every benchmark run. That is because the other-threads get offloaded here. When we don’t (AM=85 default, AM=89, AM=121 and AM=249) FPS has a tendency to vary quite a bit between and during benchmarks as the other-threads sometimes end up sharing resources with the Main-thread. Out of these 4 AM entries AM=249 gives us a good result most of the time. The default AM=85 is clearly not the best one.

Having HT activated always exposes a virtual thread to the OS that is sharing resources with FSX Main thread. Therefore there is always a risk that the OS will schedule processes that aren’t necessary related to FSX there as well. Windows search indexer comes to mind, make sure it is off. If that happens, it will have a negative impact on FSX performance. That’s a risk we always take having HT activated.

AM=253 leaves only the thread next to the Main-thread vacant and all the other-threads gets scheduled there at the expense of a constant lower FPS. As we can see the improvement in texture loading is very minor so it’s not worth it.

Finally AM=255 once again show us that hyperthreading a T&t loader with the Main thread induces stutters and cost a lot of FPS. It does gives better FPS than dual-core AM=15. That’s since the light refresh when the T&t loader shoots up to 100% goes a lot quicker having 7 instead of 3 T&t loaders. It still kills FPS and gives you stutters so stay away from it.

When comparing quad-core with HT AM=49 with dual-core with HT AM=13 we can see that offloading the other-threads from the Main thread gives us slightly better texture loading as well as better FPS.

If you compare the quad-core HT vs non HT results you see that they are very much the same as long as we have other-thread offloading and use the same amount of physical cores and T&t loaders.

So the default AM=85 does have its downsides, my recommendation is to use AM=241 (or 244) on a quad core-with HT. It gives you slightly better texture loading than quad-core AM=15, similar FPS and only slightly slower load time. What you also get is other-thread offloading. If you are particularly keen on texture loading and load time I would recommend AM=249. AM=84 is also an option if FPS is of most importance, at the cost of texture loading and load times but it gives you the same result as quad-core without HT AM=14 (or 13).

 

Here is a spreadsheet showing all the results together.

 

 

 

We can clearly see how more T&t loaders clearly improve on texture loading, even by using HT, and that load times improve mostly by adding another T&t loader on a further physical core, and only a little by hyperthreading two T&t loaders together. I would expect this to continue with hexa- and octa-cores.

 

Let’s now see what happens when we increase the LOD_RADIUS in the cfg and also what happens when we lock the FPS within FSX. I’ll also throw in the effects we get by removing the BP=0 tweak or replacing it by the Reject Threshold tweak instead and also what happens if we half the CPU speed.

 

 

 

Don’t get distracted by any of the stutter values. We’ll look in to them in greater detail in a minute.

 

First of all, removing BP=0 is bad for Texture loading, FPS and stutters. Using the Reject Threshold tweak instead of BP=0 doesn’t help. Compared to having no BP=0 entry, Reject Threshold only yields a tiny FPS improvement. I know the effects can be bigger with a lot of autogen, but here it is almost useless while BP=0 is giving very notable effects.

 

Higher LOD equals longer texture loading and load times, and lower FPS.

 

Locking the frames shaves off around 2 seconds from the load time across the board otherwise load times stay the same for each LOD setting. I don’t have it recorded but I recall seeing around 4s improvement at half the CPU speed, so it is a few CPU cycles we save.

 

Texture loading improves by locking the FPS within FSX. If we set a value we can’t maintain (99) the average FPS we archive is lower than what we get running unlimited, but instead we get better texture loading. Texture loading improves further if we set a value we can maintain with a good margin (30). The higher the LOD we have, the better improvement in texture loading we get by locking the frames. Texture loading is once again shown to cost FPS.

 

Texture loading, load time and FPS also scale very well with CPU clock. We are seeing close to 100% improvement for a 100% speed increase.

 

We have already seen that a higher LOD is making texture loading and load times taking a lot longer. We are loading a lot more high resolution textures, so it’s no surprise. You’ll hardly notice that if you fly slowly. All you’ll notice is that you are surrounded by nice crisp textures. But you’ll notice it when you start going faster. We might not be able to load the highest resolution textures in time. So let’s see how a few AM settings affect the texture loading at LOD 9.

 

 

 

Here you can see that I have two values for AM=15 (default) on a quad core. As the T&t loaders now work a lot harder and we have no vacant core it means that it is a higher possibility that the other-threads gets scheduled together with the main thread, reducing FPS. Only 12 out of 20 cases gave the best case scenario.

As you can see I have included a worst case scenario for AM=249 as well. Here 9 out of 12 cases gave the best case scenario. The result is still better than for AM=15.

More T&t loaders, hyperthreaded or not, still gives us better texture loading. And load times still primarily improves by adding T&t loaders on further physical cores and only a little by the use of HT. If you use an overclocked system activating HT will most likely force you to back off a bit on the overclock. In my case I can get a 5% higher overclock without HT. And this will affect as well. We know that texture loading, load times and FPS scale very well so I can expect 5% faster texture loading, load times and FPS on the numbers where HT is off on my processor. But even with this taken in to account the texture loading we get with the use of HT is still much faster, while the advantage on load times is smaller but still there. When it comes to FPS however we clearly get the highest by keeping HT off. It’s already higher at the same clock speed and it will only get higher when we increase it. (AM=241 is the HT equivalent of AM=13 and AM=249 is the HT equivalent of AM=15.)

 

Now back to the stutters. Remember, the value I give you just tells if a stutter is over 10ms. Not by how much. A single 20ms stutter will be a lot more noticeable than a 11ms one. And a 10ms stutter won’t be much less noticeable than a 10.1ms one, but it wont be logged at all. Thankfully I have a lot more information regarding the stutters on my benchmark spreadsheets. I have one spreadsheet for each setting/configuration. This is what part of two pages (AM=13, NoBP=0 entry LOD4.5 to the left, LOD9.0 to the right) looks like.

 

 

 

At the top I have a few different stutter values entered.

I have a graph plotting the average 50 hardest stutters.

A graph plotting where the stutters occur, and how big they are during benchmark Run 1.

Underneath you can see a graph plotting the FPS during the benchmarks.

 

Do you notice the drop in the FPS graph that happens regularly roughly every 15 seconds? It also happens to have the hardest stutters associated with it. If we were to fly the benchmark slower the FPS drop will come at longer intervals. The FPS drop and associated hard stutter always happens as we pass the same place over the ground. The drop in FPS is also maintained for a longer time if we have a higher LOD. It also happens to be where we very rarely can see a small crack line in the terrain. The associated stutter is also largely reduced if we put in BP=0 in the cfg.

 

 

 

What is happening?

Adam gives a good clue in his terrain paper: "Since the rendering pipeline (Direct3D in this case) uses 32-bit floats, the final coordinates used for rendering must be converted to 32-bit offsets from a 64-bit local origin no more than several thousand meters away... ...As the viewpoint moves through the world, the local origin must be periodically updated to keep it within a few kilometers of the viewpoint. Otherwise, a loss of precision results making the terrain vertices appear to wiggle around as the viewpoint moves, an interesting but obviously undesirable outcome. Whenever we update the local origin, all the vertex buffers in every cell of the quad tree must be recomputed relative to the new origin. As this can take several frames, the new vertex data is double buffered and then made active only when all are ready to avoid visible cracks."

Its FSX terrain engine at work recalculating the vertex buffers. The 3 factors that have a big effect on this vertex update stutter, the most noticeable and longest of all stutters, are BP=0, LOD value and CPU speed. A faster CPU reduces this stutter.

 

Between these vertex macro stutters, we have a sort of micro stuttering going on. Running unlimited or locked at a value we can’t maintain, most of these stutters are staying under 7ms increasing only slightly with the LOD setting. CPU speed this time has a more notable impact. BP=0 helps reducing these stutters slightly. It’s helping the most at higher LOD settings.

 

Finally, having the FPS maintained by the FPS lock in FSX is causing these micro stutters to be a lot harder. All of a sudden while the majority of these micro stutters are staying under 10ms quite a lot of them go to almost 15ms. This is clearly visible. It doesn’t matter what FPS that is set. As long as FSX is maintaining it, you get visible ongoing micro stuttering.

 

Adam explained in his paper that the terrain engine is running on fibers. Given that we can put in an FFTF value in the cfg and tweak it, shall we find out what it actually happens when we change it? First of all, let’s see what Adam has to say about FFTF: "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."

and

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

Let me first show you this graph showing the FPS plotted for a few benchmarks.

 

 

 

Here you can see that a high FFTF while having the FPS in FSX set to unlimited does make the FPS drop associated with the vertex buffer update a lot bigger, but also that it doesn’t last as long. You can also see how the vertex buffer update takes longer when we have a slower CPU.

When having the FPS locked we don’t get these FPS drops, instead FPS remains constantly low. The FPS we get when the vertex buffers are getting updated is the similar no matter if we are running unlimited or locked. The associated vertex stutter remains the same regardless of FPS lock or FFTF setting. This happens at all FFTF values I’ve tested. It looks like in unlimited mode FSX will allow CPU time for fibers on the main thread up to the FFTF value, just as Adam said. While if we have the FPS locked it behaves differently as it always reserves CPU time for fibers dictated by the FFTF value.

 

 

 

Here we have different FFTF values at the 3 different scenarios. Unlimited, Locked FPS we can’t maintain and Locked FPS that can be maintained.

 

Scenario 1. Unlimited

Reducing FFTF from the default value 0.33 does yield better FPS but texture loading is rapidly decreasing. Upping the FFTF is initially giving us better texture loading for a small decrease in average FPS but look at the stutters. They increase rapidly. It’s the micro stutters that occur between the vertex stutters that increase. The amount of time the Main-thread have to give up to fibers constantly change resulting in a big difference in time between individual frames. It’s not too bad at the default value of 0.33, but anything higher starts to look stuttery.

 

Scenario 2. Locked FPS we can’t maintain (99)

A similar story that lower FFTF gives a lot worse texture loading but better FPS. Having CPU time for fibers always reserved, instead of “on demand” as with the unlimited setting, yields better texture loading to start with. Upping the value gives us better texture loading up to a value of 0.67, after that there is no improvement in texture loading but the FPS keeps dropping. So going past 0.67 is not desirable. This best obtainable texture loading also happens to be the texture loading we get in the 3dr scenario.

Using an increased FFTF value improves slightly on the micro stutters up to 0.67. Dropping the value from 0.33 is actually also slightly reducing the micro stutters, probably as the blurred terrain give us less data to work with.

 

Scenario 3. Locked FPS that can be maintained

As you can see, as long as the FPS can be maintained with a good margin, Texture loading is as good as it can be. It doesn’t matter what FPS or FFTF value that is set. In this case you can even set FFTF=0 and still have texture loading. What happens is that the Main thread has way more CPU time than it actually needs. So we don’t need to reserve any with the FFTF, it’s there anyway.

It’s when we get close to the FPS we could possible maintain that FFTF is starting to make a difference. We end up in a transition between Scenario 2 and 3. By using a lower FFTF value we reserve less CPU time for fibers so the Main-thread can keep the FPS at its locked value. But less time for fibers also means less texture loading. When FSX can’t maintain the locked FPS any more the associated micro stutters disappear and we end up with micro stuttering as in scenario 2.

 

So to maximise texture loading we can either lock the FPS to a value that we can easily maintain. Or we set any FPS target with a FFTF of 0.67. It’s a shame that we get those stutters when we have FSX to maintain the FPS. Otherwise this setting would be a really good solution as when the scenery isn’t too demanding we’ll get full texture loading no matter what the FFTF setting is. And if we set a lower FFTF we can maintain the locked FPS longer when the scene is demanding (at the cost of texture loading).

 

However, I guess some of you might have already figured this one out, we can work around these stutters by capping the FPS externally. V-sync is a great way to both cap FPS and remove tearing the same time.

Regular V-sync will cap at the screen refresh rate (normally 60FPS), but it is not usual to be able to maintain such high locked FPS in FSX. Half the refresh rate (30FPS) is a more reasonable FPS to aim for.

 

So when we use the half refresh rate V-sync available with nVidia inspector and the 301.42 driver and at the same time lock the frames within FSX to the same FPS we get really smooth flying, no tearing and full texture loading as long as we easily can keep the FPS at the same time. Triple whammy. No wonder this is what people have been doing for a while now.

 

 

 

Here you can see that forcing fullscreen V-sync in FSX cfg adds about 2 seconds to the load time.

When analyzing the stutters however, this is the only time I have not fully been able to understand why I get a certain result. Because if we look at the stutters value (or graph) we don’t see as much of an improvement as were really getting. The actual display is now butter-smooth, apart from the odd stutter when we have the vertex update. The micro stuttering is gone. This lack of micro stuttering probably has to do with that were now always feeding frames to the display at a constant rate of half it’s native refresh rate, so as long as it gets a new frame within 1000/30=33.333ms we won’t see any stutter at all on the display.

The butter smooth flight disappears as soon as the FPS goes below the value V-sync caps at and we are then faced with the second best experience when it comes to stutters. A locked FPS that we can’t maintain. It is actually not that bad, but you’ll clearly see the difference.

 

It is also possible to use 1/3^rd of the refresh rate and lock the FPS to 20 within FSX. That will also give you stutter free flying. However 20 FPS, even thou it is stutter free, is looking very much like a slide show if we have fast movement across the screen for example when you look out the side window.

 

As I’ve said, I don’t fully understand why my stutter value doesn’t agree with reality in this case, but if we were to lock the FPS to a value slightly above half refresh rate (33) the stutter value improves significantly (it still looks the same stutter wise on the display). But we also get worse texture loading, and texture loading is now always affected by the FFTF value. So limiting the FPS externally, that is what V-sync is doing, is giving us worse texture loading. You can see the worse texture loading at the Unlimited and Locked @ 99 numbers as well. You can also see that I have tested with my old trusted 8800GTS 512. And it is pretty much able to keep up with the maximum texture loading we get in the ½ refresh rate V-sync scenario.

 

 

 

If we look at the 8800 results here when we are running unlimited we can see that texture loading gets worse when we are really limited by the graphics card as well. We already know that the 8800GTS is able to keep up with a lot faster texture loading. Downclocking the 8800 doesn’t do texture loading any good either. The GTX470 on the other hand does affect the FPS slightly if we over- or under-clock it, but not by much. And texture loading remains pretty much the same.

 

It is the same when we use a x8 PCIe bus. We get only a minor decrease in FPS and similar texture loading, load times and stutters. The PCIe bus is not particularly saturated in this case when we don’t have a lot of autogen.

 

Using slower RAM only has an effect on FPS. It’s also not that much, but its there.

 

You can also once again see how taking away BP=0 has an effect in these new scenarios, slow CPU or faster texture loading. In line with what has been said before.

 

Let us now move on to what I set out to look at, SSD vs HDD.

The spreadsheet below looks the same as the previous ones but it has one important difference. The FPS and Stutters values are now derived from a 10.5 minute flight using the FSmark07 flight path.

All the previous results have been collected using what I call a “hot” system. “Hot” means that the computer has been booted, FSX loaded, the flight carried out followed by a full exit out of FSX. Windows 7 at this moment still keep a lot of data from the flight cached in the RAM ready to be used if we fire up FSX again. Any data in the GPUs memory will have been cleared.

Here I also have a “cold” case. That means that the computer has just been booted up having fully finished loading just before FSX is started.

There is also a “Superfetch” case. Superfetch was introduces with Vista and refined slightly with Windows 7. Superfetch basically monitors your user habits and tries to make use of the RAM in your system by caching data it believes you will be using. In Windows 7 superfetch starts collecting data a few minutes after the system has been booted up. Without it having any history of your usage it can’t do anything but if you for example do the same thing after starting up your computer it will soon learn to cache this data after you have done it a couple of times. Superfetch is automatically active for a HDD, but deactivated for a SSD. In this case the computer has been booted up and left idle until superfetch has finished caching its data.

 

 

 

I learned early on that there is a notable difference in load time between a “hot” and “cold” system. As you can see, in the case of a slow HDD this can be more than 3 times longer while the SSD just needs 2 extra seconds when we have a cold system. Texture loading also suffers on a cold slow HDD system while the SSD give the same texture loading regardless if the system is hot or cold. After superfetch has kicked in the slow HDD shows very improved load times and the same texture loading as on a hot system.

It doesn’t matter if we have a HDD or a SSD when the system is hot. The numbers are the same.

Adding more texture loaders on a cold slow HDD does give you a small improvement in texture loading and load time but not close to the improvement you get with a hot system or with an SSD.

If we compare the FPS and stutters for the cold slow HDD with the cold SSD you’ll see that the FPS is pretty much the same (if we were to add a decimal point the SSD result is 42.0 when the slow HDD is 41.5) while we get slightly more stutters with the slow HDD.

 

If we instead look at how long time it takes to launch the actual FSX program we see a similar picture. The average time to launch FSX on the cold slow HDD is 40 seconds. If we launch it just before Windows has finished loading we have to add another half a minute on the cold results. If we have a hot system it launches in only 6 seconds. That’s more than 6 times faster. After superfetch has done its caching it launches in only 7 seconds. That’s almost as fast as in the hot case.

The SSD installation has a lot more FSX things installed on it so it takes a lot longer to launch FSX but there is still a notable difference between a hot and a cold launch. The hot launch takes 20 seconds while the cold case takes 29 seconds. Not even nearly as extreme improvements as with the slow HDD. The SSD also doesn’t show the severely increased launch time if Windows hasn’t fully finished loading when we launch it. I will probably do a clean install later and see if the hot numbers are the same as for the slow HDD with the same things installed.

 

All this is fairly logical if we think about it. Think of your own FSX installation. It is likely tens- if not hundreds- of GB in size. To read this data will take time. A SSD is able to give you a lot faster read transfer rates than a HDD. A lot of the data from your FSX installation that you will be using is red upon loading the flight. During the flight it’s mostly terrain and texture data that will be loaded from your storage. Terrain and texture data will be a huge chunk of your FSX installation.

If most data we will use is already cached in the RAM there is hardly a surprise that we get the same result no matter how fast or slow the storage is. This is what happens when we loop the same benchmark over and over again. In real usage however you won’t be able to have all the texture and terrain data cached in the RAM, so your storage will matter. If you have a slower HDD and normally fly the same planes superfetch should be able to mitigate a lot of the load time penalty for slower storage. But it won’t be able to help with the texture and terrain loading unless you have a very repetitive pattern of where you are flying.

Don’t disable superfeth if you have a HDD. It does work as it should.

 

Thankfully FSX has been made to work fine with slow storage. The high speed consumer storage available today wasn’t available when FSX was developed so the speed of your storage won’t affect your FPS much at all. Stutters will however be slightly affected. The cold slow HDD will give you notable harder stutters at times. On my 10.5 minute test flight there is only one very noticeable stutter difference between the SSD and the slow HDD. When passing over the Seattle Tacoma airfield the cold slow HDD give you one stutter that is on average 417ms long. That is more than 0.4 seconds! It obviously shows in the min FPS value as well as only 1 frame is rendered during almost half of that second. The same stutter on the SSD is also the hardest, but it’s “only” 85ms. You’ll see that stutter as well, but it’s quick enough so you won’t have time to start thinking of what is actually happening. Micro stutters are the same regardless of your storage.

I’m not saying that we should all go out and buy expensive SSDs to put our FSX installation on. What I’m saying is that storage has the potential to affect texture loading, load times and stutters a lot. The HDD I’ve been using is a 2,5” 80GB Toshiba notebook drive. That’s a slow HDD compared with what you can get today. The Intel X25-M G2 is by all means not a particularly fast SSD anymore but it’s a lot faster than the Toshiba HDD. These are the transfer rates measured with ATTO.

 

 

 

The SSD is showing around 10 times faster transfer rates across the board. We don’t get that much improvement with the SSD compared to the slow HDD. We are clearly removing a bottleneck putting the CPU back as the limiting factor. The SDD might be a lot faster than what we actually need. You might also have noticed that I had transfer rates for a 3^rd storage device in my ATTO numbers. The WD Velociraptor 1TB that became available not too long ago that is the fastest conventional HDD around right now. The plan was to have results from the Velociraptor included, but Windows 7 pre SP1 needed additional drivers before it was happy to be installed on it causing a bit of head scratching, swearing and time wasting before it got installed so I ran out of time. I’m working away the next few weeks and will also soon be moving house so I thought I better present my findings now. I plan to update with the Velociraptor results later. What you can see from the ATTO result is that the 1TB Velociraptor is getting very close to the X-25-M G2 read transfer rates. But this is at the fastest outer sectors of the disk. The inner slower sectors will probably lose at least a 3^rd of the speed. But that will still be fast for a HDD.

 

Recap

Apart from showing how FSX can make good use of Hyper Threading I haven’t really shown anything that isn’t already known. I have just provided solid evidence, and sometimes a bit more detail, proving what a lot of people have already been saying.

 

FSX wasn’t designed to give us better FPS with the use of more cores. It was designed to give us better texture loading. And it does just that when we go past three cores. It doesn’t give us better FPS, instead it gives us a slight reduction in FPS as texture loading improves.

We also need storage that won’t bottleneck us. If we use a slow old HDD it can bottleneck our texture loading and load times. In that case we will get a lot better improvement to texture loading and load times by upgrading our storage instead of using more cores/threads for T&t loaders.

 

How fast storage do I need in order for it not to be a bottleneck?

I’m sorry I can’t really tell. A faster CPU will require faster storage not to be bottlenecked. It’s all about having a balanced system. Most likely the latest fast HDDs are enough.

 

But what if I’m happy with the texture loading I have at the moment, do I need to activate HT and/or get faster storage?

No you don’t! The effects of faster texture loading is best seen when using photo scenery or flying without autogen. Especially if you fly fast and at a higher LOD setting. But I would stay away from any slower than 7200rpm drives and any older HDDs with low density platters. (I might have a revised recommendation after I have tested with the Velociraptor, but I much doubt that)

 

Do not disable superfetch in Windows. It can help a lot with hiding the effects of a slower storage. Just as it was designed to do.

 

If you have a system with a dual-core with HT, I would recommend using HT together with AM=9. If texture loading is of most importance AM=13 can be used but you’ll sacrifice a lot of FPS with it.

 

If you have a quad core without HT, I would recommend AM=14 (or 7, 11 or 13) to be used unless texture loading and load times are of the most importance. In that case use the default AM=15.

 

If you have a quad-core system with HT and you have it activated all the time I would recommend AM=241 for every day FSX usage. If FPS is of the most importance use AM=84 and if texture loading and load times are of most importance use AM=249.

 

If you have an overclocked i7 system as I believe many FSX enthusiasts have, I would recommend keeping HT off and keep using AM=14 or equivalent if FPS is of the most importance, like when using complex third party aircrafts. But if texture loading is of most importance lower that overclock enough so you can have HT on, and use AM=249.

 

Never put a T&t loader on the same physical core as the Main thread when you have HT activated. It induces stutters and kills FPS.

 

I would recommend to always make sure you can use the BP=0 tweak. It improves on texture loading, FPS and stutters.

 

I would also recommend locking your FPS to 30 within FSX and having half refresh rate V-sync activated in nVidia inspector. It is important that the FSX frame lock is set to the same value that V-sync is capping at, otherwise we lose texture loading. On top of this I would tweak down the FFTF value if FPS is of most importance. This is to sacrifice texture loading to bee able to keep the locked FPS in demanding scenery. How low to set it? It all depends on how sensitive you are to blurries in demanding scenery and how fast your CPU is. If texture loading is of most importance I would increase the FFTF value to 0.67 and accept the lower FPS and micro stutters that will show up in demanding scenery.

If your CPU is slow you also have the option to lock the FPS to 20 and use 1/3^rd refresh rate V-sync but this will look more like a slideshow out the side window. It’s either this or you have to accept the micro stutters you get when FSX can’t maintain the 30FPS lock.

 

Having the FPS set to unlimited within FSX is not to recommend apart from when benchmarking. Sure, it will give you the highest FPS, but also slower texture loading and more stutters. The higher, but highly varying FPS, won’t look any better than the constant, stutter free, 30FPS we get with the half refresh rate V-sync.

 

Increasing the LOD will make the vertex stutters bigger. These are the occasional but more noticeable stutters we get every now and again as we fly along. It’s another trade-off we have to make for having high resolution textures and terrain further away from the aircraft. BP=0 helps a lot with reducing these stutters while the Reject Threshold tweak doesn’t. Otherwise it’s only a faster CPU clock that will help reducing these stutters, but it’s only significant CPU speed changes that will be really notable. In order to maintain detailed textures within this bigger radius we also need to have a storage and CPU/AM configuration that is able to keep up with the texture loading, especially when flying fast.

 

Thank you for taking time to read all what I had to say. I hope the information can be as useful for you as it’s been for me.

 

Happy flying

Lars

[Illegitimi non carborundum 4]

Saab

Excellent results nice to see such detailed results. Its good to see frame dwell times recorded as these are much more robust than fps in determining stutter type issues. We need cards that can display frame times of <20ms for 99.99% of the time.

Did you consider using a program like process lasso which can allocate cores ie AM efficiently?

Did you also consider using a command prompt for the affinity mask rather than setting it in the fsx.cfg file - in my case it resulted in better performance and I now use Process Lasso.

I personally don't like task manager for monitoring the various processes and values and I tend to use Process Explorer, Process Monitor, XPERF and VMMAP, all developed for multi core multi threaded pC's, but that is a personal choice.

I'm also not sure of the accuracy of FRAPS and I get worried when I get readings of 2560 when its loading FSX!

Nice to see the tests all in one place.

One las t thing I forgot nobody investigates the impact of the "replay" video option in FSX, I read somewhere that it hogs quite a bit of the available resources and it would be great to disable it to see if performance improves!

Regards

pH

[SAAB340 28]

Hi Peter,

Thanks for the program recommendations. I'll look in to them. I hapily admitt I've never heard of them before.

Cheers

Lars

[mpw8679 428]

Thanks for the good info.

[CFIJose 5,485]

Thanks for the info. I jumped on the BP=0 tweak when it was revealed and bought a gtx 480 right after they were released. Those without a gtx 480 should get a gtx 580 just so that they can experience the BP=0 tweak. As it has been stated a well balanced system is the key to FSX fluidity, but tweaks should never be avoided. They are as necessary as a fast CPU and GPU combo.

[scott967 62]

Good write up. One thing I notice on my system looking at ProcExp with AM14 I have 44 threads in fsx, 4 of these are from FSUIPC. Of the 40 remaining threads, 4 of them do most of the work: one from fsx.exe (main thread), two from api.dll (terrain threads) and one from d3d9.dll. A little bit of time is spent in dsound.dll and dinput8.dll and a couple of others (ntdll.dll), but not too much.

 

scott s.

.

[SAAB340 28]

Of the 40 remaining threads, 4 of them do most of the work: one from fsx.exe (main thread), two from api.dll (terrain threads) and one from d3d9.dll.

Interesting to hear

[dazz 69]

Yes, the load on the texture loaders peak every 61 seconds as the light refresh happens. And in the task manager you can see that the light refresh goes quicker using AM=244 on a quad-core with HT compared to the regular AM=14 quad-core without HT.

Maybe we should continue this discussion in my thread http://forum.avsim.n...ing-ssd-vs-hdd/ instead of hijacking rcichellas thread =)

 

Yeah, sorry about that.

 

Well, I've been doing more tests and I'm happy to say that I clearly got faster texture loading after slewing with HT on and AM=254 (4 T&t loaders) & AM=244 (2 T&t loaders)

With a "standard" config consisting of HT off & AM=14 it takes about 30 secs for textures to get 100% crisp in my particular test scenario

HT on + AM=244, 25 secs

HT on + AM=254, 20 secs

 

I'm not convinced it matters all that much flying at x1 speed with airliners, or low & slow bush flying, but the results are there

[SAAB340 28]

 

 

Yeah, sorry about that.

 

Well, I've been doing more tests and I'm happy to say that I clearly got faster texture loading after slewing with HT on and AM=254 (4 T&t loaders) & AM=244 (2 T&t loaders)

With a "standard" config consisting of HT off & AM=14 it takes about 30 secs for textures to get 100% crisp in my particular test scenario

HT on + AM=244, 25 secs

HT on + AM=254, 20 secs

 

I'm not convinced it matters all that much flying at x1 speed with airliners, or low & slow bush flying, but the results are there

Thank you for verifying my findings Dario.

 

I totally agree with you that for flying airliners it won't matter much. It's better to keep HT off to get a higher overclock. If you fly slow it won't matter much either. Texture loading isn't an issue then.

Where it does matter is flying fast over photo scenery at high LOD.

Or any other time you might see blurry textures.

 

Thanks once again for confirming my findings.

[Ben Cap 89]

 

 

Yeah, sorry about that.

 

Well, I've been doing more tests and I'm happy to say that I clearly got faster texture loading after slewing with HT on and AM=254 (4 T&t loaders) & AM=244 (2 T&t loaders)

With a "standard" config consisting of HT off & AM=14 it takes about 30 secs for textures to get 100% crisp in my particular test scenario

HT on + AM=244, 25 secs

HT on + AM=254, 20 secs

 

I'm not convinced it matters all that much flying at x1 speed with airliners, or low & slow bush flying, but the results are there

 

Interesting findings. This is exactly what Phil Taylor discussed in one of his video interviews. If I correctly remember, he said that FSX can use up to 256 cores for terrain loading or rendering. Thanks so much for your tests Saab and Dario!

[dazz 69]

Thank you for verifying my findings Dario.

 

I totally agree with you that for flying airliners it won't matter much. It's better to keep HT off to get a higher overclock. If you fly slow it won't matter much either. Texture loading isn't an issue then.

Where it does matter is flying fast over photo scenery at high LOD.

Or any other time you might see blurry textures.

 

Thanks once again for confirming my findings.

 

no, thanks to you man

IIRC you also mentioned dual cores could greatly benefit from HT, which makes complete sense to me.

At this point I'm gonna need to reconsider if HT may help quads somehow too. There may be some particularly demanding situation texture-load-wise (maybe with unlimited FPS) where it might help with blurs

 

Interesting findings. This is exactly what Phil Taylor discussed in one of his video interviews. If I correctly remember, he said that FSX can use up to 256 cores for terrain loading or rendering. Thanks so much for your tests Saab and Dario!

 

all credit goes to him of course

[westman 257]

Thank you for verifying my findings Dario.

 

I totally agree with you that for flying airliners it won't matter much. It's better to keep HT off to get a higher overclock. If you fly slow it won't matter much either. Texture loading isn't an issue then.

Where it does matter is flying fast over photo scenery at high LOD.

Or any other time you might see blurry textures.

 

Thanks once again for confirming my findings.

 

Tanks for this, not agree acording overclock SB my temp raise 2C 24/7 @ 5.16 ( the odd freq a max the rams with BLCK )

With HT off max safe 24/7 OC for my chip @5.2 the performance is the same higer ram speed @5.16

 

Hasse

[westman 257]

HT on + AM=254

test @5.1 can push it to 5.2 with 0.05V increase and save temps.

 

[Manny 1,293]

With HT ON, I can see all the cores and the HT part showing activity when flying in FSX. So I would think that HT is dowing something with FSX.

 

BTW..the BP=0 worked great on my old machine. However in my new ivy Bridge build with GTX 670, bp=0 gives me artifacts... white flashes on the ground texture. If I remove the bp=0 the problem seem to have gone... but I haven;t tested this enough as yet.

 

 

MAnny

[SAAB340 28]

I've managed to do a bit of testing with the Velociraptor yesterday.

 

Initial observation are:

It can't keep up with the SSD when it comes to load times on a "cold" system. But it is a lot better than the 4500rpm HDD. Initial numbers indicates around twice as fast as the slow HDD but still 25-50% slower than the SSD.

 

Good news is that it can keep up with the texture loading of the SSD. Even at the fastest texture loading my system is capable of.

 

Stay tuned for more testing and more detailed analysis.