FSX is a multithreaded program, and for texture loading it is using in a quad core configuration 2 or 3 threads, depending on your AM. How do you figure it is going to be overloaded?

 

I have tested an SSD on my FSX configuration and seen a considerable speedup at VC loading and view switching when using SSD as opposed to velociraptor. This is the only reason why I would get an SSD.

For what it’s worth

 

Yesterday I moved FSX from a SATA3 7200 rpm Seagate drive to a brand new Intel SSD and both my FPS and texture loading went down the drain.

(I used the mklink /j DOS command to make the link from drive D:\FSX to drive S:\FSX).

 

I wrote down some notes beforehand using the RealAir Dukes; steady ~15-18 FPS at KSEA and ~30 on other airports, All with fast texture loading

 

Using the SSD drive FPS went down to ~6-11 at KSEA, cockpits views took around 3-4 seconds to refresh and top down view was all messed up with flashing aircraft or vehicle textures on top of scenery, not only at KSEA, but on all ORBX addon airports I own.

 

I have other SSD’s, so maybe there is a problem with the new one? Or AHCI vs IDE on BIOS? Unknown?!

 

Anyway I reverted to the original SATA3 drive and it took a while to get back to “normal” because some addons had updated their registry settings to the true “S:\FSX” path instead of using the Symbolic Link from “D:\FSX” and some other issues that appeared afterwards.

FSX is a multithreaded program, and for texture loading it is using in a quad core configuration 2 or 3 threads, depending on your AM. How do you figure it is going to be overloaded?

 

Threads run on core1, core2, core3 (in case of 4 cores CPU with AM=15) are responsible only for mesh, terrain textures and autogen processing:

"Multi-core Performance Work

- moved DEM loading to threads,

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

- moved Autogen batch rebuilds to threads"

Source: http://blogs.msdn.co...ork-in-sp1.aspx

 

View/camera "syntesis" process is performed only on core0. Reloading VC textures and rebuilding VC view is en element of view/camera "syntesis" process. It doesn't have anything to threads running on core1, core2, core3.

 

In few words, threads run on core1 to core n are loading and processing data about terrain environment. Most important and critical for FSX performance thread run on core0 is connecting this environmental data with data about aircraft 3D geometry, VirtualCockpit 3D geometry, weather model (clouds textures and geometry), flight model and using all this in "syntesis" process to "render" camera view. Lots of data and lots of work for only one core. That is why "TEXTURE_MAX_LOAD=" parameter has so significant influence on FSX performance as it affects mainly core0 work. One size bigger for "TEXTURE_MAX_LOAD=" setting is four times more data to calculate for aircraft, cockpit and clouds. I was talking about this when I mentioned overloading problem.

Yes, I know. I never ment it was VC textures that run on the multithreaded cores. But, when you switch views, not only aircraft model textures, VC textures need to get loaded, but also ground, and this is where the threads are helpful.

 

I full agree that reloading VC textures is done on the Core0. An interesting question though is if those textures are moved to Core1 if you use AM=14 on the 4-core CPU. You state they do not. How do we know that, is there some proof?

 

I get your concerns, but how is it that you figure that CPU is overloaded, because I see no delays of 2-3 seconds to load the VC textures, and this I tested with the SSD, and had even less delay, if any. Yes I did wait quite a bit between switches and tested on more aircraft.

 

So, while your points seem valid, in praxis I experienced that simply an SSD will "fix" the problem.

Problem solved for me! I posted my .cfg file here http://forum.avsim.n...25#entry2509272

 

In my opinion it is better to make changes in fsx.cfg manually according to great Word Not Allowed's "Software & Hardware Guide for FSX" http://forum.avsim.net/topic/370594-software-hardware-guide-for-fsx/ , than using Bojote's automated FSX Tweaking & Tuning Service at venetubo. You have better control, but I know that this is option good for people having enough time to bite this subject.

 

Next thing, I have checked your new fsx.cfg and I found this:

 

HIGHMEMFIX=1

UPPER_FRAMERATE_LIMIT=31

[JobScheduler] AffinityMask=14

TEXTURE_MAX_LOAD=1024

 

Check what I recomended to you and check recomendations at Word Not Allowed's guide too.

