Robert, read the link I just posted.

 

Julian, thanks for this link. It explains a lot. In this link, Peter mentions that in order to possibly avoid the OOM when you're aware it is near, you can try "saving the flight and maybe doing something like reloading memory or aircraft, to force a memory defrag." I know how to save a flight and how to reload an aircraft, but I don't know how one goes about "reloading memory." I'll follow up with Peter on this, or perhaps someone in this forum can explain.

 

Thanks,

Robert

One thing I have tried Robert, is to go from full screen to windows back to full screen, that seems to help, but not on every occasion. One thing, is if your on final, stay in the cockpit, don't use wing or spot view and 99% of the time I can land and park at the gate and finish the flight. Of course, saving the flight, restarting FSX is the guaranteed option.

One thing I don't do anymore is fly from a mega hub to another mega hub. For example, KJFK to KORD. More like KBUF to KORD. Small >Large >Small.

With all the latest eye candy, payware aircraft (NGX) and realistic weather themes coupled with maybe high settings and LOD, we are pushing boundaries that FSX was not designed for. So compromises must be made.

Julian, these are all excellent suggestions, and confirm my own experience and practices. What's most perplexing is that friends, some with with less powerful machines, but all using the same software and settings, do not encounter these OOMs, while I do. Thinking it was a hardware problem, over the past 6 months I have RMA'd or replaced every component except my hard drive and FSX installation DVDs, but to no avail. It appears that there's something on my system that is causing me to use memory less efficiently than others. And I can't figure it out for the life of me.

 

Robert

Julian, these are all excellent suggestions, and confirm my own experience and practices. What's most perplexing is that friends, some with with less powerful machines, but all using the same software and settings, do not encounter these OOMs, while I do. Thinking it was a hardware problem, over the past 6 months I have RMA'd or replaced every component except my hard drive and FSX installation DVDs, but to no avail. It appears that there's something on my system that is causing me to use memory less efficiently than others. And I can't figure it out for the life of me.

 

Robert

If you want, PM me your contents of your FSX.cfg and your system spec's and will have a look for you.

