MD-11 memory management / OOM error issues

[Sharrow 0]

Hi guysFirstly a big thumbs up to the PMDG MD-11 team for a truly excellent piece of kit! I am, however, having issues with Out of Memory errors (as have been noted by others). Thing is that the exact same routing (EGLL to LSZH) with the 744X presents no problems at all. Having done this route a couple of times now in the MD-11 each and every time I am able to complete the flight but for the last 10 or so minutes before touch down FSX will refuse to take screenshots (or take corrupted ones) and a soon as I exit the flight I get an Out of Memory error and FSX shuts down. I have duplicated this exact sequence of events at least 4 times in a row now... As stated I have no such issues with the 744X on this exact same routing.Overall, the MD-11 also seems a bit more "sluggish" than the 744X, it is hard to say exactly but a 2 to 5 fps hit is what I would estimate it at.System specs in signature. I am not using the 3GB switch and nor do I intend to (tried it with bad consequences). Moving to Vista 64bit is also not an option for me at present. Just to have no (or reduced) OOM errors with the MD-11 would not be enough reason to do so anyway.So where exactly does this leave me with the MD-11? And where does this leave PMDG's claim that, all settings being equal, the MD-11 performs better than the 744X? My experience so far has been the opposite.I doubt a 64bit OS going to become a minimum requirement on the boxed MD-11 so what's the plan then?Thanks for listening!Konrad

[Guest D17S]

Running 4Gs of physical ram in an un-3G-switched 32bit operating environment is causing the problem. If going to Vista 64 is not an option, there are 3 others: 1) Set the 32bit system's 3G switch.2) Run with lower settings. This will reduce ram loading. 3) Remove 2Gs of physical ram. If the op system's ram scheduler (Mr. Virtual Size) doesn't see it, it will be less aggressive about trying to schedule it. Strictly FS performance wise, this is really your best bet. You are using considerably less than 2Gs of physical ram for FS anyway. The op system's ram scheduling feature (VS)is giving you the OOM at 2Gs of scheduled (or forecast) ram usage. However actual, physical ram usage always runs below this forecasting schedule. That means you are OOM-ing with physical ram loads - Below - 2Gs. Don't blame Aces (or PMDG). The MS operating system crowd is responsible for this. Everyone always knew this is exactly the way it would happen (To draw an analogy: Everyone also knew that eventually that 286 processors just would not be enough!)As it sits now, your extra 2Gs of physical ram is - Not- being used by FS and is now just causing problems for the un-switched 32bit system.We are at a transition point between 32 and 64bit op systems. "Pay me now, or pay me later" this relentless advance of software capabilities is quietly describing. Consider the alternative.

[Sharrow 0]

Hi SamThanks for the detailed response!1. As mentioned I tried the 3G switch a few months back with near disastrous results so not going there.2. Lowering settings is the obvious solution but in this case it does not really seem to help all that much. Considering my specs I run very modest settings with the 744/MD-11 as it is and even with autogen off I still run into OOM errors with the MD-11.3. Removing 2Gb of RAM is also not an option. I have 2x2GB. Even if I did only run 2x1GB would this really help in overcoming OOM errors? Seems a bit like stealing from Peter to pay Paul...My question remains: Why does the MD-11 seem to run into OOM errors much quicker than the 744 does, given all settings being equal? Is this a reflection of the extra complexity of MD-11 systems as opposed to the 744's or is this something which could be potentially optimised in the future?Not blaming anyone for the evolutionary process, just challenging PMDG's claim that the MD-11 performs better than the 744. On a 64bit system this may indeed be the case, but what about a 32bit system?Does this mean that the Recommended Requirements for the MD-11 boxed edition will suggest a 64bit OS? Surely it will not mention the 3G switch.All the bestKonrad

[Gary A 8]

