Side by Side video of photo scenery texture loading using HDD Vs SSD

[SAAB340 28]

I've created this video to show the difference in texture loading when you have your photo scenery on a HDD vs a SSD.

 

 

I thought a Side By Side comparison can be a bit easier to put in to context instead of a lot of numbers. I've tested this extensivly before and for more information about where and how this test is carried out please have a look at this thread. There you can also see loads of numbers relevant to other drives. Pretty much all SSDs will perform the same, but any HDD that isn't the Velociraptor will perform even worse.

[Clutch Cargo 384]

Interesting.  On my own tests with my system between a 7200 RPM, 10,000 RPM and a SSD using photoscenery I saw no noticeable difference in load times between the three.  Only when I loaded from an external drive did I see a noticeable difference.   However, I was flying how I typically fly either low and slow or in a tube at about 250 knots. 

[dtmicro 1]

Interesting, I'm restesting this on my i7, let me see if I can replicate (or see what the deal is).

[dtmicro 1]

I tried this just now on my new i7-4790k, and am completely unable to replicate your results. The SSD drive and the HD for me were about the same (Samsung Evo vs. Hitachi or WD Black).

 

How I tested:

 

First Test:

Took two sets of "touching" BGL tiles, first set had 5 tiles per BGL (put that on the SSD drive), second set had 20 tiles per BGL (put that on the HDD). I started FSX from scratch at an aiport about 20 miles away from all tiles (loaded default scenery), and then I put the SIM into 4x mode, and I SLEW'd my way to where the two sets of tiles met. In my case, the tiles loaded at almost exactly the same time.

 

I even gave the SSD an advantage by using smaller sized BGL's (BGL with fewer tiles in them), and still no difference. Just not able to replicate these differences at all.

 

Second Test:

I flew in 4x SLEW speed mode to opposite sides of each set and clocked each load-time of the tiles fully resolving (note that my tiles are marked with text so I could easily tell when it was fully resolved). The load times were still nearly identical even when flying on opposite ends of each BGL set.

[SAAB340 28]

I tried this just now on my new i7-4790k, and am completely unable to replicate your results. The SSD drive and the HD for me were about the same (Samsung Evo vs. Hitachi or WD Black).

 

How I tested:

 

First Test:

Took two sets of "touching" BGL tiles, first set had 5 tiles per BGL (put that on the SSD drive), second set had 20 tiles per BGL (put that on the HDD). I started FSX from scratch at an aiport about 20 miles away from all tiles (loaded default scenery), and then I put the SIM into 4x mode, and I SLEW'd my way to where the two sets of tiles met. In my case, the tiles loaded at almost exactly the same time.

 

I even gave the SSD an advantage by using smaller sized BGL's (BGL with fewer tiles in them), and still no difference. Just not able to replicate these differences at all.

 

Second Test:

I flew in 4x SLEW speed mode to opposite sides of each set and clocked each load-time of the tiles fully resolving (note that my tiles are marked with text so I could easily tell when it was fully resolved). The load times were still nearly identical even when flying on opposite ends of each BGL set.

Did you re-boot the computer between each test?

[dtmicro 1]

Rebooting now, in the meantime, can you look at my config and see if there is anything you see I might could try differently...

 

