Possible new VAS issue in v3.4

[Hanse]

Let us go back to the subject "Possible new VAS issue in v3.4" and not talking about OOMs in generally. In the mean time I did some other test flights and the generally behaviour is allways the same - only the VAS values differ based on the various P3D settings (or disabled addons) I tested. And this result is also valid for 3.3 - so not specific to 3.4!

- During CLIMB the VAS increases between 200 (with a lot of scenery) and 100 MB (all non P3D scenery disabled)
- This additional VAS "stays" during the whole flight e. g. after reaching TC the value never goes down below this VAS
- At CRZ LVL additional VAS is coming on top - amount depending on the flight time
- During descent (before approaching destination airport) VAS increases additional
- If the flight is saved midair and reloaded again there is a big VAS difference. On a longhaul flight even up to 1.300 MB!

Lowering settings or any other suggestion to decrease VAS used is just a workaround for this problem........ I do not know if the behaviour is different based on the various OS used. I use Windows 7 64-bit but heard that Windows 10 should have a much better memory management? Can somebody maybe confirm this?

Regards,
Rolf

[Raphael_Chacon]

I use W10 64bits, and i can say performance is exactly as you describe.

In my case(due to a reason im looking for) i start with very high VAS, apparently due to KIAD(Flightbeam)+ ASN? Dont know, hope someone with simmilar setup help me through this post, because at OOM Point, im not affected by sveral addons, and after OOM point and reload, i have ORBX PNW + KDEN Flightbeam and still have mutch mutch less VAS than before..... so.... Sceneries? Or VAS increase problem? The interesting part is that after reloading at same OOM point and flying the 2 hours above PNW on my way to KSFO, again!, at some point, VAS increases until OOM.... so yeah, 2 OOMs before reaching KSFO. I mean, not something i had before... Im used to perform long hauls very very often and i havent had this behavior before...


For your description i would add:

- During all phases of flight, depending on camera cycling usage you VAS will increase and add that workload number to the general VAS amount you had. After some time of flight, if camera cycling was aggresive, VAS continually increases until OOM very rapiddly compared to "non/limited camera cycling usage" behavior.

+1 on the Midair save reload. THis is my flight during OOM:




This is my flight after reload exactly in the same position:



Near 1400MB difference? Clearly proves the statement.

At this point, im bored of testing during the whole week, day after day... Weird

[GAEA]

I think Hotfix 2 is worse. I am still having OOM issues on the route between KMIA (LatinVfr) - KATL (ImagineSim) - KIAH (FSDT).

I think we wait to much for LM to get nothing.

Merry Christmas to all of you, and we will hope best news for 2017. Continue testing is lost your time...

Regards,

[Martyson]

I did a one hour flight this morning P3D HF2 (did screenshots if needed).
My full specs on page 4 of these posts
Win7-64
FSGRW
PMDG 737-600
KPHX (FlightBeam) KLAX (FSDT)
KPHX IZZZO5.MESSI PKE TNP.SEAVU2 KLAX
FL340


FSUIPC VAS (remaining) reports
******************************
Results: VAS increased and decreased during the flight.

Takeoff
1937528

17500 feet
1965272

TOC
1977720

PKE (Cruise)
1978128

PAUMA (TOD)
1972452

4000 feet G/S active
1813140

Landed KLAX (VAS remaining)
1646544

VAS used during the flight:
290,984 MB

[Raphael_Chacon]

You will not believe this.

Repeated KIAD-KSFO(my test flight) and i just passed the critical point near Denver.

What i did?

- Put my REX TD clouds to Maximun resolution and 32 bits(No soft clouds at this point, but i have it installed).
- Very limited camera cycling
- Set my sliders to the limit.
- And, very important for this night flight --> Set ASN to default. The major change is the upper visibility. I had it to 50-60 NM, but seems to be better at default 200NM because uses less layers? My god.... this is what i would call the VAS Hunger games...

Will send you some pics in a while of the full config. BTW i discovered that there is something to do with night flying... I flew from EGLL-KJFK few weeks ago and no problem, but when arrived it was night time, and i reached VAS limit(Not OOM).

Well, so far this is it... in any case, not common, not normal...

[acccro14]

I have a Hotfix 2 problem. Hotfix 1 was perfectly OK. So, yesterday I did (or at least I tried to do) a VHHH to OMDB in Blackbox a330. 2 hours into the flight, an OOM. I thought at first it's a bBackbox problem, and decided to do a different flight today - VHHH to YSSY. And again, 2h into the flight, an OOM. I could perfectly do a flight like EHAM to KATL or EHAM to OIIE.... I think I'm going back to 3.2 because it's the most stable for me, untill this issue resolves

[Raphael_Chacon]

All right,

This is the KIAD-KSFO Nighttime flight review after 6 attemps during the whole week.

My settings:
1 2 34 5

Flight:















