Sign in to follow this  
SAAB340

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

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

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. 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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:

(0)Settings.GIF?dl=0

 

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

To be clear, Yes --- reboot the computer before a set of tests, but don't reboot between each test. When doing performance testing in FSX, you do NOT even want to restart FSX, much less reboot the computer between tests.

You need to be in the same "reboot instance" of FSX and Windows, so just use tiles that you know were never loaded before (hence renaming or a fresh compile)...

 

Also, although I compile the tiles myself (this ensures they are not cached, because they were never even read before), you can probably avoid recompiling just by renaming the BGL files (tiles) and restart FSX. This way you can be sure the "covert stuff" running in the background is in a similar state, and that the swap file is in a similar state, and all the background garbage that runs in Windows whether we want it to or not is in the same state. After each reboot, there are other things that can be problematic as well, because Windows can be in a different background state between reboots.

 

All this said, I believe the reason your tests may be showing faster SSD times is partly due to your "fresh environment" that you keep creating by rebooting and restarting FSX. If you let Windows sit there for 10 minutes or so after a reboot, and then play FSX for 5-10 minutes, then do your fresh tile testing, it will perform differently. This is how we actually play the game anyhow.
 

Yes, some FSX stuff will get cached, but NOT fresh tiles, there is no possible mechanism for FSX to cache a tile that has never even been read before,. Also, when we play FSX for a few minutes, some stuff is cached already when flying in a real environment (hence some object libraries), so my testing methodology is almost opposite of yours.

 

All this rebooting is actually giving the SSD an advantage that won't exist in regular FSX usage.

Share this post


Link to post
Share on other sites

Not sure were actually talking about the same thing here.

Let me summarise.

 

Years ago I measures if an SSD improved texture loading vs HDD. I came up with the answer that it didn't as long as you had a decent HDD. I posted this here on Avsim.

 

As I aquired more and more photo scenery and used it more I felt like that wasn't the case as I flew around in FSX. I felt texture loading was indeed slower using the Velociraptor despite my previous testing.

 

I tried a new testing scenario more in line with the way I was using my photo scenery and ended up with an result that reverersed the results from my previous testing. It was showing that the SSD is indeed quicker at texture loading at this use case. I posted this again.

 

I record a video showing the difference hoping that a side by side video can be a bit easier to grasp than just numbers on a spread sheet.

 

I get told that the way I do this test that confirms my in game experience is wrong because I reboot between tests. My test is very repeatable giving different but consistent results from different drives. I'm getting told that the right way to test would be not to reboot between tests even though I can with my own ears hear that there's no data getting read of the HDD if I do that. I can through software confirm that the data isn't getting read of the disk if I do that. And my results also agree. They are very consistently the same regardless of fitted drive if I dont reboot.

 

Let's just agree to disagree.

Share this post


Link to post
Share on other sites

It is true that different processes can start running in Windows from one boot to the next that can affect the results. That's why I make several measurements for each result in my spreadsheets. As the test is very repeatable that will show up as a slower measurement and when that happens a quick look in performance monitor often shows this is the case and the measurement is than discarded.

 

Its also true that having a lot of objects around can give you variable results. When I redesigned the test I did initially try it over mainland Scotland using all the Horizon photo scenery as well as treeacapes and scotflight active as that is how I use it in game. That test scenario did produce a lot more variability between repeted tests on the same disc still showing HDDs slower than SSDs. Just harder to pin down a reliable result in how much slower. By using process explorer, process monitor and disc mon I found out that there is one FSX thread that isn't assigned affinity by the affinitymask in the cfg that is the tread that reads most data of the disks. When we include a lot of objects to read the CPU load of this thread increases and as its prefered affinity changes every time FSX is restarted it introduced a lot more variability between measurements. In particular with Hyperthreading active and with certain affinitymask. That's why I moved the test to where it is now where I get concistant results with all afinitymasks.

 

Affinitymask 4089 on a hyperthreaded hexa core is one that introduces a lot of variability together with a lot of objects. 4081 is a lot better in those cases. The same is true for affinitymask 249 on a hyperthread quad core where 241 is better or default 15 on a non hyperthreaded quad core where 14 is better.

Share this post


Link to post
Share on other sites

I'm thankful that youre trying to validate my results with a different test. Its always good when that is done.

 