[JOBSCHEDULER]
AffinityMask=84
[bUFFERPOOLS]
//PoolSize=0
UsePools=0
//Poolsize=8388608
//RejectThreshold=262144
[TERRAIN]
LOD_RADIUS=8.500000
MESH_COMPLEXITY=100
MESH_RESOLUTION=25
TEXTURE_RESOLUTION=29
AUTOGEN_DENSITY=2
DETAIL_TEXTURE=0
WATER_EFFECTS=6
[GRAPHICS]
TEXTURE_MAX_LOAD=4096
ForceFullScreenVSync=1
TextureBandwidthMult=120
SHADER_CACHE_PRIMED=1693500672
NUM_LIGHTS=8
AIRCRAFT_SHADOWS=0
AIRCRAFT_REFLECTIONS=1
COCKPIT_HIGH_LOD=1
LANDING_LIGHTS=0
AC_SELF_SHADOW=0
EFFECTS_QUALITY=2
GROUND_SHADOWS=0
TEXTURE_QUALITY=3
IMAGE_QUALITY=0
See_Self=1
Text_Scroll=1
SHADER_CACHE_PRIMED_10=1693500672
D3D10=0
HIGHMEMFIX=1
[Main]
DisablePreload=1
FIBER_FRAME_TIME_FRACTION=0.66
User Objects=Airplane, Helicopter
SimObjectPaths.0=SimObjects\Airplanes
SimObjectPaths.1=SimObjects\Rotorcraft
SimObjectPaths.2=SimObjects\GroundVehicles
SimObjectPaths.3=SimObjects\Boats
SimObjectPaths.4=SimObjects\Animals
SimObjectPaths.5=SimObjects\Misc
Maximized=2
Location=0,0,1920,1080,\\.\DISPLAY1
HideMenuNormal=1
HideMenuFullscreen=1
ProcSpeed=12647
PerfBucket=7
[Display]
TEXTURE_BANDWIDTH_MULT=40
UPPER_FRAMERATE_LIMIT=0
WideViewAspect=True
ChangeTime=4.000000

[SAAB340 28]

Rebooting now, in the meantime, can you look at my config and see if there is anything you see I might could try differently...

 

When testning disc performance you have to reboot between every measurement as Windows will keep the files cached in RAM so they will subsequently be read from there instead of off the disc

[dtmicro 1]

Doing some more testing in a sec, but...

 

Sorry in advance for the long explanation...

 

Only if FSX's caching algorithm is doing it, FSX is written in C++ and Windows isn't going to randomly cache data for it and return it from a cache unless FSX does it that way. FSX is limited to what, 3GB to 4GB... FSX uses low-level C++ pointers and it's own memory management, it isn't relying on Windows that much. These files are also too big for FSX to attempt to cache very many of them (given the app is limited in how much memory it can use, and the default footprint uses a lot of it up already). It's a common misconception that the Windows swap file can cache anything, but there is a whole set of rules and it depends on stack vs. heap and all kinds of junk that is too long to go into here. Large files like this are invalidated quite quickly from the cache.
 

These files are too big to let Windows fully manage them in its own cache, the game would come to a screeching hault and OOM instantly with only 2gb of non-footprint memory. Besides performance reasons and stale pointer references, another reason Windows cannot randomly cache all data is because if using volatile RAM you could be attempting to write something into a non-volatile device or space, and then get stale and corrupt memory in your application, and you would collide with Windows if your app was handling its own CRC and asynch operations or driver stuff (this is just one of many reasons), and all this is espcially true when using C++. It would be impossible to write a driver in C++ if Windows just started caching everything that went in and out of the heap. If it could cache all this stuff, then we wouldn't care about FSX's 4GB limit anymore, it wouldn't matter.

 

If Windows had a "fully working" magic universal cache, then us programmers wouldn't have to spend so much time in apps caching our own data (web apps, windows apps, you name it we all gotta manage our own cache). Most of the things Windows caches are specific to "shared DLL's" and Windows itself, small things from the stack, certain types of heap allocations are cached, but actually Windows has a tendency to cache a bunch of useless data and bloats the swap file unnecessarily believe it or not, that's one reason it was so inefficient compared to Linux BEFORE we suddenly had 8GB+ memory available to us (to catch up to how sloppy WIndows is at managing memory).

[dtmicro 1]

Need to correct one thing:

 

Actually if you just performed the operation and replicate it exactly within a small time frame, it may speed up because of Windows caching the copying process itself, but if you were doing the copy yourself on a memory stream of bunches of large files in code using pointers, it wouldn't be the same as if you just let Windows do the copy. These huge files would be invalidated out of cache very quickly even if they were at some level being managed by Windows.
 

It's very different when in a game though where the game has to manage its own memory.

