Sign in to follow this  
Berike

Renamed Thread: User still having VAS problems.

Recommended Posts

I have the latest update and still having OOM when landing.

 

Just did a flight from PANC to KLAX

 

P3D 2.5 (latest update)

ASN 5589

PMDG 777-300ER

EZDOK

ORBX Global, Vector, NA / Alaska etc

vPilot

Share this post


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

You're going to have to provide more data to successfully assert that there is a VAS leakage in the PMDG 777.  For example, how have you eliminated all other users of VAS and measured a time-based consumption of VAS by the 777?

 

It's been said many times:  An OOM error is not an indication of VAS leakage, it is just an indication that you have asked too much of your allotted memory.

Share this post


Link to post
Share on other sites

 

 


I have the latest update and still having OOM when landing.

 

As Dan mentioned, OOM errors are not an indicator of a leak, as much as they're an indicator of VAS over-use in total.

 

If it's happening upon landing, it sounds like scenery is more of the culprit, particularly because you list FTX Global, Vector and NA/Alaska (which is a heavy hitter alone, even without the rest).

 

VAS is a sum game. PANC takes memory, NA/Alaska takes (a ton of) memory, Vector takes memory, FTX Global takes memory, and the 777 takes memory, too. If the sum of that goes over the VAS limit, then you get an OOM. While the 777 is a contributor to that (usually about 800MB of it), people aren't entirely correct when they say the 777 is causing it.

 

Please see here:

http://forum.avsim.net/topic/468259-07may15-detailed-discussion-of-resolved-777-vas-leak/

Share this post


Link to post
Share on other sites

Have a read thought the link in my sig.

Share this post


Link to post
Share on other sites

What specific routing did you use in the FMC, which specific approach did you select?  What level of autogen, weather, AI, etc.?  Are you able to repeat this even with clear weather, no other traffic, no sceneries activated?

Share this post


Link to post
Share on other sites

I have the latest update and still having OOM when landing.

A 4-5 hour flight is not even long enough in real time to even manifest a VAS leakage. You are just grabbing at straws. Try the suggestion of Kyle Weber in post #6. If you run out of VAS then, you could consider leakage otherwise forget it.

Share this post


Link to post
Share on other sites

I have the latest update and still having OOM when landing.

 

Just did a flight from PANC to KLAX

 

P3D 2.5 (latest update)

ASN 5589

PMDG 777-300ER

EZDOK

ORBX Global, Vector, NA / Alaska etc

vPilot

 

The leak is from Vector. I stopped using it until the next patch is released. Just stick with Global for now. 

Share this post


Link to post
Share on other sites

I think turning off a part of addons you don't need when you are flying will solve the problem for you.

Share this post


Link to post
Share on other sites

Ah this resurfaced.  Out of curiosity I fired up my B77W at a PANC gate and flew to KLAX.  I am using Aerosoft PANC, FSDT KLAX and Orbx enroute including SAK, PFJ, PNW and NCAL regions for NA; as well as Vector...which by the way I've never had a problem with Vector.

 

Anyway, I notice my VAS remaining was down to about 600 Mb at TOC.  This is not due to a memory leak that by definition takes time to become a problem.  This is due to the combination of tasks I've asked my 4 Gb of VAS to accomplish including scenery, ASN weather and PMDG aircraft.  The fix is simple:  Save the flight after TOC and restart the simulation and load the flight.  VAS remaining increased to 1.7 GB and the flight continued unaffected to KLAX including landing.  I could have improved the KLAX arrival by doing the save/load before TOD as I normally do but it was not required.  Having to do the save/load sequence at TOC is rare but required in this scenario.  I usually do a save/load sequence at TOD if my VAS is below 1 Gb.  This has prevented OOM errors completely.

 

EDIT:  I forgot to mention that I turned off Aerosoft PANC airport and terrain using Scenery Editor in between my save and load after TOC. Didn't want to drag that photoscenery all the way to LAX.

Share this post


Link to post
Share on other sites

 

 


The leak is from Vector. I stopped using it until the next patch is released. Just stick with Global for now. 

 

Thank  you for pointing this out.

 

Guys, he's absolutely right, there is something in Vector that can potentially make VAS usage run away. I was getting OOMs flying the 777/Aerosoft A320 out of stock airports unless I disabled all options in Vector Configurator except for "Highways" (no suboptions, just the primary tick box).

 

 

 

 

David Ayoub

Share this post


Link to post
Share on other sites

I guess results vary.  I and many others have no problem with the Vector product.  In fact, most of what vector does has nothing to do with texture loading, it's vector data.

 

I recommend that if you have problems you visit the Orbx forum (when it comes back) and try to find the solution; or, you can just turn it off I guess. That works too.

Share this post


Link to post
Share on other sites

If you haven't done so, suggest uninstalling and reinstalling the PMDG 777 with the latest version.  I also had the same OOM experience.  I had only ran the latest installer over an existing copy.  Like with my PMDG 737, uninstalling and reinstalling seem to be the only way for me.  

Share this post


Link to post
Share on other sites

To add to what Kyle and Dan said earlier - you would need to demonstrate that there is a leak over time (significant positive slope on a graph of VAS usage, significant negative slope on a graph of free VAS) while on a long distance (preferably over water) route at cruise for us to consider claims of a new or still existing leak. Several users have written tickets with such claims and I haven't been able to reproduce any of them under a controlled environment. Several users had the older version of the 777 somehow still and were seeing the exact issue we fixed in the last update.

Here's an example of my test of one of those routes a customer wrote in about. I made this by logging the free VAS using FSUIPC and turning the data into a graph in Excel. Notice that during the cruise phase there are fluctuations but on the whole there is very little drop in free VAS. The line is essentially flat during cruise. This flight was over land for the most part so there is some variance to be expected as new areas load in. The massive drop at the end is the Norcal/Bay Area loading in - FlightBeam KSFO, Orbx Northern CA etc all take up a ton of VAS in that area. We keep telling people how huge some of these sceneries are for VAS and graphs like this drive it home. I've seen a drop of over 1GB as FSDT KLAX loads in too for instance.

I landed with around 700MB free (FSUIPC was set to 15 minute log intervals here, so I didn't get the very end - there's a final high detail airport grounds loading that happens on short final that usually drops it significantly more from where this ended.

 

It's also extremely important if you're testing stuff like loading an approach vs. not loading one to keep everything else 100% the same between flight tests. Don't fly with weather, don't use AI traffic or fly online - only load things that you can keep the same. Fly at the same time of day, stay in the cockpit without loading the external views, use the same weights, FMC performance numbers, etc. This is basic scientific method stuff here - you want to isolate the variable you're testing so that nothing else can confound the results.

VAS_SBGR-KOAK.jpg

Share this post


Link to post
Share on other sites

Gents-

 

Ryan is being polite - so let me make another point here.  Please forgive me being blunt but:

 

99.999% of users aren't qualified to conduct the type of testing required to identify a true "memory leak."

 

In order to do so- the sim must be run under very tightly controlled circumstances that allow for ease of replication- and in 17 years of business we have found less than a half dozen users who are **actually** good at this- even after we provide specific step-by-step instructions on what we want accomplished.

 

This is why we don't ask you to diagnose such things- and this is why in 17+ years of this, we have only identified 1 such problem with the help of users.

 

We have very advanced techniques and tools that we use internally- and while we always enjoy help and input from users- the fact is- most of you don't know enough about what we are doing to really be of much help when it comes to machine level issues in code.

 

Oh- and please let us also not forget that we know what we are doing.  There is that too.  :lol:

 

To the original poster:  I renamed your thread because it was not accurate under the circumstances. 

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this