Got an OOM with FS9. Too bad!!!

[psolk 3,037]

Posted in the FSX forum as well but i know how many fought the Out of Memory in FS9 so it is very relevant to these forums as well.Well this is just my opinion and please let me begin by thanking Phil and the team for finally giving us the definitive answer we need which is that neither FS9 or FSX can KEEP themselves under the 2g limit. Phil's presence in the forums adds an air of credibility to our hypothesis and some of us have been saying for quite some time it is not an A/C or a scenery but just that we have exceeded the limits of the app. It does not bode well for add-ons in FSX that people are exceeding the 2g limit with default fsx though. It took us years and hundreds of add-ons to get to this pint in FS9. We are getting it vanilla with FSX.In fact if either sim wants more than the O/S can give they will ask for it and we will get an OOM and our simming experience is over.Some of us have been fighting this issue for YEARS!!! We thought it was our setup, navdata, LC files, terrain.cfg files, if you name it someone tried it to fix the OOM errors. Now we come to find after all these years that it really is the same issue that effects MS Exchange and requires the /3gb switch on an exchange server. The only difference is that Exchange servers are not running high end video cards that are not compatible with the /3g switch in the first place.So, yes, MS wrote two sims that just like their Exchange Server can not even stay within the limitations of the O/S they run on. Phil has also said they will not modify either version of FS to stay within the limits of the O/S. In fact what we are being told is to apply the /3GB switch to XP Pro and Vista to eliminate the issue. Well anyone running high memory video cards can not do this. It does not leave enough memory for the O/S and the card and you start losing things like AA/AF. Maybe this is the DX bug Phil is speaking about but I doubt it.So I was just wondering what your thoughts were now that years of fighting the OOM comes down to an app written to be able to exceed the memory allocated to it by its own O/S and that MS is not going to fix but instead recommend a tweak that is not even viable for most...I know I am more than a little disturbed and disappointed but wanted to get others opinions.-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

[JSkorna 137]

I guess I would suggest the same thing your cute sig always suggests:"STOP TAKE A BREATH RELAX"Jimhttp://www.hifisim.com/banners/hifi-community-sigbanner.jpghttp://www.hifisim.com/

[Guest Zevious Zoquis]

hmmm...I flew FS9 for about 2 years with 768 megs of RAM and never had an OOM error - and I've got a ton of add-ons. Was I doing something wrong? I've recently upped the ram to a gig, but performance is about the same and of course, no OOM errors now either...

[psolk 3,037]

LOL,You are talking about 768 ,megs of RAM total. I am talking about 768 megs of RAM per video card and I have two. Come on Jim, for those of us who have fought this for years racking our brains, blaming every add-on out there and tearing FS apart to now hear that oh yeah, FS can actually exceed the 2g memory limitation of a 32 bit app is pretty darn frustrating. Especially when MS writes the O/S. To then here that MS can't change it and that the only fix is one that will not work for people with large amounts of video memory is even worse. I went to the beach for a few hours, got some color and although still frustrated, I do regret posting but such is life. -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

[JSkorna 137]

Hi,Software that is being limited by hardware, such as FSX: people complain.Hardware that is being limited by software, such as this: people complain. Another message from your cute sig: "This is crazy this is crazy this is crazy"Jimhttp://www.hifisim.com/banners/hifi-community-sigbanner.jpghttp://www.hifisim.com/

[scott967 62]

One thing Phil was alluding to is the possibility that there is memory space available in the lower 2Gb, but because of fragmentation the OS can't allocate the requested range of memory. This suggests that FS needs to do a better job of compaction or cleanup after releasing memory objects.scott s..

[psolk 3,037]

From my favorite move National Lampoons Vacation... Technically this is software that is being limited by the same companies Operating System LOL ;) So this is a software being restricted by software and people complain. The biggest reason I am complaining is because this SHOULD have been avoided if the app stays within the 32 bit application space which it was written for which it doesn't. That is not ideal coding...-PPrimary 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,714]

