Got an OOM with FS9. Too bad!!!

[Bob Scott 7,721]

psolk wrote:>The OOM sufferers are>typically those with the highest system specs... The problem>though is regardless of my setup. 4g-1.5g= 2.5g that should>leave plenty of room for an O/S and an app to survive in a 32>bit O/S.The 32-bit Windows variants are designed to give the upper 2GB of address space to the OS, and the lower 2GB to applications. When you give up 2x768MB = 1.5GB (75%) of the upper address space to the video card alone, you're crowding the space available to the OS, the other memory mapped device addresses, and the apps, and something's gotta give.The memory-mapped VRAM is not the only thing occupying that valuable upper 2GB of address space. Your sound card, your LAN card, and various other hardware devices on the PCI bus take a chunk for their hardware-mapped addresses as well. And after the smoke clears, the OS then has to either fit into whatever tiny space is left over in the upper 2GB it is designed to operate in, or it has to move down into the lower 2GB and further block the address space available to application programs.The simple truth is that FS was never designed to operate in the environment you've created for it. I think you're irate because you can't fit ten pounds of the latest-greatest stuff into the five pound bag MS has provided you. >The problem that no one seems to want to address is that with>proper coding NO application should EVER exceed the 32 bit>limitations. This is why I am so frustrated. A properly>coded application does not suffer from OOM errors period ever>end of story. "Proper" coding is in the eye of the beholder. Perhaps a paging scheme could be designed to keep FS and any conceivable combination of memory-munching add-ons (mesh, hi-res scenery and complex aircraft etc) within an arbitrarily overcrowded address space...but then the paging would kill frame rates and fluidity. IOW, the cure might be worse than the disease, and for a lot more folks than the relative few affected now. Bottom line...and the lesson to be learned by others here, is that there is more to systems design than plugging in as many of the best and most powerful components you can fit and expecting results commensurate with the dollars spent. Your system, as designed and built, imposes clearly foreseeable limitations when using any 32-bit Microsoft OS. I would think that a pair of 320MB 8800GTS boards (if you truly need SLI) or a single 640 or 768MB 8800 would prove a better design choice in a system that will be used to run FS on a 32-bit OS. And 4GB of RAM on a 32-bit system, as I've written elsewhere here before, is money wasted as well--even with a single 768MB video card, most to all of that fourth gig of RAM is inaccessible to the OS because of the same memory-mapped hardware device issues.It's frustrating, I'd think, to spend hundreds of dollars on that second video card or that last gig of RAM, and then realize that they're either sitting there useless, or even creating problems. But respectfully, I suggest to you that the problems you're having are at least as much of your own making through faulty system design as any perceived deficiency in the design of FS.RegardsBob ScottATP IMEL Gulfstream II-III-IV-VSantiago de Chile

[scott967 62]

ISTM that for an app to handle this OOM issue, it would have to first allocate VM to itself, and then manage it internally rather than letting the OS do it. How good is the garbage collection in MSFS?scott s..

[psolk 3,044]

Scott,The garbage collection in MSFS is horrible. Just watch Filemon for an entire FS session and watch how FS wastes memory and then doesn't seem to recover it ever until you shut down FS. Watch all the calls to non-existent directories and files "by default" in FS that eat up at memory. To Bob, this was happening to myself with everything from 7800 GTX cards on up. Don't try and put this down to "faulty system design" when the only three applications that trigger the OOM on any of my systems or servers that run for months and TEAR through any piece of s/w under the sun are MSFS 9 and X and MS Exchange Server...It is not the users fault regardless of their system that MSFS looks for the same file that doesn't exist in 5 different places and MS just left that horrible coding in there for the end user to find themselves and that this poor coding gets exposed when FS is pushed to the limit on high end systems. If I had to sacrifice my system or the only app that doesn't run on it I will sacrifice the app and keep the crispest clearest #D modeling and video editing you can imagine. Talk to me about faulty system design when all those nifty FSX features require DX10 which requires an 8800 series card or better. Talk to me about poor system design when anything less than this can barely run FSX and yet they wrote that app for a bloated 32 bit O/S as well. Oh wait, it would cost MS to write FSX for the O/S that can actually run it with the memory and video cards it needs. MGH,the answer to your question is in my answer above. If the MSFS code was efficient to begin with we would never be CLOSE to these memory levels even with our add-ons. Inadvertent searches for files that don't exist over and over again in the base code of an application is not poor coding in the eye of the beholder it is poor coding. Primary RigLiquid CooledIntel C2D E6600 @3.2 gigsAsus P5N32SLI-Plus2 gigs Corsair XMS PC6400 4 4 4 12 @810Dual OC'd XFX 8800GTX @ 2 gigs24 inch Widescreen LCD 16XAA/16XAFDual 19 inch LCD'sRaid-0+1PCPower and Cooling 1k Quad SLIhttp://home.comcast.net/~psolk/3monitorsa.htmlBackup RigAMD 4000 San Diego @ 2.72 Gigs Kingston Corsair XMS CL2XFX 7900 GTX Raid-0