This way that I started measuring texture loading was initially designed get an actual measurement to show that FSX can make use of multicore and Hyperthreading. It used to be like swearing in church if you said FSX could make use of Hyperthreading as it (in most cases) didn't improve FPS and if your FPS doesn't go up it can't be doing anything right... A few years later i feel this general misconception has finally changed and you don't get told FSX can't use Hyperthreading anymore.

 

It just so happened that the same testing method could be used to test storage as well.

 

I'm sure there will be other ways to conduct a test that can be repeated with consistent results. Possibly even one where rebooting isn't needed.

 

Worth to remember is that using the same testing method as in the video created for this thread in another location that puts less stress on the storage system I can get a result that says there's not much difference at all between SSD and the Velociraptor. That doesn't make the results in the Video wrong. It clearly shows a difference in texture loading time at that test cenario. The results in the video also reflects my in game experience.

Share this post


Link to post
Share on other sites

I am not trying to give you a hard time here, however as an FSX developer for about a year now, but I've been a programmer for more than 20 years, I am absolutely certain that your test results have an issue...

 

If you look at the common sense numbers, it can be derived why very simply...

 

How long does it take to load 100 tiles in FSX fully resolved, vs the raw hard drive speed that is possible?

 

Well it can take a VERY long time to load 100 tiles in FULL detail if you jumped to each one, I mean we are talking many many minutes. Yet the HARD DRIVE load time is only seconds.

It is something like 100:1 or more on how much CPU bottleneck the compressed 1.2m NAIP tiles are loading vs. the drive, and absolutely most definitely not more than 20:1 with all variables accounted for (GPU, CPU, HD, Memory, etc...), so the max improvement with a tile load on an SSD drive is only 5%.

 

You cannot ignore simple ratios, all computers are based off ratios, and ratios do not lie. This is the basis of computer science is ratios, that is where you start when analyzing this stuff. We can derive ratios outside of other variables, because we know the raw tile loading time if you COPY the tile outside of FSX from the drive vs. the CPU time de-compiling it. Nothing else matters, there is no argument to supplement this fact, I am sorry.

 

The Proof is in the numbers

 