Here's my analogy...Ford builds a pickup truck, rated at 3/4 ton. I can put a 1000 lb camper on the back and it'll run all day just fine. I can put a 1500 lb camper on the back, and it'll run OK, usually without problems. I can put a 2000 lb camper in the back, and from time to time I might blow a tire or break a spring, but it'll usually run OK.But...I also want to tow a trailer, heck maybe even two or three. And I also want the truck to go fast and corner well with the big camper and the trailers. Even if I put the smallest motor available in it. And run it on ethanol.An boy, am I gonna be grumpy when I have problems that make me go back to a smaller camper, tow less than three trailers, and take the corners a little slow...FS is like the truck...you can't keep piling on the stuff indefinitely and expect the performance of a Maserati. I've been able to keep FS9 from OOMing on me by avoiding the accumulation of .dll modules in the modules folder...I put them in with batch files only when a flight needs them. If they're there, they are loaded by FS and taking a bite out of the limited 2GB address space FS has to stay within. And I try to avoid piling on the extras...big 32-bit kabillion-pixel models, sliders firewalled to the right, oodles of layers of 32-bit clouds in a bad wx scenario etc.The beauty is that you get to choose. But best not to complain when you pile on so much stuff it can't carry the load. FS isn't going to break out of this limitation in the current generation, so get over it and learn to operate within the fairly roomy performance envelope available.RegardsBob ScottATP IMEL Gulfstream II-III-IV-VSantiago de Chile

[mgh 89]

