777 OOM - depleted VAS (my brand)

[CaptKornDog 290]

Copy, thanks.

 

Unfortunately, I'm traveling later today, so I can probably only run 1 or 2 tests before I leave.  Should be back tomorrow evening though.

[pcubine 143]

 

 

Copy, thanks.

Finished EDDP-KLAX using 1407 V2 with no OOM. Parked at a  cargo ramp at KLAX showing 3.1GB VAS usage.

[CaptKornDog 290]

Finished EDDP-KLAX using 1407 V2 with no OOM. Parked at a  cargo ramp at KLAX showing 3.1GB VAS usage.

 

Well, very interesting indeed.  Sounds like that's the VAS usage you normally saw flying KLAX-EDDP eastbound.  And I'm assuming you didn't have to save and reload this time (i.e. you were able to complete the whole flight when you previously could not)?

 

 

And, thank you very much for testing for me - and helping me keep my sanity that I'm not the only one out there!

[downscc 1,328]

 

 

I hope PMDG support is a little more open minded and don't just dismiss it out of hand.

 

Michael, you add a lot of value here and I'd never 'dismiss out of hand' your hypothesis but I'm very familiar with how navdata is created and used in the simulation; based on my experience and knowledge I am skeptical but open minded to any hypothesis you offer. 

 

I look at the thousands of navdata users that don't have memory leak problems and wonder what would set up a cause and effect relationship for a few.  I'd like to hear your ideas.

[pcubine 143]

 

 

And I'm assuming you didn't have to save and reload this time (i.e. you were able to complete the whole flight when you previously could not)?

No saves and reloads. First time since 12-5-2014.

 

 

I'd like to hear your ideas.

My idea is that on the hardware and software I have, a combination of the T7, recent AIRAC cycles, and ASN all combined to create a "perfect storm" in FSX. I maybe stuck with 1407 and reinstalling ASN for the rest of my life. I need to pull some dates together from my records so I can see how events unfolded before I can say anything more than what I have already said without a making a fool of myself.

[CaptKornDog 290]

Michael, you add a lot of value here and I'd never 'dismiss out of hand' your hypothesis but I'm very familiar with how navdata is created and used in the simulation; based on my experience and knowledge I am skeptical but open minded to any hypothesis you offer. 

 

I look at the thousands of navdata users that don't have memory leak problems and wonder what would set up a cause and effect relationship for a few.  I'd like to hear your ideas.

 

My current FSX rebuild ONLY has the 777 and NGX installed (base liveries).  I removed ASN for testing purposes, and haven't even gotten around to installing any scenery.  When flying my control JFK-LAX flight, I'm using the same route, weights/flows/checklists, same default weather scheme, etc.  However, I'm starting each flight fresh, and not from a saved state.  So I'm trying truly to keep the only delta currently to either AIRAC 1502, 1501, 1413, or basic 1309 OR destination/departure airport, testing one at a time.  However, even when attempting other airports like HNL, ATL, MIA, IAD, all to LAX, I can see the same VAS leaking at 200 MB/hour within about the first hour or so of flight after departure.  When attempting this to airports that are NOT LAX (even HHR, right next door to LAX) the symptoms are not visible.  I'm willing to venture out and say this is repeatable at this time on my system. 

 

I've been able to fly the 777 comfortably to LAX before, and OOMs are very rare for me in general (I value balance tweaking and performance over eye candy; yep, for those wondering, I've read the VAS section of the manual introduction).  But I haven't taken the 777 into LAX since before Christmas; I sure wish I could identify what has changed since then other than a few Ops Center updates, SP1c/d.  I hadn't made any sweeping changes to my sim or machine, and reinstalling ASN gave me some temporary reprive, but I went ahead with the nuclear option anyway and wiped/reinstalled FSX on my drive.

 

I'm truly trying to do this in a methodical fashion.  I flight test aircraft for a living, but haven't the darndest idea how aircraft are programmed in FSX outside of the aircraft.cfg and textures I paint .  The best I can do is report my effects because I sure wish I knew the causes.  I'm certainly open, and would love, to hear your ideas as well.

 

