The other restriction is that once cards are filed, they cannot be moved from their current location.

Yes, and this restriction make all the problem !Such a memory management is maybe sufficent for "standard" applications in a multi-tasking environment, but probably the worst one for FS, which never stop to request and release ton's of memory blocks.This "rolling fire" of textures load/unload should NEVER has been implemented straight forward over the Windows system Memory Manager layer !!!The visible symptom of the horrible slicing of the virtual memory, made by FS, is probably the growing of "Virtual size" we can see into the "Process Explorer". For example this afternoon, I made the following test: I flew my "OOM flight" and saved along the flight "Virtual Size" and "Virtual Bytes" values (yes I know, it is a non sense, but it is all what I have !!!), while doing in the same time, a "Flight" save, in order to be able to restore the exact same situation later.So I got:Top of Climb -> VS=1288MB / VB=731MBTRA -> VS=1402MB / VB=754MBMILPA -> VS=1547MB / VB=775MBNARAK -> VS=1557MB / VB=761MBVASUM -> VS=1552MB / VB=728MBOOM -> VS=1554MB / VB=739MBThen, I reloaded the situation for VASUM and, after having well played with all views, internal, virtual cockpit, map at different zoom factor, etc..., to make sure all textures loaded, I looked at "Virtual size" + "Virtual Bytes" values and I got: VS=1020MB / VB=659MB.Quite a dramatic difference !!!So, what is missing in this Memory Manager, is a possibility to "defrag" the memory.But I think I guess why it isn't implemented !!! To defrag the memory would probably require to hang all running process until defrag is done, and a mechanism to make them aware that their private memory allocations are going to move elsewhere !!!ACS

n4gix,I have maybe a last question for you:Does the "/3GB switch trick" really solve the OOM problems, or just delay it ?In other words, does this increase of room for applications in VAS table, on the detriment of OS room, allow the Memory Manager to stabilize, when harassed by FS ? I mean, the hudge fragmentation of VAS stabilize at one point and therefore, we enter into a stable situation, where OOM won't occur anymore ?Or, with the FS behavior toward the memory, it is just a matter of supplementary time (or more complex and demanding addon) and the OOM will be there again ?I ask me this question, because you clearly said that the OOM does not come from the fact there is really no more room, but the system cannot anymore found a single contiguous space large enough, to fullfil the request in this chopped virtual memory.It will be probably difficult for you to answer, as I know yet that we are all blind to really monitor what's happen, but I guess you should have your opinion about that matter, maybe based on experiences you made.Thanks in forward,ACS

n4gix,I have maybe a last question for you:Does the "/3GB switch trick" really solve the OOM problems, or just delay it ?

Yes, no, or maybe. Take your pick. I've explained this in excruciating detail in my Wiki article, which was vetted by more than one of the (now ex) ACES developers, including Phil Taylor...It is a "balancing act," meaning that each person must experiment to find a "sweet spot" which will maximize the benefits for their specific computer hardware, operating system, etc.Let's just say that proper application of the technique will vastly lower the odds of an OOM Error occurring...Of those who've bothered to report results, I cannot off-hand recall a single instance where it did not solve their OOM Error problem.It costs nothing but a bit of time, is completely reversable, and cannot harm women, children, animals, or the Brazilian rainforest to try it out... Despite all my efforts to explain, you still insist on using the term "memory" when discussing this issue, which means I've utterly failed to convey this clearly... :( :( B) B) :(

Despite all my efforts to explain, you still insist on using the term "memory" when discussing this issue, which means I've utterly failed to convey this clearly...

I can insure you that I perfectly understood all what you explained and the fact that, to your taste, I have used the term "memory" in an inappropriate manner, does not mean you failed to convey this clearly. French is my mother language and it is very difficult for me to express such complex things in English.Finally, You probably missunderstood (because of my poor English) the sense of my question. It was just a technical curiosity. No suspicion or fear, or whatever you want, about the /3GB trick. So I didn't needed to be convinced about the benefit to use it or not.Oh l

Thank you for explaining this phenomena in detail. Using the examples was particularly effective for me, and now I can comprehend the problem.After posting much earlier in this thread about experiencing only one OOM error since starting to use FS9 several years ago, it occured again (the second time) tonight after crossing LAM before the S-turn arrival to 27R at Heathrow at about 9 DME. Two miles before the first turn.I was at Mega-Frankfurt on the ground at A19 for nearly two hours while configuring WidevieW on another networked system. UT Europe is also installed on the FS server, and the destination was Mega-Heathrow. After finally pushing out of A19 at Frankfurt, during the taxi I noticed that the system was stumbling along at about 6FPS, then shoot up to 24FPS and smooth out normally. It did this several times during the long taxi down to 07R. I'm wondering if this was a warning of the developing problem I had before the approach into Heathrow. The frame rate stayed constant enroute on the server and the client and then it froze on the server at the point mentioned above. I didn't know about the error until minimizing FS. Apparently it is a random occurance, as you stated, as all of the same scenery is installed on the client and are basically the same computer both configured identically.I can understand now how these errors can occur. I'm going to try the 3GB switch and see how this improves. Will upgrading Win XP Pro to 64 bit have any consequences for FSUIPC, scenery installed or any add-on aircraft?

Upgrading to WinXP 64bit should have nothing but good results for you. :(

Red1Can you please direct us to UT USA unofficial patch that cured a problem for you?ThanksGhiom

Touch wood Red1 !!!ACS

:( :knocks on wood:As for the patch... http://www.simforums.com/forums/forum_posts.asp?TID=19685 Its the 1.30 version. Make sure you use all previous patches in order..AND after each patch you must make sure that you have all features selected in UT. After fully patched, you can use what ever features you like.

I have this one installed. It is not 'unofficial'??NevermindThanksGhiom

I changed the boot .ini to the 3GB switch and this seems to have worked.The same exact flight from Frankfurt to London was flown yesterday with no occurance of the OOM error. I did pick up some strange video artifacts such as large unplanted trees flashing briefly in front of the flight path, and other pastel colored flashing blocks and triangles, but the approach was completed without problems.I'm going to add the 'userva=2560' switch and see if it clears up. I've already installed this on the client, but I didn't have problems with the client machine during the flight. I will report back on the 'userva=2560' addition on the server machine in a day or two. I hope this clears the video artifacts. Incidentally, this only occured coming in to London during the approach before reaching LAM and several times past LAM, and then stopped.

I have this one installed. It is not 'unofficial'??NevermindThanksGhiom

The latest official retail patch is 1.21, as it is sold..and the official UT websites do not mention 1.3, so call it what you will. Also, the patch is done by different people, using a different installer.