What i did:
1- Put my REX TD clouds to Maximun resolution and 32 bits(No soft clouds at this point, but i have it installed).
2- Set my sliders to the limit(My original Config)
3- Set AS16 to default. The major change is the upper visibility. I had it to 50-60 NM, but seems to be better at default
200NM because uses less layers? My god.... this is what i would call the VAS Hunger games...
4- Very very limited camera cycling during TO and absolutely no cycling during flight.
5- Grabed a 64 bits beer and let i go!


Well, be the judge...

[Raphael_Chacon]

Well, i decided to make it like before, Daytime and back KSFO-KIAD and test my theory:



Ooooops - OOM about to land KIAD


I understand why i havent ever had this before. I couldnt set my old PC to this settings(i5 3.5Ghz, 8GB RAM, HDD 580GTX), so i kept everything off and sliders low. If i`d fly KIAD-KSFO, simple, i did not own Flightbean Scenery, and in order to fly through ORBX Regions, i used to disabled them, because for sure itll be an OOM.

Now that i have a High end watercooled super space system(i7 6700K OC 4.6Ghz/32RAM/SSD/MSI1070GTX), i`ve been lucky to finish some flights using the strategy: No camera cycling, moderate sliders and tweaks, and i have barely able to perform my flights reaching to the end by listening the VAS warning BEEP my pc was playing(I didnt know what that sound was, so i ignored it at the begining). Now that im measuring it, i understand it was a matter of luck really...I knew i could flight the B772 not disturbing camera cycling too mutch and i was not using so aggresive tweaks and vitamines... May be it is worse now the code? Or better?

In the best case, the same: VAS Hunger Games...

[Hanse]

Let us go back to the subject "Possible new VAS issue in v3.4" and not talking about OOMs in generally. In the mean time I did some other test flights and the generally behaviour is allways the same - only the VAS values differ based on the various P3D settings (or disabled addons) I tested. And this result is also valid for 3.3 - so not specific to 3.4!

- During CLIMB the VAS increases between 200 (with a lot of scenery) and 100 MB (all non P3D scenery disabled)
- This additional VAS "stays" during the whole flight e. g. after reaching TC the value never goes down below this VAS
- At CRZ LVL additional VAS is coming on top - amount depending on the flight time
- During descent (before approaching destination airport) VAS increases additional
- If the flight is saved midair and reloaded again there is a big VAS difference. On a longhaul flight even up to 1.300 MB!

Lowering settings or any other suggestion to decrease VAS used is just a workaround for this problem........ I do not know if the behaviour is different based on the various OS used. I use Windows 7 64-bit but heard that Windows 10 should have a much better memory management? Can somebody maybe confirm this?

Regards,
Rolf

I would like to add one additional issue (also mentioned by Raphael) but a little bit more specific:
- If you use various camera positions p. e. already before TO (still on the runway) this alone adds app. 150 MB to your VAS. Any you will never get this VAS back after TO and during the whole flight.

This states again for me that there is a severe memory management problem in P3D v3.4: A lot of VAS is added by various actions but never released in total - mabe just a bit. And the longer the flight the higher is the VAS mostly occupied by "garbage". This is definitly proven by the fact that relaoding a previous saved flight at the same position frees several hundred MB of VAS. A P3D 64-bit version with the same behaviour would also be just a workaround and not a solution. The only difference would be that nobody will care anmore about VAS.

It would be nice if somebody from LM finally would comment on those findings......

Regards,
Rolf

[pcw291]

Well, today I decided to give one more shot to P3D 3.4 and did full reinstall of the newest version.

I manually deleted all the folders left by P3D, defragmented hdd and then installed the simulator. I had to uninstall some of my 'must-have' addons like FS2CREW or ORBX Regions but I finally managed to finish my flight from UK2000 EGLL to FlyTampa EHAM, and VAS actually was going down during the flight.

My settings:




I think I can live with that until 64bit platform is gonna show up.

[Kosta]

Is there anyone posting about the OOM problem who is NOT flying PMDG 777?

[GAEA]

I posted flying PDMG 737NGX

Regards,

[gkollmann]

I mainly fly the PDMG 737NGX, that’s why I have seen most OOM’s with this aircraft.
However I also had OOM’s with the Aerosoft Airbus and even with the Majestic Dash 8-Q400 which is supposed to be very resource friendly.
The aircraft is definitely a factor but for my opinion not the main one.

Regards,
Gerhard

[acccro14]

I got an OOM with Blackbox a330

[FJeijsman]

Regularly comes the message "run out of memmory" "P3D shuts down, change your Scennery Settings"
If I choose Default settings there is no problem.

The started programs are;
Prepar3Dv3.4
Ezca
FSC96

My computer;
Windows 10 64.
Processor: Intel i7-3930K 3.2o GHz. 8 cores
Video card GeForce GTX 980
Ram 32 GB.

Information from Source Controlle
prepar3D assigned 2,265,348
Available 26,021,004 MB
There is only 2.2 GB assigned to P3D
How do I change this assignment so that I can maximize the scennery settings


Frans Jeijsman