I am getting an average VAS of 3700Mb with some pics at 3900Mb when flying with FTX global, vector and LC over Squamish CYSE.

After following Rob's advices it seems much better (essentially after removing all 2024x2024 different textures) but I still had few OOMs alerts without freezing the sim and a last "fatal" one stopping my flight on approach after 1 hour flying.

Another thing to check is VRAM usage ... I recall being in some NCA areas (KMRY I believe) where VRAM usage was very low (<1 GB) but VAS usage was very high 3.7GB starting. My normal VRAM usage is anywhere from 2.2GB to about 4.3GB ... so when I see my VRAM <1GB it makes me wonder if something is CPU bound rather than GPU bound.

I don't recall if Squamish was one of these areas, can check later. But a typical 2-4 hour flight in Orbx AU or Orbx NCA/PNW will consume about 600-700MB VAS and that includes using GSX at both departure and destination airports, and ASN, REX 4, and Aerosoft's A320, etc.

Thanks to Kosta! I love your knowledge and honestly. It really helps the simmers like me. Giving me a realistic perspective of whats going on with Prepared and simulation in general. Unlike others/ beta testers on youtube we cant/don't get the real picture. I hope you keep posting.:)

As I'm set up with a clean proper install of Win7 64x (ala Nick Needham) on a dedicated P3d box, the only OOM I have ever experienced in P3D 2x is with Aerosoft's Heathrow Extended with FTX EU England and heavy traffic. Again, look to the add-ons and subterranean OS issues.

I would wonder really REALLY much if it were FSUIPC. But I said nothing ;-)

My suggestion is still to follow up on the addons. For me, always, even in the FSX, the biggest culprits were FTX Regions in combination with heavy(ier) aircraft and addon airports.

For instance: flying a T7 or NGX out of addon Heathrow with FTX UK activated. No-go. And I use LOD 6.5 in FSX. I also have to reload, and I usually do, in the middle of the flight, just to be sure I can land properly. Doesn't hurt and it's only a little "procedure".

And in P3D, it can only be worse, as it uses more VAS on startup by default. My FSX, with all its 300GB installation takes up 200MB of less VAS on startup at the same airport than P3D does with all the relevant addons, but without anything else FSX is holding, like additional sceneries (deactivated) and modules like A2A, ORBX modules, Aerosoft modules etc. They all take up additional VAS.

I can provide a little update on my experiences although I haven't had much chance to fly in the last couple of weeks.

I followed Rob's instructions to the letter and did a VA flight from CYVR to CYKA in the A318. This is a flight I have done many times and is a great tester for VAS. One thing that I did change that I didn't realise I hadn't done previously was changing the FTX Vector settings as per Rob's guide to show fewer roads/railways etc. I decided to keep traffic off for the flight.

On loading up, the VAS usage on start up was 2.96GB - pretty damn high to start with. BUT instead of going north to really dangerous levels as I departed (and in fact this time I deliberately flew over downtown Vancouver) it went up to a max of around 3.5GB - still high but with room to spare. As I departed the area it went down by around 200MB. Previously in a comparable flight (to CYLW that time) I had then see VAS get really high as I neared the destination but this time, and perhaps due to Kamloops (CYKA) being relatively sparsely populated, I managed to land with a max VAS of 3.6GB and no OOM's. I count this as a victory. I will need to fly back to CYVR and also want to retest the flight to CYLW but Rob's settings appear to have given me just enough leeway to be able to fly around the tougher VAS heavy regions (with complex aircraft too).

There is a big however, however. I simply did not have to manage things in this way prior to 2.3. I was happily flying around the PNW with higher texture settings (2048 and more densely populated autogen and using ATC and traffic) and in complex aircraft (A320 and Q400) with no need to even worry about VAS. I dare not even turn on VOX ATC again or other things I was happily using before. Something has definitely changed in the updates that either make the sim more VAS heavy or the add ons I (we) have more VAS heavy. I wonder if there are any comments or thoughts on this from the guys at LM?

