v2.1 OOM test: three conclusions

[Guest]

I tested OOMs this afternoon, focusing on vegetation.

 

I set up a flight with the A2A C172 on autopilot above Australia with FTX Global installed (so not FTX AU, which I have removed). I set vegetation autogen at Extremely dense to force OOMs. All other settings were as I usually have them (quite medium).

 

I saved the flight in mid air. The view was the main VC view. After loading the flight (each time after a complete restart, of course), I would wait for a minute and then I would look around with the hat switch, 360 degrees, 4 times in a row. After 2 minutes I would set time accel to 2x. After 3 minutes I would look around 4 times 360 degrees again and I would do the same after 4 minutes and then every 30 seconds. I had TrackIR disabled to make sure each test would be the same as much as possible.

 

Here are the results:

 

With Orbx trees enabled: OOM after around 3 minutes.

With Orbx trees disabled: OOM after around 5.30 minutes.

 

Conclusion 1

Orbx trees lead to an OOM a lot sooner because they either are heavier on the system or because they are more diverse. Or both. Or they are coded wrong somehow (don't ask me how). In anyway, default trees take longer to trigger an OOM! And so disabling Orbx trees will enable you to fly longer before you get an OOM! Until Orbx solves this problem, I will be using default trees (because the 'solution' to set autogen to sparse isn't an option for me!).

 

One thing that became very obvious after doing these tests (I did them at least three times with Orbx trees enabled and disabled) was that the OOM ALWAYS occured whenever I was looking around 360 degrees with the hat switch! So... I decided to see what happened if I would NOT look around at ALL. I only tested this with Orbx trees DISabled. (And again, no TrackIR.)

 

Here is the (rather shocking) result:

 