[Bob Scott 7,721]

>To Bob, this was happening to myself with everything from 7800>GTX cards on up. Don't try and put this down to "faulty>system design" when the only three applications that trigger>the OOM on any of my systems or servers that run for months>and TEAR through any piece of s/w under the sun are MSFS 9 and>X and MS Exchange Server...Lots of emotion here...but unemotionally, your choice to block 1.5GB of memory address space with dual 8800GTX boards (or perhaps 1GB of address space with two 512MB 7900s?) is an obvious problem for the 32-bit Windows environment and FS9/X. Don't know about all these other apps you refer to, but I don't run anything that taxes my PC to its limits as much as FS plus the usual slew of hungry add-ons.>It is not the users fault regardless of their system that MSFS>looks for the same file that doesn't exist in 5 different>places and MS just left that horrible coding in there for the>end user to find themselves and that this poor coding gets>exposed when FS is pushed to the limit on high end systems.No, but I don't think anyone is nominating the ACES team for the Turing Trophy here. >If I had to sacrifice my system or the only app that doesn't>run on it I will sacrifice the app and keep the crispest>clearest #D modeling and video editing you can imagine. Talk>to me about faulty system design when all those nifty FSX>features require DX10 which requires an 8800 series card or>better. But my point is that you chose to put *two* 768MB 8800 cards in your PC. The consequences of that design decision, when running FS and 32-bit Windows, are quite predictable. Sorry, but I do fault your system design as it relates to the FS environment.Your system is so strong...with a few minor compromises you could have FS9 cranking at 40-50 fps with loads of add-ons in the mix. You're so pi**ed that you can't have it all, you'd rather just throw the baby out with the bath water?? That's not very good reasoning.>Talk to me about poor system design when anything>less than this can barely run FSX and yet they wrote that app>for a bloated 32 bit O/S as well. FSX is a pig, I agree, but it does run (slowly) without OOM errors on machines with slower CPUs and less RAM...but the key is that they sport more memory address headroom.>Oh wait, it would cost MS>to write FSX for the O/S that can actually run it with the>memory and video cards it needs. Someday, Joe Average and the rest of the unwashed masses will move to a 64-bit OS environment. Before that it just isn't economical for MS to write a game specifically for a 64-bit environment that is only used by a minority of professional users and power hobbyists.Until then, dial it back a notch or two, take a breath, relax, and have a happy day simming...RegardsBob ScottATP IMEL Gulfstream II-III-IV-VSantiago de Chile

[psolk 3,044]

