I've done quit a bit more testing with different storage configurations. Just want to give a quick update before I'm off on vacation.

 

When it comes to load times it's the access time that is of most importance. Different transfer rates between the inner and outer parts on the HDD has just a minor impact while different type of drives makes the most impact. Even the latest Velociraptors will still be a bottleneck. So stay away from those 5400rpm drives=)

 

I'll publish all my findings in a while.

Great work! I know article "Global Terrain Technology for Flight Simulation" very well but is nice to see all of these visualised and confirmed in tests with modern multicore processors. Now is clearly visible that disabling HT in Intel i7 processors is right choice.

Thanks for your magnificent work.

@SAAB340 - Any chance you could provide a little more dsetail on how to set up FRAPS and then provide the EXCEL spreadsheet source so we could perform the same tests on our own PCs? I think you have provided a great revelation - particularly on stutter definition - and I would really like to see if my 980X system with 580 and/or 680 performs optimally. With THREE monitors at 1920x1080, there are some additional considerations perhaps. I notice more stutter with the 680 driving all three in WINDOWED mode than with the combinations of graphics cards - it might even be optimal if I had three separate cards (affordable??).

 

Thanks - if possible

 

Dave

Thanks for the kind words guys.

 

@SAAB340 - Any chance you could provide a little more dsetail on how to set up FRAPS and then provide the EXCEL spreadsheet source so we could perform the same tests on our own PCs?

I should be able to upload the spreadsheet template I use together with an explanation how its designed. You basically copy in the frametime and FPS csv files you can tick a box for in FRAPS. But It will probably take a little while because I'm working away again and I'm moving house (a great combination... :-/) so I won't be able to use my desktop where I have the files for a while.

 

I've completed a bit more testing with a few different HDD/SSD combinations with OS and FSX on different drives as well, but have a bit more work to do there and that's on hold now as well...

I've now posted my updated SSD vs HDD results in a new topic here

attachment=43398:(1)Quad-core.GIF

 

What has happened that images disappeared? It is very valuable material but it is losing a lot without statements shown on images.

What has happened that images disappeared? It is very valuable material but it is losing a lot without statements shown on images.

 

I dont know why the pictures dropped out. I wish I could edit the original post and put them back in. Maybe a moderator could help? Here are external links to all the pictures. I hope it can help future readers.

 

https://www.dropbox....(0)Settings.GIF

https://www.dropbox....1)Quad-core.GIF

https://www.dropbox....T dual-core.GIF

https://www.dropbox....ual-core HT.GIF

https://www.dropbox....uad-core HT.GIF

https://www.dropbox....a/(5)LOD4.5.GIF

https://www.dropbox....5/(6)LOD BP.GIF

https://www.dropbox....o0b/(7)LOD9.GIF

https://www.dropbox....LOD4.5 LOD9.GIF

https://www.dropbox....9)With BP=0.GIF

https://www.dropbox....pact on FPS.GIF

https://www.dropbox....wx/(11)FFTF.GIF

https://www.dropbox....z/(12)Vsync.GIF

https://www.dropbox....fig changes.GIF

https://www.dropbox....)SSD vs HDD.GIF

https://www.dropbox....tp/(15)ATTO.GIF

Hi Lars,

I am still reading your older post (I haven't spotted before). Just two quick questions:

I was under the impression that photoscenery is handled quite differently by FSX than conventional scenery. Is your analysis valid also for conventional scenery?

"Load Times" refer to loading a flight?

 

PS1: Excellent approach. Very well done.

PS2: Reading more carefully the MS article on terrain engine: interestingly autogen is not referred to in the discussion. That would mean that is not part of the terrain engine (aka "fibers")? Maybe autogen can be the unknown thread that can appear in core(s) excluded by AM?

I guess we should continue this discussion here instead of hijacking Kostas guide

 

I started investigating the effect of different affinity masks on texture loading quite a while back using the FSmark07 flightpath over Seattle. The same flightpath I use when I study the impact on stutters and FPS with different storage. There, over regular scenery I saw a clear effect on texture loading with different affinity masks and a bit of the impact of FFTF but one that was hard

put an accurate number to. Photoscenery is different in the way that all texture tiles are unique while normal scenery just use land class textures. So I believe photo scenery put a harder strain on the texture loading. But all indications I have are that my analysis is valid for normal scenery as well.

 

"

Load times are measured with a stopwatch from when “FLY NOW!” is pressed until the terrain is displayed outside the cockpit window.

So yes, it refers to the time it takes to load a flight. In my follow up HDD vs SSD post I also introduce 'launch time', the time it takes to start the FSX application.

 

Thanks for the kind words.

This is what Phil Taylor wrote in his blog post regarding the updates in SP1:

 

Multi-core Performance Work

13. moved DEM loading to threads,

14. moved terrain texture synthesis ( the process itself is documented in Adams' "Global Terrain Technology for Flight sim paper at http://fsinsider.com...t Simulator.htm, see the bit about the layers and texture synthesis ) to threads,

15. moved Autogen batch rebuilds to threads

 

So it's possible that some of it is autogen but I do however recall that you can see those other threads in task manager on a fresh FSX install without any ServicePack or Acceleration. Best seen if you configure your CPU as a Dual-core without hyper threading.

I guess we should continue this discussion here instead of hijacking Kostas guide

Very true. Sorry Word Not Allowed.

 

As for the excerpt from Phil Taylor's blog:

1.does it mean "threads" as distinguished from "fibers" or what?

2. reading Adam's paper, I understood that DEMs are part of terrain texture synthesis, but now it is distinguished.

Is there any way of monitoring what runs at each core (e.g. in ProcessExplorer)?

Is there any way of monitoring what runs at each core (e.g. in ProcessExplorer)?

 

Yes there is, One way it to use Thread Profilers, but it is complicated, to say the least.

1. The fibers are scheduled by the threads. So the terrain engine is still running on fibers but it can now use several threads with them.

2. The DEM (Digital Elevation Model) is the terrain mesh loading. Terrain texture synthesis is the process of composing the ground textures, burning in roads, decompressing the texture data and so on.

 

I havent used ProcessExplorer but Scot provided this interesting comment earlier:

 

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.

.

 

Given this it sounds like the texture, terrain and autogen happens in one thread on each additional core assigned on top of the main thread. This also indicates that it's mostly DirectX processes that are responsible for the other threads (what many people still incorrectly call fibers)

Does it mean "threads" as distinguished from "fibers" or what?

 

Threads and fibers are very close related. But fibers are elements of scheduling work on software/application side, threads are system/CPU side. One or more fibers can be processed by CPU as one thread. Read more here: http://msdn.microsof...1(v=vs.85).aspx

 

 

Reading Adam's paper, I understood that DEMs are part of terrain texture synthesis, but now it is distinguished.

 

DEM is an acronym of Digital Elevation Model, translating it to common known FSX's term it is mesh. Loading and processing DEM (making tessellation and matching it on curvature of WGS84 Earth's model) isn't texture related process. Terrain texture comes after finishing DEM processing and is placed on just generated terrain surface. Whole process can be called as creation of terrain environment.

This is a very good article to read with regards to FRAPS and its limitations: http://www.anandtech.com/print/6857/amd-stuttering-issues-driver-roadmap-fraps

So the hard stutters I show will actually show on the screen, while the small ones won't. It also explains why i didn't actually see the stutters FRAPS show when the half rate vSync tweak is applied.