Sign in to follow this  
RTK1972

VAS 450MByte left but OOM

Recommended Posts

Good evening,

 

Maybe someone of you can help me with an idea what to do.

 

Thing ist that while on approach into Aerosoft EGFF i have appx 450 megs of VAS left. But then i get a OOM crash.

I have no idea why this happens. With my old machine i could land even with 100 left and everything was fine.

I have out of the stock p3d.cfg with latest 3.4 version. Sometimes when i repeat this flight it is possible to land but then not all textures from the airport are loaded and they stay black.

 

No idea on this :-(

 

Thanks for your ideas !

 

Carsten

Share this post


Link to post
Help AVSIM continue to serve you!
Please donate today!

As you continue a flight, VAS not only gets used up, but it also gets fragmented. If a request for memory exceeds the size of the largest open contiguous block of VAS, the sim with either OOM or worse, crash, usually with an NTDLL.DLL error. P3d 3.4 HF2 does its best to free up VAS that is no longer needed, but it is a game that a 32 bit sim will eventually lose.

 

The only solutions are to turn down such settings as scenery LOD, AI traffic and building autogen.

  • Upvote 1

Share this post


Link to post

As you continue a flight, VAS not only gets used up, but it also gets fragmented. If a request for memory exceeds the size of the largest open contiguous block of VAS, the sim with either OOM or worse, crash, usually with an NTDLL.DLL error. P3d 3.4 HF2 does its best to free up VAS that is no longer needed, but it is a game that a 32 bit sim will eventually lose.

 

The only solutions are to turn down such settings as scenery LOD, AI traffic and building autogen.

Thanks a lot Jay for you fast answer. Will try some more scenarios....

Share this post


Link to post

The only value that could substantially impact VAS usage is the number of aircraft which you list as 100. The other three values just cause shifts in the spatial distribution of the 100 aircraft within the user's reality bubble. For example, if one is on the ground at an airport and you want to see all the traffic you would set the GroundPreference setting to 0. Setting this value to 50 gives you an equal probability that an aircraft on the ground but without clearance will either be deleted or not. 

 

If one likes to see aircraft in the air and landing around nearby airports, then the AirportPrefrence setting does this. At 0 all airborne planes will stay untouched. At a value of 50, there is an equal probability that airborne planes will either be deleted or not. The NearerPreference setting prevents newly spawned aircraft at the edges of URB from being instantly deleted. Without this setting,  the furthest away flights are always the ones being deleted.

 

Keep in mind that FSUIPC will still maintain a maximum of 100 (or whatever one chooses as a limit) within the URB. The other three preference settings just vary the deletions spatially. By using the Traffic Toolbox to monitor where aircraft are in the URB, one can fine tune the settings to match personal preferences.

Share this post


Link to post

Jay,

 

What would you say to the following:

 

The above happened with nvidia drivers 37x.x series

 

I just installed 368.69 driver and in the same scenario with the same settings i get no oom and no black textures. Nearly 450 mbyte left.

 

I really don't get it.......

Share this post


Link to post

Carsten - Windows or the applications manage the memory allocation. As Jay said - the OOM occurs because the application has requested an allocation of memory that is larger than any CONTIGUOUS block. You could have 2G of free memory but if the largest contiguous block is only 250MB and the application requested 260MB - you'd get an OOM with 2G of VAS free.

 

You could do the same steps 10 times in a row and get different results each time - just a question of timing and as long as we're 32bit, this will be a way of life.

 

 

Vic

Share this post


Link to post

Carsten - Windows or the applications manage the memory allocation. As Jay said - the OOM occurs because the application has requested an allocation of memory that is larger than any CONTIGUOUS block. You could have 2G of free memory but if the largest contiguous block is only 250MB and the application requested 260MB - you'd get an OOM with 2G of VAS free.

 

You could do the same steps 10 times in a row and get different results each time - just a question of timing and as long as we're 32bit, this will be a way of life.

 

 

Vic

yeah i know Vic, at least i thought that i know it.

I really wondered actually that there is a different behaaviour with thos two versions of display drivers...

 

I will test for myself and will see what happens and then come back.

No intention to spam the forum.

 

Thanks a lot, carsten

Share this post


Link to post

Carsten,

 

Remember when everybody had mechanical hard drives and after months of writing and deleting, the drive would get fragmented? That situation is analogous to VAS fragmentation.The difference is that even though a disk was fragmented, all that happened was that disk performance got degraded, as the OS thrashed about trying to squeeze ten pounds of poop into a 5 lb bag ( or more correctly 160 one ounce bags). With VAS, an app just hasn't a big enough block to work with and the app fails. And since the circumstances change from run to run, the results look random in nature.

 

Jay

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this