With the MSE state of Utah as a perfect example, there are about 5000 tiles in the state of Utah total (and this is about 40GB of data if I recall (thereabouts, just install Utah and then check the total size of all MSE installed files to verify). This 40GB of data is already compressed by the compiler.

 

I know this ALL to be true because I have downloaded the whole state in RAW Format myself and compiled it myself from the NAIP imagery site (www.thenationalmapviewer.gov). I know at LOD = Auto, 15 (1.2m) is the size they are using with probably 85% compression setting (it is NOT a coincidence that when I use these settings in the FSX compiler, that my tile sizes come out about the same size as MSE). I am talking about tiles, not files (two different things here).

 

Even 100 tiles already compressed is generally less than 1.5 GB (I know this because I can compile a tile myself individually and see the size), so this can be read in 20 seconds or less on an average 7k RPM SATA even when broken into smaller files (before CPU processing). The hard drive is of course reading the compressed data, then the CPU is decompressing it. The ratios are unfavorable for the hard drive to increase performance.

 

Yet the HD could load this entire set in seconds, the reason is because ALL the load is on the CPU, not the drive. And when I say all the load, I mean greater than 95%, so there is no way to increase the tile loads more than 1-5% with an SSD drive, it is absolutely impossible with our current CPU's.

 

The only thing that COULD be possible is putting the game fully on the SSD drive could be compensating something that is causing a faster load (I will test this later, but I am doubtful).

 

This isn't theoretical, any developer that has ever dealt with and understands FSX image and compression knows this to be true just by looking at the tile sizes and general load times.

 

This isn't anything new I'm coming up with, in other forums this issue has been beat to death and we already know because of tile sizes vs. load times that it's all on the CPU, and you can speed up the hard-drive thousands of times and see no real benefit to tile load times, that is until you start using uncompressed tiles (no-one does this as they just become too gigantic to manage, a state could end up being over 300GB of data or worse even for 1.2m).
 

FSX developers already know this, go to the Orbx forum and ask a developer if you doubt it, they'll tell you the same thing. There is a bunch of SSD propaganda, and I love SSD drives myself, but it just doesn't help FSX as much as people want to believe it does. It does help some things, and initial load times, but other than that it won't help tile load times (not unless something out of the ordinary going on with a config).

Share this post


Link to post
Share on other sites

I know down to the specific coding algorithms why FSX loads these things slow, it is because FSX relies on the CPU to decompress the tiles instead of caching Gaussian Blurred images and lower-res distant Mip Maps, and in modern compression schemes using MIP MAPs (like GTA V for instance), the pressure is on the video card because modern cards and API's (like DX 11+) have built-in optimized compression options and MIP MAP options to GREATLY improve this. That is what FSX coders did not take advantage of, that is why the tiles load so slow, and yes it is possible to make them load instantly by making better use of Gaussian distance blurring with MIP MAPS in the distance. FSX is loading a specific LOD or resolution level of several tiles simultaneously instead of using many many MIP map levels that are graduated like GTA 5 does.

 

This is why if you fly in the game Grand Theft Auto 5 on the PC the tiles load instantly with ZERO delay at 30fps on a modern system, but as you get farther from the mountains in GTA 5 the mountains actually get blurrier (not clearer like in FSX). FSX does it backwards, instead of MIP MAP'n and using very small amounts of compression on the photo-real tiles, FSX only has this capability on objects that have MIP MAP's pre-compiled, so FSX is basically just loading a piece of the image like a JPEG used to do when it was interlaced. So this is why FSX is so slow at loading tiles, but yet with a high LOD setting can remain sharp looking (sharper than GTA 5's mountains for instance).

 

That is also why ORBX stuff can OOM very easily while Photoreal does not OOM easily (even though some claim the contrary, test it yourself), but if you DISABLE all ORBX (set to default in FSX) and use Photoreal, your chances of OOM are much lower. I know this to be true theoretically, but I also know it in my own testing. People that get an OOM in a Photoreal session get it for a different reason (texture of plane, objects in distance, whatever). Photoreal is unloaded from memory more easily than some objects, whereas there is a base memory assignment that is required for auto-gen and similar things that are loading fast on the screen.

 

I noticed that on a vanilla install of FSX while running PHOTO-REAL that an OOM is EXTREMELY rare even at a LOD of 8.5 in VERY HIGH RES photo-real, but run that in Vancouver and Slew at 4x around, and BAM OOM quite frequently with ORBX.

 

Even on a vanilla FSX install flying at normal speeds, run Orbx with a LOD of 9.0 or more and you're going to get an OOM in some of their areas too often (Northern Cal for example). It's the object libraries and Auto-gen causing it, and the textures on top of that. However, Photoreal is different because in MSE's case, no auto-gen and few objects.

 

That's how we know, I don't know how you can debate this really, I would suggest going to the FS-Dev area and getting input, and any capable FSX developer will re-iterate what I said here.

Share this post


Link to post
Share on other sites

 

 


You need to be in the same "reboot instance" of FSX and Windows, so just use tiles that you know were never loaded before (hence renaming or a fresh compile)...

Well, I managed to squeeze in a brief testing session today.

 

I copied the CA, OR, WA and LA+SD ultra res scenery so I had the bgls on my 840EVO SSD, my 850PRO SSD and my Velociraptor HDD at the same time. I made sure the HDD was well defragged. In total this scenery is 200GB and 3007bgls.

 

I re-booted the computer and used process explorer to monitor the disk activity.

 

I fired up FSX. Made sure the scenery library pointed to the 840EVO SSD.

Ran the test. Clocked 24.7s to load the scenery. Software told me loads of files were read of the disk. No strange non FSX related disc activity was observed.

 

I kept FSX running. Went in to scenery library and pointed to use the scenery off the Velociraptor HDD.

Ran the test. Clocked 30.0s to load the scenery. Software and my ears told me loads of files were read of the disk. No strange non FSX related disc activity was observed. The HDD was very notably slower even though i was still in the same windows and FSX reboot instance.

 

I kept FSX running. Made sure the scenery library pointed to the 850PRO SSD.

Ran the test. Clocked 24.3s to load the scenery. Software told me loads of files were read of the disk. No strange non FSX related disc activity was observed.

 

I kept FSX running. Made sure the scenery library once again pointed to the Velociraptor HDD.

Ran the test. Clocked 23.8s to load the scenery.  Software and my ears told me barely any files were actually read of the disk. No strange non FSX related disc activity was observed. That data was obviously read from somewhere. But not off the disk. My uneducated guess is cached in RAM.

 

Still kept FSX running. Made sure the scenery library pointed to the 840 EVO once again.

Ran the test. Clocked 24.3s to load the scenery. Software told me barely any files were actually read of the disk. No strange non FSX related disc activity was observed.

 

So to summarize. I've once again been able to recreate a SSD being notably faster to load photo scenery compared to a Velociraptor HDD as long as the scenery is read of the disk. This time using a method that didn't involve any re-booting of either the computer or restarting of FSX itself.  This method was however very time consuming compared to re-booting the computer. I only acquired one 'valid' result for the 850 PRO and one for the Velociraptor. The results in my spreadsheets are averages from at least 3 valid results. In no way does it however indicate that the results using the method where I reboot the computer are invalid.

 

 

 


Well it can take a VERY long time to load 100 tiles in FULL detail if you jumped to each one, I mean we are talking many many minutes. Yet the HARD DRIVE load time is only seconds.

It has mainly to do with access times. HDDs keep the CPU waiting for each packet of data it reads of the disk. Its mainly 4k reads and they are not sequential. The SSD has fast enough access time to fully put the bottleneck on the CPU again. The HDD is not there. There's no measurable difference between SSDs even though one SSD on paper is a lot faster than the other. 

 

 

 

 


The Proof is in the numbers

 

I know. That's why I prefer to produce them through tests and post what I find. Yet another set of numbers above showing a SSD being faster to load photoreal over a HDD. Just as I feel when flying in the game, but you cant produce a number to a feeling. That's why we need appropriate tests to produce them. 

 

 

 


I noticed that on a vanilla install of FSX while running PHOTO-REAL that an OOM is EXTREMELY rare even at a LOD of 8.5 in VERY HIGH RES photo-real, but run that in Vancouver and Slew at 4x around, and BAM OOM quite frequently with ORBX.
 
Even on a vanilla FSX install flying at normal speeds, run Orbx with a LOD of 9.0 or more and you're going to get an OOM in some of their areas too often (Northern Cal for example). It's the object libraries and Auto-gen causing it, and the textures on top of that. However, Photoreal is different because in MSE's case, no auto-gen and few objects.

I totally agree with you. Photoreal can be used with high LOD without OOMs. As soon as you venture outside and on to an area with a lot of various autogen the OOMs happens quite quickly. Even with default scenery. 

 

 

 


That's how we know, I don't know how you can debate this really, I would suggest going to the FS-Dev area and getting input, and any capable FSX developer will re-iterate what I said here.

I'm such a stubborn ###### that questions things and speak up when I don't agree. Born that way. Sorry  :wink: It's also very important to be humble and be able to change your mind when proven wrong but don't feel that has happened in this instance.

Share this post


Link to post
Share on other sites

As I understand it, you can get OOMs relatively easily with photoreal scenery if you have lots of these areas enabled in the Scenery Library, because FSX/P3D loads all of the photoreal scenery areas that are active (rather than just the ones within a certain radius of your aircraft). In fact, I can easily induce OOMs even when I have unused photoscenery areas disabled. That's because I use ES TreeScapes autogen at maximum complexity, scenery at maximum complexity, and UT2 AI @ 100%!!

Share this post


Link to post
Share on other sites

As I understand it, you can get OOMs relatively easily with photoreal scenery if you have lots of these areas enabled in the Scenery Library, because FSX/P3D loads all of the photoreal scenery areas that are active (rather than just the ones within a certain radius of your aircraft). In fact, I can easily induce OOMs even when I have unused photoscenery areas disabled. That's because I use ES TreeScapes autogen at maximum complexity, scenery at maximum complexity, and UT2 AI @ 100%!!

As far as I can recall from logging disk reads last year, FSX reads the first 4k of every active scenery bgl shortly after initial startup or when you load your first flight if you have disablepreload=1 in the cfg. That's why the initial load time takes forever if you have a lot of active scenery and also the reason the SSD is so much faster compared to HDD when it comes to that. SSDs are great at short 'random' reads.

 

During a flight from SanDiego to LA with LOD9.0 in the cfg i saw photoreal bgls in western NC getting loaded from disk so it does load photoreal far from the plane as you fly along. Way, way further than the horizon. Obviously at lower LOD the further away from the plane you get. Never saw it load any of my active New England states or the active UK photoreal though. It did however touch mesh as far away as Turkey whilst flying on the US west coast. That's almost half way across the globe. Guess it would have touched the NewEngland photoreal bgls should I have selected top down view and zoomed out until half the globe was visible.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this