[SAAB340 28]

Doing some more testing in a sec, but...

 

Sorry in advance for the long explanation...

 

No need to apologize. I enjoy learning about things and I am not a programmer and no expert in Windows memory management.

 

Never the less I have still observed the need to reboot between tests in FSX if you want to specifically target storage performance impact. When you keep the scenery on a regular HDD you can easily hear the disk access during the first test after re-boot, but if you just close down FSX and re-launch it without re-booting and repeat the test you'll also notice the lack noise from the HDD the second time. You can also see that the disk access light rarely comes on as well.  The data is obviously still getting read from somewhere, just not from the disk. Therefore I make the conclusion It has to remain cached in RAM by Windows.

 

In Process Explorer I can see that FSX makes 8881 disk reads during the tested scenario in the video above. If I just restart FSX and do the test again it only makes 202 disk reads for the same test the 2nd time. Even when I left it half an hour and used the computer for regular office work until I restarted FSX and re-run the test it only did 682 reads from disk. I also left it half an hour and let a virus scan run in the meanwhile. That triggered a full read of the files from the disk again. I don't know the technical reason of how, why and when the scenery files get cached in RAM. But they do. So in order to make sure you test the storage you have to reboot.

 

I did previously have another texture loading test using the exact same procedure as in the video above, just over a different photo scenery that is only 8GB in size. During that less strenuous test the Velociraptor and the SSD where about the same. I would guess that's why your test show no difference between them either. It just doesn't place your storage system under as much load as a few MSE states and an Ultra Res City does.

 

I've also done some further testing and excluding the bgl files in the MSE Southern California scenery that are covered in the Ultra Res LA and SanDiego scenery speeds up the texture loading using the Velociraptor quite a bit while it doesn't make much impact on the SSD. The Velociraptor is still quite a bit slower than the SSD still but it does show that its the need for the HDD to move its arms to different places on the disk that is slowing texture loading down. MSE states and Ultra Res Cities are each taking up quite a lot of space on the HDD so the arms of the HDD will have to jump around quite a bit once you've installed a few of them, even when its well defragged.

[dtmicro 1]

I hear you, but there is no point in rebooting every time since the only benefit when flying in FSX is when not rebooted. Hence, we don't reboot every time we load a new tile when in the game, therefore I don't see why conduct a test in a scenario that is not relational to the actual in-game experience.

On my system, I have not seen any substantial difference on newly loaded FSX or just having rebooted, I do not know why you are seeing that difference.

 