(Coincidentally, was looking forward to treating myself and purchasing the -300 expansion this weekend once I finished my FSX rebuild.  Guess I'll have to put that on hold, unfortunately :huh: )

[downscc 1,328]

Interesting information.  I've not suffered from VAS leak (yet) but I have fought with OOM errors in past three months and never before that.  I observe a normal VAS remaining decrease of just under 100 MB (0.10 GB) per hour of flight for typical medium flight (3-6 hrs) and less on long ranges, which I do not consider a leak but normal for the microslop program. You are reporting a loss of available VAS at twice that rate and I would too find that problematic.  I leave all addon scenery turned on in CONUS but do not have any that includes photoreal scenery.  I do have photoreal scenery overseas (EGLL PANC YSSY for example) and these are only turned on when I use them.  Photoreal scenery gets loaded needed or not.

 

My knowledge of navdata starts with the experience I gathered six years ago when I maintained over 60 sidstar locations that I create from scratch using FAA NFDS data, so I know the structure of the data intimately.  My knowledge of how the data used inside the simulation is not expert level (I didn't write the code) but I've been fortunate to work with PMDG and Navigraph during introduction of new products to help test function.  The navdata is used by the FMS to populate terminal procedure routes/legs/constraints and to define routes and fixes in airspace, and the ND uses navdata to locate airports, stations and waypoints.  I think that pretty much defines the scope of the data. To my knowledge, navdata is not used in any way that would affect memory allocation beyond that already mentioned for FMS and ND use.

 

If you suspect that a certain airac cycle of navdata is causing problems, then I suggest you save the navdata files separately and build a SUBSET of that data. For example, only include the airports (airport.dat, wpNavAPT.txt) that you need, the routes that you use for the test flights (wpNavRTE.txt) the navaids you will use (wpNavAID), the sidstar files you call out in the FMS (which will include sids, stars and iaps), and if you need them don't forget fixes you might include in a flightplan that are not referenced by a route (wpNavFIX.txt).  I forecast that eliminating everything from the cycle data except what you need for the session will have no impact on the VAS problem.  However, if it does make a difference then you have found something very interesting and worth the effort of the test setup.  Now it's just a matter of adding the parts of data you excluded back into the test and see what causes the problem.

[yacoub 0]

hi guys,

 

re installed asn and pmdg as advised, flew KATL to KLAX, only Ftx global and both scenery enabled, flight done Under time compression cause Gmt+1( late for me) , landed at KLAX with 0.6 gb remain, no outside view during the flight only a couple at KLAX , so you expert what do you think ?? did i resolve my oom issues !!

 

Sid

[tf51d 284]

Just curious, how many people who are running a 64bit OS (Win7, 8,8.1,etc) with a 1GB video card, are having OOM issues like described in this thread, and how many don't have any issue, especially with the NGX or 777?   Versus those with 2GB cards?

[downscc 1,328]

I didn't have an issue with OOM when I had my old 512MB ATI card, and I did with my new 2GB GeForce.... I would like to know why you think video memory would interract with the 32b applicaiton VAS limit of 4 GB.

 

Also Tom, full names in the PMDG forum please.

[CaptKornDog 290]

hi guys,

 

re installed asn and pmdg as advised, flew KATL to KLAX, only Ftx global and both scenery enabled, flight done Under time compression cause Gmt+1( late for me) , landed at KLAX with 0.6 gb remain, no outside view during the flight only a couple at KLAX , so you expert what do you think ?? did i resolve my oom issues !!

 

Sid

Under time compression, I'm not sure your test is valid. You may have just simply "out run" any impact or depletion of VAS. For the purposes of this thread and what I'm trying to collect data on, you really need to fly 4-6+ hours in real time and pay attention to your VAS usage throughout. I try to take VAS

measurements between TOC and TOD every 15 minutes.

[yacoub 0]

 

Ok Kapt, just don t give up all together we will achieve our aim

[tf51d 284]

I didn't have an issue with OOM when I had my old 512MB ATI card, and I did with my new 2GB GeForce.... I would like to know why you think video memory would interract with the 32b applicaiton VAS limit of 4 GB.

 

Also Tom, full names in the PMDG forum please.

DX9 Applications will store a copy of video memory within it's own APP virtual address space, so the more video memory you have the larger the chunk of VAS it eats. So if you have 1 1GB card, the most the app can allocate is 1GB for Video memory, leaving the remaining 3GB of VAS for the App (64bit OS, 2GB for 32bit OS). If though you have 2GB video memory on your card, the app can allocate up to that amount, potentially leaving the same 2GB VAS for the App, as with 32bit OS.  In theory DX10 makes this copy unnecessary, but the application has to setup for it not to make it's own copy or not define the allocation as lockable. Since DX10 was implemented after FSX initial release and then only as preview, I would bet this was not done in FSX,  Which is why people running DX10 while more efficient then DX9, isn't seeing large amount of VAS gains, which they shoud if the app, didn't allocate it's own copy of video memory in it's address space.

 

Tom Cain

 

http://support.microsoft.com/kb/940105

[downscc 1,328]

Okay, I see where you are coming from however at the end of the article it mentions that Microsoft 'is changing' the way that video resources are allocated. Since this was written during the Vista era, I assume that current WDDM in Win7-10 avoids the problem. Could be a bad assumption, or people running DX10 don't see the difference from DX0 users because my assumption is correct. Interesting.

[pcubine 143]

Since the issue Kyle and I am having has been narrowed down to AIRAC 1502 into KLAX, I have submitted a ticket to PMDG support. I will let you know the outcome. I will continue to use 1407 V2 for the time being.