>Hi Sam>>Thanks for the detailed response!>>1. As mentioned I tried the 3G switch a few months back with>near disastrous results so not going there.>>Not blaming anyone for the evolutionary process, just>challenging PMDG's claim that the MD-11 performs better than>the 744. On a 64bit system this may indeed be the case, but>what about a 32bit system?>>Does this mean that the Recommended Requirements for the MD-11>boxed edition will suggest a 64bit OS? Surely it will not>mention the 3G switch.>>All the best>KonradKonrad, you still running scared of that 3GB switch? LolPut the 3GB switch in as a switch man. The switch is accessible before the system boots. If you encounter an issue with the switch simply reboot and do not select the 3GB at boot. It is near bullet proof no risk. When you did your near fatal 3GB switch you put the 3GB in as a one-line no choice option. You hit a snag and couldn't get back to your OS because of it. That isn't what I am suggesting you do here.Add this line, do not alter your existing line on you boot ini file. If you need more specific directions on how to do this please just ask.multi(0)disk(0)rdisk(0)partition(1)WINDOWS="Microsoft Windows XP Professional 3GB Switch" /3GB /USERVA=2560 /noexecute=optin /fastdetectThis way when you boot you will be asked what operating system you want to boot to. One option will be windows xp one option will be windows 3GB. Select 3GB, if you hit a wall reboot and select Windows XP. Better to have loved and lost than to never have loved at all I say.I could hit OOM all day long on the 744 not sure how much of it is PMDG, or GEX, FEX, ASX other add on scenery files e.t.c.I put Vista-64 on my system last week and so far I can tell you that the performance gains exceed any tweak or hack I ever did to my XPP32. So far no OOM but still pretty soon to tell.put the switch in man put the switch in.Specific instructions:

[Sharrow 0]

Hi GaryOk, took the chance and inserted the 3G switch in my boot.ini file! BUT before I did this I set my virtual memory back to system managed from a custom value I had in there (4065). I suspect that this custom setting may have been the cause of my issues with the last time I tried this switch.And guess what? The 3G switch seems to work fine so far! FSX and the MD-11 load fine - will try a flight this evening and see how the memory management goes. I gained over 500MB of extra useable RAM in Photoshop CS4! Looking good... will see over the long term how it goes. Thanks for the push and advice! Much appreciatedAll the bestKonrad

[Guest D17S]

You need both sticks to remain in dual channel mode. However running 4Gs with a 32bit op system may not be using that hardware to its best advantage. Any 32bit program can only schedule (VS) 2Gs. That means that each individual 32bit program can actually use Less than 2Gs of physical ram. If a user has multiple programs All using large chunks of ram, this can make sense. However if 4Gs of physical ram is primarily intended to provide service to any single 32bit program, it is wasted. 4Gs of physical ram installed with a 32bit operating system only makes practical sense in some very specific conditions. It's not just a matter of 'more is better.'Here's just an ordinary flight. We know Virtual Size (this is the ram's scheduling agent and the OOM-er). Meet WS Privite. This is the physical ram load. Note that any 32bit op system was a dead-duck 400Ms ago. Also look at the spread. This is about normal. The 32bit op system would have OOMed at a ~ 1.6G physical ram load:http://forums.avsim.net/user_files/193482.jpgI really don't know why the MD is more prone to higher ram loads. I just bit the bullet with the last build and went with Vista 64. I saw this coming and really didn't want to fight this fight myself. I don't think we're gonna get a recommendation on the box, but the troops are standing by to help the 32bit-ers get that op system to run just one last lap around the barn. That 3G recommendation has a mod (I think) that unloads the full 3G effect: multi(0)disk(0)rdisk(0)partition(1)WINDOWS="Microsoft Windows XP Professional 3GB Switch" /3GB /USERVA=2560 It's the "/USERVA=2560" part. Yes? Thankfully, I'm missing all this need-to-tweak.

[Gary A 8]

Sam, you

[Sharrow 0]

Sam, I see by your reply that you guys are all indeed well prepared for this issue! First time I been called a "32bit-er"! :-)Ok, so now with the whole /3GB /USERVA=2560 switch in my XP boot.ini file can I expect my WS Private to have a total "ceiling" of approx 2.5GB? Am I understanding this correctly?ThanksKonrad

[Sharrow 0]

>Konrad, glad to hear that you took the plunge buddy but I can>tell you that the 3GB switch is masking the problem. The cure>is in switching to a 64bit OS be it Vista or XP.>Here's to hoping it masks the problem long enough for Windows7 64bit to be out! :-beerchug Konrad

[3-2-1-Now 126]

