Well it finally happened, I'm not surprised given how much I've tossed at FSX in terms of 3rd party and graphics settings.

 

With UTX Enabled:

 

 

With UTX Disabled:

 

 

Doing a full flight (LFPO - EGHI) living on the Edge:

 

 

Close, but landed without incident

 

Cheers, Rob.

Lets hope that new titan will help you out :smile: looks like some background stuff should be shut down especially your spaceball how did I know that I am a 3d modeler :smile:

This is an automatic message.

 

This topic has been moved from "MS FSX Forum" to "Crash To Desktop (CTD) Forum". This move has been done for a number of possible reasons.

• The most likely reason is that the post was off topic.
  
• The topic could also have contained images or a video that were not appropriate to the original forum it was posted in.
  
• The images might not have been "illustrative" or "explanatory" in nature.
  
• The topic could have been moved because we deemed it to be more appropriately placed elsewhere.
  

Please ensure that your posts are "on topic" and contain illustrative images or videos as appropriate. Do not post videos or images just for entertainment purposes anywhere but in the screen shot or video forums.

 

Members who continue to post off topic posts can be denied entry to specific forums in order to reduce and remove the practice. Your cooperation is appreciated.

About 40 less processes may help.

Yes, I use my 3D connexion a lot for modeling, love it!

 

It's not the number of processes I have running that's the problem (I have 32GB of RAM) ... look at Private Bytes and Virtual Size for FSX ... that's the 32bit address space limit of FSX that I exceeded.

 

But in FSX's defense, I had the following:

 

FSX.CFG:

 

TEXTURE_MAX_LOAD=4096

NUM_LIGHTS=8

AIRCRAFT_SHADOWS=1

AIRCRAFT_REFLECTIONS=1

COCKPIT_HIGH_LOD=1

LANDING_LIGHTS=1

AC_SELF_SHADOW=1

EFFECTS_QUALITY=2

GROUND_SHADOWS=0

TEXTURE_QUALITY=3

IMAGE_QUALITY=0

See_Self=1

Text_Scroll=1

D3D10=1

 

[TERRAIN]

SWAP_WAIT_TIMEOUT=3

IMAGE_PIXELS_FOR_AUTOGEN_POLYGONS=2048

BATCH_AUTOGEN2=1

LOD_RADIUS=9.500000

MESH_COMPLEXITY=100

MESH_RESOLUTION=25

TEXTURE_RESOLUTION=29

AUTOGEN_DENSITY=5

DETAIL_TEXTURE=1

WATER_EFFECTS=4

 

[sCENERY]

ObjectsToBatchPerFrame=50

MAX_ASYNC_BATCHING_JOBS=4

SmallPartRejectRadius=0

LENSFLARE=1

DAWN_DUSK_SMOOTHING=1

IMAGE_COMPLEXITY=5

 

2560 x 1600 screen resolution (in window mode so I could monitor FSX mem) but maximized window

 

Add-Ons:

REX

GEX

GSX

UTX Europe

Traffic 360

Real Air Duke

FSUIPC + WideFS running and connected to another PC (FS Commander)

GoFlight (GoFlight USB control modules)

 

Disabling UTX solved the OOM, but as you can see I was very close to the limit during my Orly (France) to Southampton (England) flight. I admit I was a little surprised UTX put me over the edge.

 

Lets hope that new titan will help you out

I wasn't even hitting 2GB on VRAM (around 1.5GB) so I doubt my Titan will help ... this is just hitting the 32bit address space limit of FSX.

 

I guess the hardest part now is deciding on what Add-On to NOT use ... sadly I think UTX will get the axe unless I can make it less RAM hungry.

I'm trying to figure out how you came up with the assumption that UTX was eating up your resources (other than you disabled it and the OOM's stopped). I would think REX, especially if you have those clouds and textures set to HD (plus the fsx.cfg setting TML=4096) would be a heavy resource issue too. Then, of course, you have your display driver settings and those can also bring down computer systems. But, between UTX and REX, I would keep UTX disabled too especially since you own all the MSE V2 photoreal scenery. Regarding the best settings for UTX, you should check out NickN's guide - http://www.simforums.com/forums/topic29041.html UTX SETTINGS FOR BEST PERFORMANCE vs BEST VISUALS (at the bottom of the page).

 

I agree that the processes should not be causing any problems as FSX on a Windows 7, 64 bit system, can use up to 4GB's and the rest is used for system processes. Back in the old days, before the /3GB switch and 64 bit systems, you really had to watch what processes were running in the background.

 