With Orbx trees disabled and NOT looking around: OOM after 19 minutes. (I might test this again with Orbx trees enabled but I'm done testing for now.)

 

Conclusion 2

Looking around a lot clearly increases VAS. And this leads me to conclude that using TrackIR may have an effect on VAS and OOMs. Could it be that those people who hardly have OOMs are NOT using TrackIR or at least not changing views that often? This also could mean that people who have three screens and hardly ever look around, have less OOM problems.

 

Conclusion 3

Up to now people would simply say "I don't have OOMs and my setup or is similar to yours". But it's obvious now that having OOMs is not only due to your PC or your addons, it's also influenced a lot by how you actually use the sim. If you use TrackIR or not. If you look around or not. If you use more screens or not. If you change views a lot.

 

Discussing problems (and solutions) on a forum is hard as it is already, but it's even harder if you don't take into account EVERY aspect. And I think we quite often do NOT take into account every aspect: in all the OOM discussions up to now I haven't read anything about for instance using TrackIR or not! We may sometimes THINK were are comparing apples with apples while we are in fact, without knowing it, comparing apples with oranges because we overlooked a few aspects.

[WR269 367]

interesting, would love to know why the different mileage. I have just finished a flight from SY to ML with Orbx AU4, FTX GLOBAL, Orbx ML airport, Rex4, Coolsky DC9, autogen set to sparse. no reflections, tessellation off, shadows send and receive in the cockpit, and had no problems, no stutters, and this is my 5th flight in 2 days, no OOM.

 

and I really dont have a fancy pc at all.

[RWFeldman 159]

Again, It just delays the inevitable, frees up more VAS initially and it should be enough to complete a flight.. Still have a leak somewhere if VAS degrades. If the VAS meter is counting down, setting or flying, there is a leak. If it doesnt, during flight the only VAS effects will be external views and loading of arrival airport.

 

My suggestion is to set at an airport and monitor your VAS meter.

[FINXPAS 5]

I'd call this a garbage disposal problem. The objects are not flushed after use, they just pile up like in a clogged toilet drain pipe using precious memory.

 

The bigger the poop, the faster the OOM. LOL

[peppy197 165]

Sparse veggies now works for me very well indeed

 

with FTX_Vector

[rparson99 32]

Unless there is a literal bug somewhere in the code, what we are witnessing with these OOM's is simply the status quo...based on the current ability of the VAS engine, no?   The way I see it, P3D2 with directx11 has replaced that 2cycle engine with a V8!!, but the transmission is still the same!   So every time there is an OOM some where, that's someone's clutch popping! lol

 

So my perspective is, this is less a bug and more an area that needs focus in the coming patches.  With FSX we were CPU bound, Then came P3dv2 and many of us found ourselves to be GPU bound (until we get up to speed with the latest video cards), but beyond that...with all the graphic splendor now achieved we are all still VAS bound!

 

The engine needs more tuning and or additional features.  The problem is not insurmountable.  All that is needed perhaps is a means to flush stale VAS content at a higher rate or put an OOM monitor in place that will flush VAS (even if not stale) before an OOM is reached.  I'm sure the crack team at LM can do that.  It would still be left to all 3rd parties to optimize their stuff...but at least the sim will not quit.

[FINXPAS 5]

You put the proverbial finger on the problem. Get a crack team at LM to concentrate on the stale VAS flushing issue. The input is greater than the output resulting in OOMs and gastric issues for everyone

[Guest]

Another test and conclusion: I uninstalled FTX Global and P3D v2.1 (and manually removed every trace of it). After wiping my P3D drive, I reinstalled P3D v2.1 and did the same test as described in the OP. Same results. OOM within a few minutes. It seemed to happen even quicker than woth FTXG and default trees! I don't have exact times though because the reinstall of everything reset a few things in the A2A C172 so I was focusing on keeping the plane airborne but anyway, the OOM was there before I expected it.

 

So P3D 2.1 itself (still) has some serious problems and we can't simply blame it all on addons!

[Petraeus 147]

I'm sure FINXPAS is right about inadequate flushing leading to VAS depletion. But something very specific seems to have been introduced between 2.0 and 2.1. There is now even less flushing going on, or there is more demand on the facilities. To pursue his analogy, the vegetation slider looks like a new and additional source of poop.

[MarkSC 122]

OOMs are clearly an issue for some, but my guess is a minority. No OOMs for me unless autogen is set to very dense or higher. I fly with high settings using win 8.1. Even at very dense autogen, OOMs take far longer to occur for me with 2.1 than 2.0.

[mganz121 159]

 

 

We may sometimes THINK were are comparing apples with apples while we are in fact, without knowing it, comparing apples with oranges because we overlooked a few aspects.

 

Hi Jeroen. You have hit the nail on the head. I was going to add to your thread about your testing at Lilydale airport in NSW, but couldn't find it, so I will add my comments here. Using Orbx AU I flew around the area for 4 hours, down to Melbourne and did a couple of touch and goes, back over Melbourne City and landed back at Melbourne. Paused the sim for 3 hours and went out for dinner. Unpaused and flew back to Lilydale at 4,000 feet. So 8 hours all up and no OOM. Scenery is set to dense, LOD to maximum, Vegetation to sparse. I tried to create as close to your original scenario, BUT, I used the Alabeo C172RG and kept vegetation to low. I do not use TrackIR, but constantly panning around the cockpit and occasionally watching from the outside. Thats on an i5 rig overclocked to 3.3 and with a 560Ti, frames set to unlimited. VAS never went above 2.8.

 

Go figure ???? It is beyond me. The only thing I did notice (or assume) was a slight drop in frame rates in the same area over time. It really is beyond me.

[DylanM 1,069]

Jeroen, have you tried the test with something other than the A2A 172?

[gboz 157]

Anyone doing a complete re-install should take the opportunity to test with default everything and that includes planes.

 

The A2A 172 with it's accusim engine would be one of the worse choices I think.

 

gb.

[spirit_66 2]

@all

Let me tell you my experience with OOMs in P3D v2.

 

First of all I don't have any OOMs but I know now how I can get them!

 

With all the talks about VAS and OOMs I became curious to get knowledge about the VAS on my P3D v2.1 together with my hardware. So I started yesterday to monitor it with FSUIPC4.

 

I regularly fly in the Sitka (PASI) area and only with helicopter (Dodo 206, Huey etc.). Now I saw that the shown VAS was about 2+ GB and dropped a little bit to about 1.8 GB. OK, fine what else should I expect with never having OOMs?

 

Well, so I decided to take a flight with a standard fixed wing and chose the Mooney G1000 which comes with P3D v2.1. I also decided to fly at another location which I also like. EDOG is a German Freeware airstrip and the designer claims its P3D v2.1 compatibility. http://simmershome.de/scenery-edog-torgau-beilrode-fur-fsx-und-prepar3d/

 

I started always the flights cold and the VAS was about 1.5 GB and dropped during the flight to about 1.2 GB. What I immediately noticed was that when I reached the end of the autogen radius that no new objects (trees, buildings) were built up and the area looked blur. Now what? How comes this odd behavior? Firstly I thought it's only blur and I remembered that some talks were about this together with the Affinity Mask.

 

On my rig HT is ON but I was curious to know how it will work wit HT OFF. As I always have an AM in the cfg-file I had to change the AM there. The Hex Core needs something like AM=1364 and with HT OFF I should have set it to AM=62 but mistakenly set it to 63 (all cores on).

 

-Hex Core, HT off in BIOS, OR non HT processor

• 62 = 111110 - Donot use windows core
• 63 = 111111 - Use windows core

 -Hex Core, HT on in BIOS, Donot utilize HT

• 1364 = 10101010100 - Donot use windows core
• 1365 = 10101010101 - Use windows core

-Hex Core, HT on in BIOS, Utilize HT

• 4092 = 111111111100 - Donot use windows core
• 4095 = 111111111111 - Use windows core

The flight after these changes was a surprise because now the autogen worked very well - but .... the VAS dropped permanently and before the end of 10 minutes I got the first FSUIPC4 warning sound at about 270 MB VAS!!!

 

I saw now that my AM was 63 instead of 62, so I changed this and started another flight. Now the VAS was kept constant but the autogen didn't work again. Even deactivating the AM statement didn't give me the autogen. I switched back to HT ON in BIOS and checked now with AM 4095.

 

Autogen was working again but VAS dropped and was emptied in about 10 minutes. I tried 4092 and again my common 1364 with the result of lasting VAS without autogen.

 

I tried some different settings with autogen higher then my "dense" but it didn't change the autogen behavior only VAS was lower. Changing the autogen radius from 6.5 to 4.5 also didn't give me the autogen but VAS was a bit higher.

 

By the way, I also deactivated the EDOG add-on scenery but got the same result with the standard P3D v2 scenery.

 

Now I started a flight again in PASI with my helicopter and took a long straight flight towards the mountains to see if the autogen will also disappear after the first radius. It didn't disappear and came up smoothly and steadily. I could see the trees appearing at the mountains - not popping - very smooth and the VAS very solid at 1.8 GB.

 

I still have no clue what the reason for this two very different effects are. Around EDOG is an absolute flat area and Sitka is mountainous. Can this be a reason?

 

I didn't use any weather injection for the tests and I don't have a TrackIR. The Mooney is standard but the Dodosim 206 is migrated with EMT. I like to fly in spot view (outside view) and I never turn the view at 360 degrees. Tongass+, Vancouver+ and Victoria+ were installed with EMT.

 

Maybe my accidentally discovery can give somebody else some hints for further research.

 

I for myself switch off the VAS monitor now and fly again at Sitka without any trouble as before till I can install the compatible PNW, SAK etc. ORBX sceneries.

 

Spirit

[Guest]

The A2A 172 with it's accusim engine would be one of the worse choices I think.

 

 

I ONLY used the C172 because I knew it is heavier on the system than default planes: I wanted to force an OOM and check the difference between default vegetation and Orbx vegetation. This wasn't a test to check if P3D would give me OOMs or not: everyone knows you can make P3D OOM with the 'right wrong' settings. I know how to avoid OOMs. Nevertheless I have to conclude that OOMs happen too soon: being forced to set Autogen to Sparse in order to do long flights is ridiculous imho.

 

 

but .... the VAS dropped permanently and before the end of 10 minutes I got the first FSUIPC4 warning sound at about 270 MB VAS!!!

 

http://forum.avsim.net/topic/435259-to-all-vas-and-oom-testers-that-use-fsuipc-for-monitoring/

 

^_^