The thing people keep missing about this whole 32-bit / 4 Gb RAM problem is this:There are insufficient address lines to address 4 Gb of RAM.Forget virtual memory - it's a work-around to other issues (study the design history of x86 architecture to see why).Missing from this thread is the "why": it's in how the memory is accessed. There is another quirk of the x86 design - that memory addresses are accessed UNSIGNED. This design decision was made at the conception of the x86 memory architecture that is now biting us hard.Addressing memory above the 2Gb boundary is resulting in the addresses becoming SIGNED, unintentionally. The bit that denotes unsigned vs. signed is being set in order to address the top end of memory, which is causing all manner of issues with apps that are not designed to handle it. That this bit is being set is a total "accident", only it comes right back to the design of the memory architecture and addressing scheme. Memory locations that should return unsigned, are being seen as signed, so instead of accessing the memory above 2^31 bytes, it's trying to access within the first 2^31 bytes (effectively resulting in memory wrapping). It sees the location as not available and an OOME ensues.Apps that are designed to use more than 2Gb of memory are coded in such a way as to check for this phenomenon, so they are not susceptible to the problem.Best regards,Robin.

[Sharrow 0]

>Apps that are designed to use more than 2Gb of memory are>coded in such a way as to check for this phenomenon, so they>are not susceptible to the problem.Does this list of Apps include FSX XP2? Logically thinking it should do seeing as FSX related OOM errors are virtually non existant on 64bit OS's...?This has the real potential of going over my head...!Konrad

[3-2-1-Now 126]

Hi,The description I gave above is the primary reason apps OOME for no apparent reason.FSX is already coded to use more than 2Gb of RAM.The LARGEMEMORYADDRESSAWARE flag is actually a compiler option, for when the program is built, not for when it is run. It has an effect however as this flag tells the OS that it can assign memory to the application that is over the 2Gb limit. The app must already support this feature however, otherwise OOMEs will still occur for the reason I stated in my above post.I appreciate this is technical subject, but you can't skip the details. :) You can disable the VM completely (as I have done under Vista) and be fine. Conversely, on XP, I can't disable the swap file, and yet I can get OOMEs. It has nothing to do with the swap file at all, as to whether I will suffer OOMEs (as long as I am not trying to use more memory than is installed in the system in total, but this its own set of problems! It's quite possible run beyond the installed memory limit, but the system becomes irreversibly unstable without a restart/crashes).Best regards,Robin.

[Guest D17S]

Actually, I'm not techy enough. But to make up for it, I have lots of monitors. I generally run FS in window'd mode so the other 2 monitors are free. I run that Process Explorer in one and use it as additional entertainment while Otto is flying the airplane. http://technet.microsoft.com/en-us/sysinte...s/bb896653.aspxand I refer to this Anandtech article that gave me that heads-up last year: http://www.anandtech.com/gadgets/showdoc.aspx?i=3034&p=4This problem is really old news. When it came time, I went for the 64bit operation system. However what I see as process explorer is running is that this VS scheduling agent is just dumb as a rock. One would think it'd look at physical ram, the op system it was working with and Not ring the bell (OOM one of its clients). But it doesn't. It just stumbles along in its own little world seeming oblivious of its surrounds. Another aspect of the background it that in 1985 when 16bit systems were all the rage, this same transition occurred. These were the days of 1 Megabit of ram using expanded and extended memory? Remember ThaT fight? The 32bit-ers gave the world 4 GB - - Billion Bites - of memory room. They will Never - in a thousand years - use this! Well, it wasn't quite a thousand, more like 20. There (likely) was nothing built into 32bit to handle the transition we are currently experiencing. They considered there was no need to make Mr.VS smart. . . and from what I see, the poor old guy's got an IQ of 'bout 12! And yes, the 3g switch will allow physical ram loads of about 2.5G before our challenged friend OOMs the program at his new 3G limit. (If the 2650 line is really limiting scheduling to 2.6G, recalculate accordingly.)

[Sharrow 0]

Just an update to all of this after successfuly adding the /3GB switch earlier on today. Flew the MD-11 from EGLL to LSZH with some heavy weather (FEX SHD using 4096 textures) and all went very well! No corrupted screenshots and no OOM errors. :-hah Sam, check out my Peak Private Bytes column after this flight - 1.66GB How's that for skimming the surface!http://forums.avsim.net/user_files/193522.gifThanks for all your help guys!Konrad

[Guest D17S]

Hey, that's the picture . . . and woah, look at that VS <> WS/P spread. Now you will be able to really watch what's going on. Notice that without the 3G switch, ol' VS may not have been letting even 1.2Gs of physical ram load. It's kinda frustrating in the beginning, but - Very - interesting once it starts making sense. Good job. Now, let's see about those polar runs and, I'm still not getting intermediate vertical predictions between hard altitude restraints and, what about that V2 scheduling? This airplane is sooo deep. There is no end . . . with any luck.