The vegetation autogen fix from a couple of version ago was like a revelation at the time so I wonder if there are further optimizations that can be made along the same lines in the next versions? It seems that the benefits gained when that was implemented have disappeared in the latest versions.

I would exercise some caution here. The fact that you did not experience OOMs does not mean that 64 bits in general are not needed. Your experience is not everybody's experience. For that matters, I also did never experience OOMs so far, but this does not make me think that we may well survive sticking to 32 bits.

That's what 64 bit processors were meant for, i.e. to enable software to handle large sets of data without having to worry about memory constraints. The memory limit imposed by 32 bits has been hit for some time now; I remember the many complaints about OOMs back in the FSX era, well before P3D emerged. The Service Pack 2 for FSX added the large address awareness to FSX, which doubled the available VAS (only if run in a 64 bit operating system, by the way), but this was only a temporary solution, and in fact the new VAS limit was hit again quite soon. Therefore, there is general consensus about the compelling need to move to 64 bits. Other sims (I won't mention them here, but you may easily guess what I'm talking about) have already been successfully ported to 64 bits, so this shall obviously be the same destiny of P3D too, sooner or later.

I acknowledge that converting a huge source code repository (as I imagine P3D is) will be an overwhelming effort, especially if the software was not coded from the very beginning with portability in mind (which means, for example, that the source code shall never make any assumptions about the size of pointers). But it is a needed step to make P3D future proof.

Why is it that FSX and P3D have such a problem purging the VAS of unnecessary data? I am no expert, but I would have thought that solving this problem would be the holy grail for 32bit flight simulation.

Why is it that FSX and P3D have such a problem purging the VAS of unnecessary data? I am no expert, but I would have thought that solving this problem would be the holy grail for 32bit flight simulation.

Well, in my opinion to say that purging the VAS of unnecessary data would be the "holy grail" of 32 bit flight sims (and 32 bit software in general) would be conceptually dangerous. What I mean is two things:

It should be not assumed that whenever the VAS usage is high, then there are unnecessary data present; maybe it could simply be that summing up textures, geometry, scenarios, flight models etc. could INDEED result in the need to allocate 4 GB or more -> in this case there is no remedy, a 32 bit app with such a need will crash unavoidably.

Purging immediately any data that is not needed at the moment could be a good approach to minimize VAS footprint, but remind that this is not good for performance: if you have some data that are unnecessary now, but could be necessary again in a few minutes, unloading them now implies that you will eventually have to load them again, thus using storage bandwidth, memory bandwidth and CPU resources. An application can not be optimized at the same time for memory usage and speed.

That's why 64 bits came in action, as I wrote in my previous post: to allow applications to access and process wide sets of data without the hassle to optimize memory management to the extreme in order to minimize the used memory at any time. It is much cheaper to let applications use more VAS, rather than forcing developers to find out any possible trick to fit into 32 bit addressing space...

VAS usage is really a big issue for me in the current version (2.4). Yesterday I attempted to complete a flight from KLAX to KSFO using FSDT scenery, Orbx NCA, Airbus A318/9 and ASN real weather (for the most part clear during the flight).

I used the suggested settings posted by Rob previously but to no avail - with very modest slider settings and things dialed down, I had an OOM at 20ft above RWY28L at KSFO. There is very little else I can think of to reduce in order to make a flight like this possible. It's especially strange as I have done this flight before (in the A320) and with higher slider settings.

I'm watching VAS usage constantly in Process Explorer which isn't much fun - I am fully aware that the scenery and add-ons are complex and challenging for the sim but I am not too sure why I'm having so many more problems than I did previously. And that was when I used higher slider settings. Does anyone at LM have any thoughts on VAS usage and why I and others may be experiencing the above when compared to previous versions of P3D (2.2)? Just wondering if anything that has been changed in subsequent updates that could have had an effect on VAS usage - cloud shadows perhaps? I'm just a little out of ideas.