I do see the difference when reloading the game after just having loaded the same exact scenery at an airport (but that is because you are reloading everything the same, including objects), but when flying it does not seem to me the tiles are magically loaded faster if I had already visited a tile or not, the load times are still quite slow once you get fully out of the LOD zone and let the previous LOD zone FULLY UNLOAD itself (hence many miles away), and then quickly fly back to the original area (it's still as slow or almost as slow).

 

I've been compiling these things myself as I'm building a scenery, so I have around 1000+ hours of watching tiles load (unfortunately). I've tried the test on VERY high resolution imagery (up to 30cm) which is probably higher than the ultra-res cities, and I've tried it at 60cm resolution. I have some of MSE's scenery, I can try it again on theirs I suppose, but would have to reinstall it.

 

Can you post your full config, I really want to know if I am missing something?

[SAAB340 28]

I hear you, but there is no point in rebooting every time since the only benefit when flying in FSX is when not rebooted. Hence, we don't reboot every time we load a new tile when in the game, therefore I don't see why conduct a test in a scenario that is not relational to the actual in-game experience.

 

...

 

Can you post your full config, I really want to know if I am missing something?

The only way to make sure you actually do test your storage in a repeated test situation to specifically test the storage impact on texture loading is to reboot between tests.

 

Rig is

3930k @4.2GHz HTon

8GB 2133MHz CL9 RAM

780GTX GPU

160GB Intel X25-M G2 SSD with OS and FSX on it.

A separate disk for the add-on scenery. This time swapped between the 1TB Velociraptor and the 1TB 840 EVO.

 

For the test FSX is setup with a rebuilt cfg with only highmemfix, BP=0 and AffinityMask=4089 added. wideview, disablepreload and LOD=9 altered.

 

Settings are as below apart from that FPS is locked to 30FPS inside FSX:

 

The fact that I use a hyperthreaded hexacore with plenty of texture loaders is not the reason there's a difference between the drives. Ther HDD is still slower than the SSD if I set it up using only 2 texture loaders.

 

That by the way gets painfully blurry as soon as you start to fly fast.

 

It's the high LOD setting and the fact that there's tons of photo scenery active around the plane (the states of WA, OR, CA, NV and UltraRes city LAandSanDiego) that is causing the HDD to load the textures slower.

[Christopher Low 5,325]

I never suffer from this problem, because I always fly "low and slow", even in the PMDG 737NGX!

[SAAB340 28]

As I mentioned earlier, texture loading with the HDD improves quite a bit by just excluding the bgl files in the California scenery that cover the same area the UltraRes LAandSanDiego does. So removing just 68 bgl files from the scenery library can make a notable difference on the HDD whilst almost no difference on the SSD.

 

 

I've intended to make a new thread highlighting the improvements you get from excluding these files when using ultra res cities. The main improvement has nothing to do with the improvements shown in this video. But improved texture loading is obviously still a bonus if you're using HDD. The main improvements is that you remove the bleed through of the California Scenery through the UltraRes city textures. But I still need to take a few screenshots but won't get that done for a while.

[dtmicro 1]

Thanks for posting the config, I will do further testing when I get the chance.
 

The only way to make sure you actually do test your storage in a repeated test situation to specifically test the storage impact on texture loading is to reboot between tests.
 

 

With respect, and not trying to demean your hard work and all your analysis, I still respectfully disagree.
 

1) As a developer of FSX scenery, you can simply compile the same TILE as different BGL names and at different points on the map (like 200+ miles away), then write down the coordinates, then jump to each set of coordinates. Or take it even a step further, such as if worried about advanced caching "similar file recognition" techniques, then you can even save the same tile without metadata or with one pixel changed and compile each one subsequently into its own BGL. If really paranoid about caching, just use a different tile that is close enough to the same file size as the other tile. Though in my tests, these last two things do not matter, so just use the same tile compiled as separate BGL's will produce the best test results.

 

There is a lot going on with FSX, and this isn't in any form the same as raw testing a hard drive.

 

Furthermore, a reason rebooting can be a bad way to test is because due to Windows unpredictability in doing things covertly in memory (which can affect the memory bus and load times due to CPU de-compile times without the HD raw speeds being affected), Windows can cause a file to COVERTLY load slower even when the CPU %, Drive Read/Writes, and other drive performance counters or metrics are showing nothing. Another problem is the varying CPU and GPU load during different state points even if executing the same test over and over again after rebooting.

 

2) Even though # 1 is the actual way you should be doing your testing, to elaborate just a bit more --- your test by rebooting isn't that much different than just reloading the same tile over and over again. Why? Well because each reboot has its own variables, just as each cached reload does. The speed objects load in FSX can depend on the current state of the motherboard's IO BUS, and internal HD caching Windows and DirectX internal pre-fetch stuff, and this can really mess up the test bad due to Windows being unpredictable. Even performance counters can easily be misread as there are other variables to take into account besides just # of read/writes or MBPS, and even looking at the # of random seeks doesn't get rid of the other variables.

 

3) Flying the plane around and trying to simulate the exact same test after rebooting is difficult at best, the airport objects are going to mess up the test, because there are too many interchanging variables. To eliminate the variables, you need to do the test with ONLY BGL tiles in remote areas that have no objects around. Objects cause test results to vary too much.
 

There are a few types of tests you need to do to completely validate the results.

 

I will try harder later and see if it is settings or the BGL compression settings. I will post here as soon as I get some concrete results.