You know what the funniest thing about this entire post is...I haven't had an actual OOM in a long long time. Actually, the last time I got an OOM with FS9 was prior to the dual 8800 GTX setup so please stop attacking my babies ;) Apologies if I was coming across to heated, I don't take it personal but sometimes sarcasm and that "yeah ok" look don't come across digitally. My point in this post was to neither throw MS under the bus nor to displace blame from myself. The only point was to try and tell others who are looking for a silver bullet or a guarnteed fix for an OOM that it very well might not exist and unfortunately FSX isn't going to fix it. Some people have been fighting this for a long long time and it is really frustrating for that group of users.Look I know better than anyone, (trust me tracking down OOM errors has been a second job for me for two years) that this doesn't happen with a default FS9. It happens to a severely bloated FS9 and certain systems. It does happen with a default FSX and Vista and that is scary. I actually figured out that the issue with OOM's and MSFS was specifically the bloating of FS and wrote a post a few months ago about de-bloating MSFS specifically. But that doesn't excuse the fact that there is some really poor coding alongside all of this fabulous coding in FS that can really do with a clean up...What I do before every flight is to disable all non-essential apps and programs.Then I remove all non-essential Dll's.Then I disable EVERY single add-on airport other than the ones being used for that particular flight.I also disabled all MYTraffic Afcad files. This still provides MORE than enough AI but doesn't load it up at all the airports I am not using. Add-on airports have their own AF2 anyway.By "de-bloating" FS9 it has become the most enjoyable FS experience I could have ever hoped for and I personally am happy. I was trying to give others a heads up but I guess it came across wrong.But back to my point; look at an application like HEAVYLOAD. http://www.jam-software.com/freeware/index.shtmlIt is a freeware program that everyone can download and try. It will run your CPU to 100% your physical memory down to ~ 2megs available out of 2 gigs and grow your swap until there is nothing left on your HD. This is one of the stress tests I use for my system and despite using every inkling of system resources down to nothing at all left HeavyLoad will run until I shut it down which is sometimes 7-10 days. Come to think of it so will 3D Studio Max and every other application under the sun...Why won't FS or Exchange that HAD to be ported over to 64 bit and why do we accept it?Cheers Bob,-PaulPrimary RigLiquid CooledIntel C2D E6600 @3.2 gigsAsus P5N32SLI-Plus2 gigs Corsair XMS PC6400 4 4 4 12 @810Dual OC'd XFX 8800GTX @ 2 gigs24 inch Widescreen LCD 16XAA/16XAFDual 19 inch LCD'sRaid-0+1PCPower and Cooling 1k Quad SLIhttp://home.comcast.net/~psolk/3monitorsa.htmlBackup RigAMD 4000 San Diego @ 2.72 Gigs Kingston Corsair XMS CL2XFX 7900 GTX Raid-0

[Guest TomOOO]

Hum...Garbage collection applies to languages such as java that havea separate thread that looks for un-referenced objects in memoryand deletes them. FS is written in a C-language derivative thatuses explicit constructors and destructor's - ie the program allocatesand then gives back memory to the process using explicit instructionsin the computer code - get this wrong and you know in seconds. Notice the last word - the memory can only be handed back to theprocess (FS9 or FSX), it cannot be handed back to the OS. This meansthat if you ever use 1.5G of memory in FS, the process size of FS9/Xwill never get smaller again on all OS I know of. (The size may be viewed as smaller occasionally as the OS may attribute buffersetc to FS9/X and these can be returned to the OS). So it appearsthat FS just gets bigger, then waits at this size, then sometimes gets a bit bigger, then waits at this size. The wait at the big size is when the process (FS9/X) has got lots of memory back and canreuse this again, until it needs more from the OS - and eventuallyyou hit 2G.As for FS having bad memory management - it does not. If you havea memory leak in such a program you soon know. As posts haveindicated - it is the open source nature and all the addons whichdon't work well together. Then there is the need for us simmers tojust want all possible addons until it all goes crunch. Finally : all video cards (apg and pci-e) have a memory shadow inthe RAM, and if you fit multiple big mem vidoe cards then, as noted, you seriously stretch the high memory error - which can then take application space. You cannot blame MS for a 32bitOS - I constantly hit the same problem under linux (32bit). Wewill have to all wait until 64 OS become normal and all the simstuff is ported properly to 64bit OS.I am writing this post since I am waiting to see if the program Iam writing will run at a particular setting within constraints ofmy 32bit linux OS; I just have to change the parameters and limitmy research to fit my computer. That is life....Tom

[psolk 3,044]