A application has to manage its own Virtual Memory (VM). Windows has never done this because only the application can allocate and deallocate VM to suit its own requirements. Ever since 32-bit addressing was introduced with Win98, it's only possible to address upto 4GB of VM. Normally this is allocated as 2Gb to each application and 2Gb to the kernel. The /3GB switch changes this to 3Gb to applications and 1 GB to the kernal. However, Microsoft does warn that some video drivers can demand more of the 1Gb kernal than available and won't load. That's hardly Microsoft's fault. VM is typically allocated by either the new operator (C++) and the malloc function ©. (There are variants that do much the same thing.) These return a pointer to the allocated memmory or a NULL pointer is there is insufficient memory. Out of memory errors occur if the maximum contiguous block of VM available is less than that requested. In principle the availability of VM could be checked calling the GlobalMemoryStatusEx API function (thouigh I'm not certain if this gives the total available VM or the maximum contiguous available VM - any offers?) then using sizof to detrmine the amount of VM to be allocated by the subseqent new/malloc. However, apart from the overhead this would inroduce, what can the application do if there isn't enough VM available other than stop? I run FS9 (SP1) on a low-end PC and have never had an OOM error. Admittedly I don't have much add-on scenery but this suggests to me that a vanilla FS9 is stable in this respect. I don't think Microsoft can be held responsible for the effects of using a wide range of add-ons which may require various amounts of VM. While FS9 is running it will be continually allocating and deallocating VM depending on the particular set-up and add-ons. It's unlikely that will have exactly the same add-ons and fly the exactly the same flights so that the available VM and its state of fragmentation state will be different for different users after a period of flying.

[psolk 3,037]

Nice analogy Bob but unfortunately software is a little bit different than physically overloading a truck. Software if coded correctly should not be allowed to exceed 2g no matter what. No matter how much you pile into software if it is coded properly it will always clean itself up and stay within the confines of the 32 bit lower memory restrictions. The only apps that I know of with this issue are MSExchange, MSFS and Adobe Photoshop when editing HUGE HUGE images. Even 3D CAD programs that crunch more physics and equations than MSFS can ever hope to crunch can run for days and not exceed the lower memory space restrictions. So don't tell me to get over it when I can't fly an add-on A/C into an add-on airport b/c the underlying sim can't keep itself within the memory limitations of an O/S. Every other app and company has to code to remain within this standard but this should be different and I should "get over it?" Why should I just accept it. I might not be able to change it but I can certainly voince my opinion. AD servers can handle millions of transactions per second and run for months, you give me a better answer than get over it as to why MSFS can't do the same. If you want an analogy:If my company were to go out and sell our SSL VPN software that was coded incorrectly and started locking out users because we were exceeding the 32 bit memory space and throwing an OOM I bet our customers would want it fixed... Fortunately we can handle 300,000 transactions per second and run for 3 years without reboot or issue so we don't have to worry about it but trust me if we told our customers to get over it we wouldn't be in business very long. The truth is with FS9 I have learned to do the same thing. I disable ALL of my add-on sceneries prior to my flights. I use DXT everything I shut down everything on the box and I rarely use the PMDG 747 anymore but guess what, i shouldn't have to do all of that.Now you have FSX and Vista and the FS9 issues with tons of add-ons plague people after 5 minutes of flight on vanilla FSX because MS didn't address it on a 32 bit platform and did not code for a 64 bit platform that can support it and again we should just lay down and accept it. MS just wrote a $60 sim that can't run on their own $200 O/S and we should just get over it?Maybe we just see things differently.Respectfully,-PaulMGH, you are correct, FS9 needed to be severely bloated to get to this point, FSX does not.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 Zevious Zoquis]

it doesn't make any difference what your talking about. It's vid card memory? OK fine, I've been running the sim since the day it came out with a 128 meg vid card ( a crummy geforce4Ti 4200) and even with the heaviest of addons I own I've never had an OOM error. In fact, I've never had a ctd that I couldn't directly account for from some specific thing I'd done in the sim...why would people running much more pwerful systems than mine be having this issue and not me? It sounds like the sort of thing that should affect me about 10 times as often as it does you...

[MarkRey 16]

Have to say ditto - I've always had modest specs, use 32bit paints, complex a/c, high as possible detail and never seen an OOM. Can't argue with more savvy than me re MSFS code, but something else seems to be happening to OOM sufferers.regards,Markhttp://www.dreamfleet2000.com/a320/custbanner2.jpgPC Power Silencer 470/3.2HT/2048mb/ATI X1950pro/SB Audigy

[ronzie 21]

Your total of 1.5 GB of video ram takes a lot out of available memory both virtual and physical. In the thread over on PMDG see the reply from D17S about PCI-E video ram mapping. Apparently unlike AGP port access this is mapped into your physical address space and can be bumped up into higher levels with a 64 bit OS and it is enabled in the BIOS. Quite a bit of your 2GB ram is wasted in your current situation it seems. That's what I got out of D17S' reply if I interpreted that correctly and the information he linked to here:http://www.dansdata.com/askdan00015.htm

[psolk 3,037]

You got it Ron...That is why this affects people with higher specs and video cards with higher memory levels. 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 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. It doesn't exceed the lower memory allocation of an application. FS9 and FSX both exceed 2g and so does Exchange Server which had to be moved over to 64 bit which points to MS not coding applications to their own O/S standards. There is a bigger issue here...-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

[mgh 89]

>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.That may or may not be true, although the evidence here suggests it isn't. However the reality is that Windows is not (and is most unlikely ever to be) designed to meet the requirements of a vanishingly snall number of FS enthusiasts with high-end systems.>with proper coding NO application should EVER exceed the 32 bit limitations. Given that FS (like all Windows applications) is event-driven and that Vitual Memory (VM)is allocated and deallocated dynamically, it is impossible to predict the usage of VM. This is compounded by the "open-archtecture" of FS which allows 3rd parties to incorporate executable files (.gau and .dll) that can also use VM. Basicallyis that if VM is available it is allocated when it's required. Once there is insufficient Windows can do nothing other than issue an OOM error. Remember, VM is needed not only for data objects but also for bitmaps when they are loaded from disk. Perhaps you could explain how a Windows could be coded to ensure that it never calls for more contiguous VM than is is available?