Best regards,

Jim

Hi Jim,

 

Agree, they all use resources, UTX was just the most recent resource addition that put me over the top. Perhaps I should re-word my title as to avoid finger pointing.

 

Agree REX HD uses a lot of resources also and I'm NOT trying to "blame UTX" it just happened to be the one add-on that put me into OOM. Traffic 360 is another big resource/RAM user.

 

I've researched "Add-on" saturation point and from now on I will have to make my choices wisely in regards to any new "Add-On" if I want to continue with HD textures (which I do). As you can see from my listing my Private Bytes went over 3GB mark and my Virtual Size over 4GB, hence the OOM.

 

During a typical flight if I start with around 2.4GB private bytes and don't open any "new" windows (I can still change to any cockpit views and to external views) during the flight I can just stay under OOM (2.9GB) and I seem to consume about 500MB during a flight. The good news is that when I move into a Photo real scenery area it frees up some RAM (no autogen).

 

It sure would be nice to see a 64bit version of FSX and I'm certain all 3rd party vendors would also -- thinking back when FSX was being developed I was pushing Phil hard to move to a 64bit native FSX and to my surprise the 3rd party community were very vocal to not "Break anything" ... I guess I failed at selling just how important 64bit is and that nothing needed to be "broken" ... just like XP10 (that is both 32bit and 64bit) we could have a 32bit FSX and a 64bit FSX ... the 32bit being backwards compatible (for the most part) and the 64bit having only partial compatibility.

 

It's unfortunate that LM don't appear to be willing to move FSX to 64bit as a high priority ... IMHO this is far more important than fixing DX10 and/or providing DX11 support (which has never actually been confirmed). Anyway, all old news, it is what it is.

 