Tom, your last line says it all. That is life... Very informative post BTW, thank you. Not coding in C I wouldn't know that the application can not release memory back to the O/S. That is life like you said. The h/w we want to really run this sim in a kick a@@ manner "can" exceed the limitations of the O/S. The h/w we will need for Vista/DX10/FSX WILL exceed the limitations of the O/S even with default FSX and that is even more disheartening. In other words simmers are now stuck in a catch 22 until like Tom says we are all running 64 bit OS's and the application has been ported over. As for memory management I still do not think MSFS is efficient. It was coded with a known memory leak where it will look for textures indefinitely due to a blank texture folder and it is consistently doing repeated searches for files that don't exist in places that don't exist and that can not be an efficient use of memory in any application, especially if it can not give the memory consumed on those bogus searches back to the o/S ;). I will take all the blame in the world for bloating FS and wanting to use a kick a@@ system to run it, I understand what everyone is saying and I am not arguing at all on that front.I just want to get the point across this is an issue that might not be fixable for those experiencing it unless they are willing to do what I wrote above and start "de-bloating" fs. We may have pushed beyond the limits of the s/w with our h/w and I am not going to give up my h/w that runs everything else spectacularly for any s/w and that is just me. When my cassettes didn't fit in my DVD player I didn't try to figure out a way to dumb down my new h/w to my old media I moved on. If FS can't keep up with the h/w and is limited by the O/S MS chose to write it for I am not going to dumb down my h/w to sim. That is just me,-PaulPS the difference with Linux is how easy it is to modify parameters. A quick VI here and there and you are on your way. Try that with MS ;) Primary RigLiquid CooledIntel C2D E6600 @3.2 gigsAsus P5N32SLI-Plus2 gigs Corsair XMS PC6400 4 4 4 12 @810Dual OC'd XFX 8800GTX @ 2 gigs24 inch Widescreen LCD 16XAA/16XAFDual 19 inch LCD'sRaid-0+1PCPower and Cooling 1k Quad SLIhttp://home.comcast.net/~psolk/3monitorsa.htmlBackup RigAMD 4000 San Diego @ 2.72 Gigs Kingston Corsair XMS CL2XFX 7900 GTX Raid-0

[Guest Stoopy]

"So I was just wondering what your thoughts were... "Are you really?The way you're babysitting this topic and coming back at anyone's input with anti-MS sentiment says otherwise. Again, that's just me, but I've been simming for quite some time (over 20 years) and only have had one OOM issue with FS9, and that was with a very, very large and demanding addon. So in my view the manufacturer has provided a sim that IS quite stable but does allow the power users to overwhelm if THEY see fit.So there's another thought for your harvest.

[psolk 3,044]

Yes,I am...When people like Tom come along and provide new information I did not know about I am grateful and I state it and thank the poster.I have conceded that yes this is a mostly self induced problem that can be avoided by "de bloating" FS as others have said so that point was taken as well.I have also said that our h/w these days "can" surpass the limitations of the O/S, another point taken from the feedback.I have apologized to Bob if I came across the wrong way.In fact I even stated that the real point here is that alongside all of that great code MS provided us there is some really inefficient code that can be cleaned up as well. So no, it is not all negative MS bashing but I call it like it is and if there is inefficient code embedded within MSFS it should be brought to light.I have also tried to point out that this is an issue that was not fixed with FSX/Vista and has actually become worse so there really may not be a "silver bullet" to fix it. How great are all those sliders MS reserved for future h/w when the O/S for the new H/w can't handle it? It is a very valid concern moving forward.As you can see, my demeanor has actually changed quite drastically from my original post based on the entire thread so to be honest I find your comments about me personally totally unjustified. You could have commented on the thread without commenting on me personally... I have not said a single thing about any individual in this topic nor will I, that is your choice to come and start judging the individual.So there is another thought for your harvest, it doesn't have to be personal.-PaulOh yeah and since you think I am babysitting maybe if you were stuck at home on new medications to help you feel your leg again after spinal surgery to be able to function again you might be watching the forums too. never judge someone until you know the full story...

[Guest TomOOO]