But, when you switch views, not only aircraft model textures, VC textures need to get loaded, but also ground, and this is where the threads are helpful.

 

That is true - as I wrote in previous post - primary thread on core0 is synthesizing all data into final view. That mean also preprocessed terrain enviroment data, but pbagrat reported problem with VC textures reloading so I focused on that.

 

 

I full agree that reloading VC textures is done on the Core0. An interesting question though is if those textures are moved to Core1 if you use AM=14 on the 4-core CPU.

 

Yes, with setting AM to 14, VC texture reloading is moving from core0 to core1. This was first solution I have found, and I recommended this for pbagrat.

 

 

I get your concerns, but how is it that you figure that CPU is overloaded, because I see no delays of 2-3 seconds to load the VC textures, and this I tested with the SSD, and had even less delay, if any.

 

Try to overload core0, up to 100% workload (complex airport, dense clouds generated by REXE or AS2012 weather engine, advanced aircraft, set TEXTURE_MAX_LOAD to 4096) and observe changes in VC textures reloading time.

 

 

So, while your points seem valid, in praxis I experienced that simply an SSD will "fix" the problem.

 

It depends on the initial scale of problem, if you have overloaded core0, using SSD won't have enough big influence to resolve problem, but if you reduce data flow on core0, it will be working better, then if you move to SSD it will working even more better.

 

 

Have you read "Texture loading + SSD vs HDD" by SAAB340? - http://forum.avsim.n...ing-ssd-vs-hdd/

I have found this very interesting and valuable material, I was mostly interested in influence of HT on terrain texture loading problem, but primary subject was about SSD. Btw do you know why images disappeared? These were very important for clarity of this material. I'm lucky because I have made copy on my HDD but I was recomending this material for some people to read and absence if images is real pain.

Try to overload core0, up to 100% workload (complex airport, dense clouds generated by REXE or AS2012 weather engine, advanced aircraft, set TEXTURE_MAX_LOAD to 4096) and observe changes in VC textures reloading time.

 

In such situations everything lags, not only texture loading. But of course - if you have 100% usage, 15fps, then everything will suffer and SSD will help only limited.

 

Images disappear if they are not hosted elsewhere, this is part of AVSIM. AVSIM doesn't store images forever. You must host them on dropbox or something.

Images disappear if they are not hosted elsewhere, this is part of AVSIM. AVSIM doesn't store images forever. You must host them on dropbox or something.

Thanks for clarifying. I'll do that in the future. Who has privileges to edit my initial post and put in the image links to dropbox? I've posted the links in a reply to the post as I can't edit the initial one myself.

Thanks for clarifying. I'll do that in the future. Who has privileges to edit my initial post and put in the image links to dropbox? I've posted the links in a reply to the post as I can't edit the initial one myself.

 

Contact Chase.

 

 

Sent from my iPad using Tapatalk HD

Yey! I think I might have solved it.... i just changed texture bandwidth from 40 to 400. Now switching from outside view to VC, textures load almost instantly. May not work for others but it worked for me. Doesn't hurt to give it a try. cheers!!!!

Try using AM from the task manager , even I am still tweaking my simulator.

i just changed texture bandwidth from 40 to 400. Now switching from outside view to VC, textures load almost instantly.

 

It seems that Airbus X and NGX come with too much textures as for standard FSX settings. You are third person I know who had the same problem and the same solution was helpful. I two other cases I'm talking about we changed TextureMaxLoad* from default value 3 to 12 achieving also good result.

TextureMaxLoad and TEXTURE_BANDWIDTH_MULTIPLIER are very closely connected parameters. TEXTURE_BANDWIDTH_MULTIPLIER is just an multiplier for TextureMaxLoad parameter used in formula to calculate MAX TEXTURE DATA. Personally I'm using TextureMaxLoad=12 with TEXTURE_BANDWIDTH_MULTIPLIER set to 40. My setting is 12 x 40, yours probably 3 x 400. I think it is little too high.

 

* TextureMaxLoad it is different parameter than TEXTURE_MAX_LOAD.

 

Btw. Are you using internal or external FPS limitation?

im not using texturemaxload but i'll try that too see if it works. im using the internal limiter @30fps with the vsync fix.

for an external limiter there is an app called as antilag and I use it.