Excessive VAS usage in P3D V3.4 triggered by OPTIMIZE_PARTS

[Guest]

 

 

LM would be aware of this and then hopefully they will also be able to address the problem rather quickly without having to find too much time finding the culprit.

 

It's not that simple Richard ... you'll just have to trust me on this ... LM can't replicate any VAS issues in their base no add-on setup, neither can I replicate any VAS issues on a base install.  It's the introduction of 3rd party products where the VAS issues surface and LM do NOT have access to 3rd party source files (it's rare LM will get 3rd party source files) and/or tools used ... this makes it very difficult to find the "culprit".

 

There has been much added to P3D V3.4 under the surface including VR support, what if the culprit is VR support?  There are just so many new features both visible and not visible that it could be.   In computer science there is no "gray" area, it's all black and white, there is a very specific cause and effect and finding the cause in a very complex threaded environment with all kinds of 3rd party tricks and tweaks it's extremely difficult and sometimes the reality is the effort to find the cause may just be beyond "acceptable" in terms of project timelines.  And what if the fix doesn't actually come from LM?  It's best NOT to make any assumptions, as a long time programmer for 34+ years, assumptions have always been my downfall with no exceptions ... it's a lesson that sometimes still catches up with me today.

 

The more information provided, the more likely that ticket "might" stay open and help LM narrow down the world of possibilities.  I'll admit, too much information can sometimes be bad ... but LM have pretty good information filters.

 

Cheers, Rob.

[vbazillio 2,317]

If it can help :

- Optimize_Part=0 -< VAS Free = 2023 Mb

- Optimize_Par=1 -> VAS Free = 1792 Mb

[edpatino 1,971]

It's not that simple Richard ... you'll just have to trust me on this ... LM can't replicate any VAS issues in their base no add-on setup, neither can I replicate any VAS issues on a base install.  It's the introduction of 3rd party products where the VAS issues surface and LM do NOT have access to 3rd party source files (it's rare LM will get 3rd party source files) and/or tools used ... this makes it very difficult to find the "culprit".

 

There has been much added to P3D V3.4 under the surface including VR support, what if the culprit is VR support?  There are just so many new features both visible and not visible that it could be.   In computer science there is no "gray" area, it's all black and white, there is a very specific cause and effect and finding the cause in a very complex threaded environment with all kinds of 3rd party tricks and tweaks it's extremely difficult and sometimes the reality is the effort to find the cause may just be beyond "acceptable" in terms of project timelines.  And what if the fix doesn't actually come from LM?  It's best NOT to make any assumptions, as a long time programmer for 34+ years, assumptions have always been my downfall with no exceptions ... it's a lesson that sometimes still catches up with me today.

 

The more information provided, the more likely that ticket "might" stay open and help LM narrow down the world of possibilities.  I'll admit, too much information can sometimes be bad ... but LM have pretty good information filters.

 

Cheers, Rob.

 

Thanks, and it looks like a reasonable explanation.

 

If I was LM I would look to the changes made to the platform in v3.4 in respect to previous versions, i.e. v3.3 and v3.2 on which VAS was "under control". The issues of access to commercial add-on information is nothing new for LM or particular to them in v3.4, but it is, as you said, a previously existing and ongoing situation. I tend to think that LM should have strong evidence or information as for the "culprit", if they look carefully into the additions or changes they've made to P3D in v3.4, relative to versions v3.3 and v3.2, and measure their relative impact on VAS consumption.

 

I remember well that more or less similar situation occurred one year and a half ago with past version v2.5, which had a lot of issues regarding high VAS consumption, compared to previous v2.4 and v2.3 versions. As we all know, with the arrival of the new v3.0 last September 2015, most of the issues with high VAS consumption were solved.

 

I wouldn't like to look a bit rude or sarcastic here, but I don't want to think LM is preparing or paving the way for us to think that a 64-bit version would be the ultimate solution to all VAS-related issues, and will force us to rush for its upcoming 64-bit P3D version, that of course will break all of the commercial add-ons we do have access to.

 

Just my thinking and do hope my opinion will not hurt anybody.

 

Cheers, Ed

[WebMaximus 372]

I don't want to preach to a choir, but I think it's never-ending catch-and-release game until we see truly 64bit platform. They will fix now, but break again on 3.X or whatever :-) Anyway, I can live with "saved" scenario for now as I'm not going to sacrifice on visuals.

 

I agree we will never see the VAS issue fully solved as long as the sim is based on a 32-bit platform but I do prefer a 32-bit version of P3D that will keep me on the right side of the VAS edge such as 3.3 rather than a version such as 3.4 that will from time to time leave me dangerously close to the wrong side of the edge.

[downscc 1,327]

Something I have noticed about VAS in 3.4 that is different is that when new textures are loaded there is a surge in VAS usage that quickly returns to pre-change or lower; however, during the transition period the large 200-300 or more increase in VAS load can trigger low VAS alarms or even a OOM event.  I just had one with a PMDG 777 at a Flightbeam KSFOHD gate.. my VAS load at the gate was about 3.6 GB and I changed the date/time.  While the new textures was loading the application hit the OOM wall and closed without error message.  I was watching the VAS with Process Explorer which indicated 4200 (4GB) when P3D closed.  I do not recall earlier versions having this significant bump in VAS load during texture loads... there was a perturbation but this is a tsunami. Its as if the new textures are loaded in memory along with old textures, which are then removed after the procedure and the new is rendered.

[odourboy 1,290]

Looking at Rob's second scenario (to test freeing of VAS with third party sceneries) I decided to first test with a 'vanilla' P3D scenario. I turned off ALL scenery add-ons. Positioned the F-22 at Newark KEWR and after loading and performing 360 degree views VC and exterior, recorded total VAS used as 2.370 Gb. I took off and flew over NYC then headed toward KJFK. Above JFK, I noted 2.495Gb VAS in use. I then headed out over open water at heading about 110 degrees FL350, at 'supercruise' for 90 min. I then paused the sim, saved the scenario and noted the VAS used as 2.551Gb. (So, apparently NOTHING released from the busy NYC area). I then reloaded the scenario (now 1000 miles out at sea) and after flying for a few minutes and doing the 360 degree views, I noted the VAS used was 2.009Gb - almost 550Mb less than the same state I left the sim in before reloading.

 

Seems pretty clear to me that resources are not being released that 'could' be and it has nothing to do with add-ons. I'm not a Windows expert by any means, but my observations may be due to how Windows is managing memory, not P3D.

[WebMaximus 372]

It's not that simple Richard ... you'll just have to trust me on this ... LM can't replicate any VAS issues in their base no add-on setup, neither can I replicate any VAS issues on a base install.  It's the introduction of 3rd party products where the VAS issues surface and LM do NOT have access to 3rd party source files (it's rare LM will get 3rd party source files) and/or tools used ... this makes it very difficult to find the "culprit".

 

There has been much added to P3D V3.4 under the surface including VR support, what if the culprit is VR support?  There are just so many new features both visible and not visible that it could be.   In computer science there is no "gray" area, it's all black and white, there is a very specific cause and effect and finding the cause in a very complex threaded environment with all kinds of 3rd party tricks and tweaks it's extremely difficult and sometimes the reality is the effort to find the cause may just be beyond "acceptable" in terms of project timelines.  And what if the fix doesn't actually come from LM?  It's best NOT to make any assumptions, as a long time programmer for 34+ years, assumptions have always been my downfall with no exceptions ... it's a lesson that sometimes still catches up with me today.

 

The more information provided, the more likely that ticket "might" stay open and help LM narrow down the world of possibilities.  I'll admit, too much information can sometimes be bad ... but LM have pretty good information filters.

 

Cheers, Rob.

 

Got it Rob and I do realize how hard it must be to tackle an issue like this one when you don't even have access to the same add-ons the general public has.

 

However I don't understand why that is the case. Why can't LM just get the add-ons needed to have a more "realistic" workbench to troubleshoot on? Or maybe the problem is the add-on itself won't help them but instead they need the source files/code like you mention?

 

If that is the case one would like to think the developers of these add-ons should be more than happy to have LM help them out sorting issues related to their own products making them not run OK in P3D? I know you said not all developers are willing to share the required code with LM, I just can't understand why? Are they afraid LM will steal the code from them?

 

Not sure if it will be of any help and maybe it was already mentioned/tested but I did a test before I went out for about 1.5 h by leaving P3D open with the NGX standing at gate 5 at ESSA and when I returned the VAS hadn't changed with as much as 1 KB...it was exactly the same when I returned as it was when I left it. To me that would indicate at least it's not a general memory leakage problem but rather has something to do with how the VAS is managed when P3D is actively used with new scenery being loaded etc etc.

 

Well...let's see how things turns out in the end. If LM won't be able to find and fix whatever is causing this VAS issue in 3.4 I guess the only option will be to revert to 3.3 until there is a 64-bit version of P3D where at least the VAS issues will hopefully be all forgotten.

[Guest]

 

 

however, during the transition period the large 200-300 or more increase in VAS load can trigger low VAS alarms or even a OOM event

 

Hi Dan, yes, that corresponds to my findings I described with video link earlier in this thread here. However, this issue was present in V3.3 also, it's not specific to V3.4.

 

 

 

Seems pretty clear to me that resources are not being released that 'could' be and it has nothing to do with add-ons.

 

You can't jump to that conclusion, there are still other things it could be as we have DLL.XML and EXE.XML entries, mesh entries, etc.  etc.  I have tested default NO add-on P3D V3.4 and VAS usage started higher, dropped lower over ocean, and then increased back to normal over populated area.  It also depends on where you fly relative the "zone" map on how the virtual world is segmented into Regions (why Europe is often a hot spot for VAS issues as it can straddle many dense populated regions from a single position).

 

Cheers, Rob.

[WebMaximus 372]

Something I have noticed about VAS in 3.4 that is different is that when new textures are loaded there is a surge in VAS usage that quickly returns to pre-change or lower; however, during the transition period the large 200-300 or more increase in VAS load can trigger low VAS alarms or even a OOM event.  I just had one with a PMDG 777 at a Flightbeam KSFOHD gate.. my VAS load at the gate was about 3.6 GB and I changed the date/time.  While the new textures was loading the application hit the OOM wall and closed without error message.  I was watching the VAS with Process Explorer which indicated 4200 (4GB) when P3D closed.  I do not recall earlier versions having this significant bump in VAS load during texture loads... there was a perturbation but this is a tsunami. Its as if the new textures are loaded in memory along with old textures, which are then removed after the procedure and the new is rendered.

 

Not sure if I maybe already mentioned it but I had a similar experience where my VAS on short final into ESSA all of a sudden jumped from about 350 MB left to about 130 MB left or something like that.

 

Of course the VAS alarm in FSUIPC went off and I was positive I would have an OOM CTD but after like 2-3 seconds the available VAS jumped back to even more than before like somewhere around 400 MB or so.

 

Never seen that behavior before...a jump from about 350 MB down to just above 100 MB and then back up to like 400 and all of this within a couple of seconds.

[G-YMML1 584]

In my case, I'm having issues with PMDG birds only. Surprisingly AS Buses can handle 3-4 hours flights in v3.4 easily without a need to save/reload a flight and typically I'm having AT LEAST 800Mb leftover at EDDFv3 (P3D VAS hog champ) and ~1.1-1.3 in less demanding airports such as FSDT or FB 

[Guest]

 

 

However I don't understand why that is the case. Why can't LM just get the add-ons needed to have a more "realistic" workbench to troubleshoot on?

 

LM do have many 3rd party add-ons and do test with them, but if they did see a possible issue they might need the actual "source" files used by 3rd party developer ... "source files" means files that aren't released with product, these are files used with SDK to produce compiled files that are released with product.  3rd party compiled files (what you and I get in a released product) may not help LM much if they need to know how something was specifically set before the SDK is used to compile output.  These are the 3rd party "source" files I'm referencing and naturally, 3rd party will be somewhat protective of these files as it's the key to their product.

 

Cheers, Rob.

[odourboy 1,290]

Hi Dan, yes, that corresponds to my findings I described with video link earlier in this thread here. However, this issue was present in V3.3 also, it's not specific to V3.4.

 

 

 

 

You can't jump to that conclusion, there are still other things it could be as we have DLL.XML and EXE.XML entries, mesh entries, etc.  etc.  I have tested default NO add-on P3D V3.4 and VAS usage started higher, dropped lower over ocean, and then increased back to normal over populated area.  It also depends on where you fly relative the "zone" map on how the virtual world is segmented into Regions (why Europe is often a hot spot for VAS issues as it can straddle many dense populated regions from a single position).

 

Cheers, Rob.

 

Right. Well I did say I turned off ALL scenery and I did turn off ALL scenery - no mesh, no libs no nothing that wasn't part of the default install (never added GEX or FTX Base to my P3D, so even the scenery textures are default AFAIK). However, the dll.xml and exe.xml entries were still active during my test. So, they're ALL gone now, and what I'm running is as close to a virgin install as possible, short of actually doing an install. :-)

 

I've started another run and just aimed the F-22 out over the sea at top speed with unlimited fuel. It'll reach Europe in a couple of hours and I'll be monitoring the VAS throughout the journey. So far, now that I'm out over open water, it's holding at 2.215Gb in use.

[WebMaximus 372]

Thanks Rob but I do know the difference between a source file and a compiled file :smile:

 

If I was a developer of an add-on that didn't work OK with the latest version of the platform most of my customers are using I would be happy to share any source files needed with LM to have the issue solved and in fact I would be grateful they are willing to help out sorting an issue potentially caused by my product.

 

What I wouldn't do is to share the same files with other developers developing same kind of add-ons I develop unless I trusted them by heart.

[cannow 61]

Glad to see this thread and thanks to all the people who have contributed so far good work . I will feed back some vas comparisons as soon as my work schedule allows me . What a difference a few days makes . I posted on the 3.4 thread many issues discussed here  only to be told to go away learn how to install my add ons and chuck out the computer I had just built and programmed, for info I was a day one  purchaser of p3d2 and have fed loads of info back to LM in the past . Luckily Beau at LM takes a better view of peoples comments on the LM threads . Anyway this is a difficult subject to tackle and fix good luck with the testing will feed back some info  myself soon.

[jabloomf1230 2,445]

Aerofly 2 --> 64 bit

XP10 --> 64 bit

DTG Flight Simulator (presently vaporware) --> 64 bit

 

Eventually, these three will take over the market if LM doesn't do something fairly soon. I don't even bother with long flights with the triple 7 anymore. It's just too iffy as to whether I'll finish them.