PaulI suggest you go have a quite flight somewhere nice, I alwaysrecommend the French alps - really beautiful up there - cool beer,(can't do that in a real plane) ....regardsTom

[Bob Scott 7,721]

Just out of curiousity, what prevents running FS9/FSX on 64-bit XP or Vista with the LargeAddressAware flag set? I'm guessing there may be a bit more of a wait for stable video/sound drivers...but shouldn't the software run OK in a 64-bit environment?I'm sure it's been discussed before...but that discussion never caught my eye.Paul...get well soon. RegardsBob ScottATP IMEL Gulfstream II-III-IV-VSantiago de Chile

[mgh 89]

The LARGEADDRESSAWARE flag enables 32-bit applications running on 64-bit operating system to use all the 4Gb of VM for themselves. The kernal would, presumably, be allocated elswhere.32-bit - 2 GB, 3 GB if the system is booted with the /3GB switch 64-bit - 2 GB, 4 GB if the application is compiled with the /LARGEADDRESSAWARE switchTaken from the table in :http://support.microsoft.com/default.aspx?scid=889654

[Guest TomOOO]

I believe some people have installed FS on 64bit computerswith the relevant 64bit OS. The main problem is that 64bitmachines tend to be sold at the moment for servers and large scaleresources. As such there are issues with support for drivers etcfor most things you might want to attach - so you would need tocheck joy-stick etc compatibility.On the software side, for a proper 64bit addressed program thatcan use really silly amounts of allocated memory (terabytes), you wouldre-compile with the relevant compiler. MS has got round this, as indicated in the last post, by restricting software to 4Gbytes ofmemory on a 64bit machine - ie the software is still using 32bitaddressing, but can access all 4G of memory available to a 32bitunsigned address. This is a cludge and only moves the goal posta few feet but allows software to be mostly compatible.I look forward when we get proper 64bit OS on 64bit computers runningproper 64bit software compiled as such. Computers would be reallyfast by this time, and big disks; you could have every building modeledin 3D, 10cm grids (about military resolution), and so on.OK - back to reality .....OOM are a problem and a pain - but they are are attributed withcomplex addon and the some issues with FS9 when an addon is notquite set up right (empty texture folders). We have to compromiseand be careful how much we addon. And just remember - enjoy the view....

[mgh 89]

>MS has got round this, as indicated in the last post, by >restricting software to 4Gbytes of memory on a 64bit machine.To be clear. rhat restriction only spplies to a 32-bit applications running on a 64-bit OS. A 64-bit application on a 64-bit OS has access to 16 Terabytes.This obvious question is why don't developers simply convert 32-bit applications to 64-bit by recompiling them using a a 64-bit compiler? The answer is that it doesn't neccessarily work because of differences in C/C++ between long and pointer data type sizes and alignment between the 32-bit and 64-bit versions. These can give erroneous/unexpected results on assigning long values, assigning pointers, and aligning aggregate data such as structures.

[psolk 3,044]

Great info guys, keep it coming thanks!!!And Bob, thank you for the kind words, I really appreciate it. I think we can all agree that we have beaten the FS9 OOM issue to death although I am loving all of this new info coming to light. We can also all agree that it is largely system defendant, requires a lot of end user intervention to bloat FS9 to the point that it will OOM and that the only way to get around it is to put FS9 on a diet when using resource intensive add-ons. (Hopefully) we can also all agree that FS9 does look for non-existent files in non-existent locations repeatedly even in default vanilla FS. Considering that I have learned in this thread memory can not be recovered and handed back to the O/S to redistribute to the app it would be great if it was fixed so as to not contribute to the issue. We have always thought it only caused stutters but the truth is it eats up memory every time it happens.So now that we are hopefully all in agreement LOL (yeah right) I would like to ask another question. How does this bode for the future of FSX?MS has said that the sliders right now are designed to be run at around 50% which equals 100% in FS9. They have also stated the full sliders are for future h/w and not for todays systems. My question is how is that is going to work if the h/w is still limited by a 32 bit O/S? If anything it is going to get worse as DX10 starts to require higher memory video cards for all and more and more people start chopping into that limited available memory? The whole argument that sliders were designed for future H/W could be null if the O/S can't run it...Just some more fuel for the fire :)Thanks everyone,-Paul Primary RigLiquid CooledIntel C2D E6600 @3.2 gigsAsus P5N32SLI-Plus2 gigs Corsair XMS PC6400 4 4 4 12 @810Dual OC'd XFX 8800GTX @ 2 gigs24 inch Widescreen LCD 16XAA/16XAFDual 19 inch LCD'sRaid-0+1PCPower and Cooling 1k Quad SLIhttp://home.comcast.net/~psolk/3monitorsa.htmlBackup RigAMD 4000 San Diego @ 2.72 Gigs Kingston Corsair XMS CL2XFX 7900 GTX Raid-0