Bringing this thread back to life (and it's a VERY good thread).

 

I started having the same issue ... the chime. I don't recall installing ezdoc unless it comes with GSX or one of my FSDT airports? I'll have to check. Can anyone tell me where ezdoc hides itself if installed? I'm not seeing any references to it in my FXS.CFG nor in my DLL.XML The version of FSUIPC4.DLL is 4.8.6.0 but I can't remove FSUIPC4 as some products require it and frankly I like FSUIPC4

 

I'm pretty sure it's not an OOM issue, I've never had a CTD (well I have but that was one specific aircraft and it was a gauge causing the problem and that AC was removed along with cleaning up my FSX.CFG and other files) or any OOM messages.

Doesn't the latter FSUIPC versions have a warning when VAS is stating to get close to max?

Doesn't the latter FSUIPC versions have a warning when VAS is stating to get close to max?

 

Yes, that's what's being talked about here, isn't it? The Chime sound that you here is that indication, isn't it?

 

I'm curious too as to what can we do to "reload" things short of saving our flight and restarting it? Is there any way we can cause a reload without actually ending the current flight?

I started having the same issue ... the chime. I don't recall installing ezdoc unless it comes with GSX or one of my FSDT airports? I'll have to check. Can anyone tell me where ezdoc hides itself if installed? I'm not seeing any references to it in my FXS.CFG nor in my DLL.XML The version of FSUIPC4.DLL is 4.8.6.0 but I can't remove FSUIPC4 as some products require it and frankly I like FSUIPC4

 

I'm pretty sure it's not an OOM issue, I've never had a CTD (well I have but that was one specific aircraft and it was a gauge causing the problem and that AC was removed along with cleaning up my FSX.CFG and other files) or any OOM messages.

 

Check the FSUIPC4.LOG file, see if the OOM warnings are recorded there. If not, it isn't related to FSUIPC4.

 

If you don't want FSUIPC4 to check memory availability just turn it off in the INI file.

 

Pete

I don't see any options in FSUIPC regarding VAS? At least not in 4.8.6.

 

Check the FSUIPC4.LOG file, see if the OOM warnings are recorded there. If not, it isn't related to FSUIPC4.

 

If you don't want FSUIPC4 to check memory availability just turn it off in the INI file.

 

Pete

 

Hi Pete,

 

Nothing in the LOG.

 

OOMcheck=Yes ... I'll set this to No and see if that does it, otherwise it must be something else.

Some planes (Pilatus PC-12) chime when you are getting low on fuel. Increase your fuel and see if it stops. Also if the chime is related to the plane, something should show up in the CAWS (if you have one).

 

Henri

BTW, the FSUIPC impending OOM warning chimes are a double beep or whatever at 10 second intervals, not 2. And they are the standard Windows "exclamation" sound, on the current default sound device -- just a pair of "MessageBeeps" in fact. Messages are logged to the FSUIPC log at the same time:

 

**** WARNING! Free memory is very low!

 

 

For all our sakes Pete, Please leave it as it is!

 

Here's one for you brother. I can't find an explantion anywhere, but ths works.

 

I run three monitors for the VC in windowed mode. When I run really high end scenery (example: Manhattan X, FSDT KJFK), I keep my Memory Resource page up, place FSX at the top and then reduce the window to only show the memory that FSX us using.

 

Now when I hear the warning sound (thanks for that), I quickly check the amount of memory in use, then I "minimize" my three screens to one sceen by clicking the "box" (the center of the three windows-window minimize/maximize buttons).

 

When I do the above, the memory in use by FSX goes down SIGNIFICANTLY (reduced by 600MB to 1GB depending what scenery I'm running) and stays there even when I restore the screen to all three monitors. I can't find how or why, but it's not reloading any scenery when this happens.

 

Would that there was a routine running to accomplish the same thing without changing my screen size. I can live with this, but thought I'd mention it to my friend the Guru.

 

 

Dave

Would that there was a routine running to accomplish the same thing without changing my screen size. I can live with this, but thought I'd mention it to my friend the Guru.

 

Well different folks have found a variety of ways of getting memory freed up. One solution that, if correct, can be automated is the saving of flights -- using, say FSUIPC's autosave which can do this at intervals. I'm not sure why this recovers memory except that possibly it makes FS do some tidying first in order to collect the correct data for saving.

 

Some folks seem to think it is merely fragmentation of memory which causes the problem, rather that outright usage. If that were truly the case then an automatic garbage collection operation might do the trick -- but personally I don't think it can be simply fragmentation because the memory usage FSUIPC is computing is definitely only adding up allocated memory, and fragmented free memory is still unallocated even if only in small pieces.

 

I suspect it is just that the algorithms for allocating memory for different aspects of FS are separate -- the routines getting and freeing memory for objects not cooperating with that for textures and neither cooperating with that for aircraft data, and so on. Each is only freeing its own allocation when it needs memory, without considering other activities which need memory. They need their imaginary heads banging together to make them cooperate, and perhaps that happens when something drastic occurs, like saving flights or changing screen demands.

 

I emphasize that this is just my own theory. I don't know the FS internals well enough to actually know what is going on.

 

Regards

Pete

As I understand it ... some conjecture on my part ... FSX was coded mostly in C++ with some Assembler blocks. C++ (don't confuse this with C# and .NET framework) doesn't have built in GC (Garbage Collection) like C# and .NET. GC is actually a very complex subject, but some of the reasons to not manage de-allocations (destructors) can be performance based reasons.

 

When Aces introduced multi-threading into FSX (fetching of textures), I'm willing to bet they introduced a problem with de-allocation because GC in a multi-threaded environment is even more complicated to manage. I think multi-threading of textures was introduced in SP1. It might be an interesting test to see memory usage on FSX, FSX SP1, FSX SP2 with defautls (no add-ons) covering the same area. And it may also validate some of the threads I've seen here about OOM's starting AFTER installation of SP1.

 

Oh yeah, I made changes to the INI and haven't heard the chimes return ... no OOMs either. I'll keep testing to see if they are gone for good.

suspect it is just that the algorithms for allocating memory for different aspects of FS are separate

 

An interesting theory Pete.

 

Years ago I was trained as a computer engineer (hardware type) and of course had to learn some programming. I then moved to MSE/MCSE and down that path and completely away from programming. Boy did I take the wrong path! Today I do nothing with any of it, but I seem to remember a program that actually showed a dynamic map of what was in memory. I wasn't for DDR3 (didn't existing at the time) and I don't even remember if it had DMA. I'll search to see if something like that exists and see if I can apply it to a loaded down flight.

 

Saving a flight is understandable, but I wouldn't think that adjusting screen size would do anything similar. This leads me to believe there is something more going on here between VRAM and RAM. To check this, I might be able to set things so that VRAM isn't used at all. BP=1 maybe? I just don't know. Anyway ideas for that?

 

We may be on the hunt again!

 

Pete, your work is rather amazing my friend. We're blessed to have you in the community.

 

 

Dave

 

reasons to not manage de-allocations (destructors) can be performance based reasons

 

True enough! Excellent observation! hard to know if the ACES guys used that as a performance short cut, but with a few back in the game (literally) we may see an answer to that. So far, all of Lockheed's progress is one sided... they take and take from the community, but haven't shared any data. Hopefully that will change, as it's in their best interest to release information.

 

If one didn't realize it, the LM Program Manager was a genius to provide the software to our community, in effect LM gets a lot of help and ideas that way. Free testers too. Anyway, I love their model from a program management perspective.

 

Tell me, are you running basic, SP1 or SP2? Of course, please PM me, or at least Pete with the info. Understand why it's not releasable yet.

 

Thank so much!

 

Dave

This leads me to believe there is something more going on here between VRAM and RAM. To check this, I might be able to set things so that VRAM isn't used at all. BP=1 maybe? I just don't know. Anyway ideas for that?

 

Only in the sense that with a larger screen pixel count more of VRAM will be used to create the image and there will be less room for cached textures there, so changing the screen size or number of screens will have to force some rearrangement. Note that the number of pre-rendered frames (a setting in nVidia Inspector) must also affect how much VRAM is available. I've got mine set to 0 and am quite happy. I've never seen an OOM except one i deliberately 'staged' (by an allocation loop) to test my detection code. With a fast enough processor and video card there should be no need for pre-rendering. My i5-2500K is running at 4.8GHz. and my 580 has 3Gb overclocked VRAM.

 

Regards

Pete