But the purpose of my post was really to show the "process" of OOM avoidance, not how one ultimately decides to avoid the OOM. For those running into OOMs on a regular basis (and who don't already know/use this process), you can find Process Explorer here: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx - it's not a Microsoft developed tool, but it is a trusted tool and technet is a trusted resource and it's free.

 

To work with process explorer:

1. Run FSX in Window mode
   
2. Have Process Explorer open (works best if you have two or more monitors move Process Explorer over to one of those monitors so that as you fly you can see the memory usage (suggest you sort by Process name).
   
3. In Process Explorer, right click anywhere in the column header and choice "Select Columns...", in the Process Memory tab make sure you have Private Bytes, Virtual Size, and Working Set Size checked.
   
4. Make sure you've load up all the add-ons you want (aircraft, weather, airport, ground services, etc. etc.).
   
5. Do a "flight" duration/area that you know produces an OOM (can be tricky if you use real time weather so you may want to setup a heavy weather scenario, lost of cloud layers).
   
6. Be sure to use all the views you normally would during a flight and if you use GPS window make sure you open it or if the aircraft has a GPS turn it on .. in other words setup your flight to what you think will be worse case scenario in terms of resource usage. I personally don't use the GPS as I have FS Commander running on a separate computer with WideFS communicating with it (and WideFS takes up resources but not as much as a GPS window).
   
7. Now keep an eye on Process Explorer FSX.EXE, if you are running FSX LargeAddressAware then your limit for Private Bytes will be 3GB (3,000,000 K) and Virtual Size 4GB (4,000,000 K). If you are not running FSX LargeAddressAware then your limit for Private Bytes will be 2GB and Virtual Size 3GB.
   
8. Once you understand what in FSX can cause an OOM, you can then go about deciding on a strategy to compromise a solution. That strategy is ultimately up to you ... can you live without HD textures, do really need to open a new window in FSX, can you dump your GPS, are you ok with FSX default traffic, can you drop autogen down, etc. etc. etc. -- the solution is ultimately up to you and what compromise works for you.
   

For those that don't already know, if you have FSX SP2 or Acceleration then FSX.EXE was compiled with the LARGEADDRESSAWARE option. The /3GB switch is already enabled in 64bit versions of Windows 7 and Windows 8, no boot.ini edits required. The /3GB this is needed for LARGEADDRESSAWARE to be used when FSX executes. However to use LARGEADDRESSAWARE I'd strongly suggest you have minimum of 8GB RAM installed in your PC.

 

P.S. Doesn't appear I can edit my Post Title ... if you can please do ... maybe something like "Working with OOM, process to avoidance"

? Im running UTX and my FSX is 1.5 gb. All kinds of addons and NGX running. I have 15 processes running on a dedicated FS computer and have never had an OOM!

? Im running UTX and my FSX is 1.5 gb. All kinds of addons and NGX running. I have 15 processes running on a dedicated FS computer and have never had an OOM!

 

Ok ... hoping an Admin renames my title as it wasn't intended to "bash" UTX.

 

It's more about how to work with OOM and compromise a solution ... in my case I removed UTX as it was my compromise ... I could have easily removed REX, dropped textures back 2048, reduced my LOD, etc. etc. to get some RAM back, but I chose UTX.

 

But hopefully people understand that I doubt any two environments are the same, your computer and FSX.CFG + add-ons will not be the same as my computer and FSX.CFG + add-ons ... so when someone comes in and suggests they've "never had an OOM!" it doesn't really say much outside of a detailed context. I'm certainly glad you've never had an OOM, but I hope you aren't suggesting OOM are a result of operator error?

With an LOD_RADIUS of 9.5 (yikes!) I'm not the least surprised that adding something like UTX which will increase the amount of detail you're seeing pushed you to the limits.

 

Scott

I had OOM's when running UTX, but at that time I had only 2 GB of RAM. After upgrading to 4 GB, all of my OOM's disappeared and overall performance was slightly improved. You have 32 GB of RAM, way more than FSX should ever need. I agree, turn down the LOD radius and eliminate some of those background processes. I know they may not look like they are using that much RAM, but they do place additional burdens on the CPU, especially if some of them are checking for updates while you are flying.

With an LOD_RADIUS of 9.5 (yikes!) I'm not the least surprised that adding something like UTX which will increase the amount of detail you're seeing pushed you to the limits.

 

Scott

 

Agree ... but I'm not willing to give up a LOD 9.5. I wasn't complaining, I know the limits of a 32bit address space and now it's a process of working within those limits ... I tried to outline that process above.

 

You have 32 GB of RAM, way more than FSX should ever need.

 

FSX is 32bit native application, it can never use more than 3GB private. With 6 physical cores and FSX using 4 cores I never have an OS situation that impacts FSX performance, including Windows Updates and/or other background tasks ... one of the benefits in running 6 physical cores. But don't confuse FSX RAM usage with 64bit OS RAM usage.

Agree ... but I'm not willing to give up a LOD 9.5. I wasn't complaining, I know the limits of a 32bit address space and now it's a process of working within those limits .

 

Sure, we're all going to view tradeoffs differently, and the choices are yours to make, but an LOD of 9.5 is going to fundamentally act as a mutliplier for you with ANY detailed scenery you add. It's why the impact of adding UTX was larger than you expected. I don't know what you normally use for scenery add-ons, but I'm frankly surprised you've not run into OOM issues prior to this running such a high LOD.

 

Scott

It sure would be nice to see a 64bit version of FSX and I'm certain all 3rd party vendors would also -- thinking back when FSX was being developed I was pushing Phil hard to move to a 64bit native FSX and to my surprise the 3rd party community were very vocal to not "Break anything" ... I guess I failed at selling just how important 64bit is and that nothing needed to be "broken" ... just like XP10 (that is both 32bit and 64bit) we could have a 32bit FSX and a 64bit FSX ... the 32bit being backwards compatible (for the most part) and the 64bit having only partial compatibility.

 

It's unfortunate that LM don't appear to be willing to move FSX to 64bit as a high priority ... IMHO this is far more important than fixing DX10 and/or providing DX11 support (which has never actually been confirmed). Anyway, all old news, it is what it is.

 

 

This is what I'm confused about.

I see people saying to shut down background programs, but I don't think it makes the least bit of difference since FSX only uses a fraction of a strong computers resources anyway.

It don't matter if you shut down everything, FSX is still only going to use 4GB and suffer OOMs.

The only answer is if it was 64bit and could use all of the computers resources and the only way that's happening is by switching to X-Plane 10/64bit.

Addon developers keep on making elaborate addons for FSX and the more that you buy, the more it brings your poor FSX to its knees coughing and spitting blood.

I really think that, for me, it is time to spend more time in XP10/64.

Hey Scott,

 

I hope an Admin will re-word my title, I really wasn't trying to bash UTX at all ... my apology if it comes across that way.

 

I do mostly photo-real which has a lower impact on RAM usage ... it's most likely UTX texture sizes that put me over the top, but it put me way OVER the top -- 600MB+ just starting a flight vs. no UTX. But no OOM's prior to UTX, close, very close, but never over the edge.

 

Cheers, Rob.