OOM warning given by FSUIPC

[FSMP]

Pete,

I recently saw this post on an Avsim forum

For those that don't know, if you have the latest FSUIPC, you will get a windows "ding dong" to let you know you are close to getting an OOM. Give you a chance to save or continue.

If you look at the fsuipc.log.txt, you will see low memory entries once you get near the 4gb limit. A great feature.

I have a registered version, so not sure if it works in the freeware one.

Looking through the FSUIPC documenation and this FSUIPC support forum , I see no reference to this.

(maybe I missed it .. I'm getting old ! )

Is this really a recent feature added to FSUIPC, or is the "ding-dong" coming from elsewhere ??

Geoff

[Pete Dowson]

Is this really a recent feature added to FSUIPC, or is the "ding-dong" coming from elsewhere ??

Ah, clean forgot that. It was something I added a little while back to help me, personally, locate a memory leak in one of my other specific cockpit drivers -- and it did. I never took it out, but stupidly forgot to document it.

It not only logs it, and sounds a warning, but also provides a continual (10 sec interval update) running value of the amount of free FSX process memory left in an offset. Let me see ... ah yes:

32-bit integer value at offset 024C, free memory left in kilobytes. You could monitor that on-screen using the Monitor facility on the Logging tab.

It plays two Windows "exclamation" sounds when this gets below 300 Mb (i.e. 307200), as, in my case at least, it was soon after this that FSX was starting to play up, ending in an OOM crash.

Additionaly, if you set the Log Extras option in the logging tab, it logs the memory "in use" and "available" values, in Mb, once per minute during the whole session.

I'll add it to the Changes list next week. Off for the weekend in a short while ...

Regards

Pete

[FSMP]

Thanks Pete

Ref: "The FSX Process Memory left"

Is that the TOTAL amount of "Fragmented" memory left, or the Total of all the "CONTIGEOUS" blocks of free memory left, that exceed a given size ?

From what I have experienced and seen, while there may be quite a lot of small Fragmented blocks of memory left, totaling an appreciable size, as the memory gets fragmented, there reaches a time, where there is not a big enough "Contigeous" block, to satisfy a FSX request for a new given size chunk of memory, and then one gets an OOM, ( when it is now too late for FSX to do much about the failure to get that memory).

Geoff

[Pete Dowson]

Thanks Pete

Ref: "The FSX Process Memory left"

Is that the TOTAL amount of "Fragmented" memory left, or the Total of all the "CONTIGEOUS" blocks of free memory left, that exceed a given size ?

I use this:

			[b]ullAvailVirtual[/b]			
The amount of unreserved and uncommitted memory currently in the user-mode portion of the virtual address space of the calling process, in bytes.		[/CODE]

I don't think there's any way of getting only "contiguous memory above a certain size" without doing a complicated memory walking loop, which will detract from performance. I found the value I was computing good enough to predict problems -- graphics and other things started playing up at around 200 Mb left, followed by the OOM crash. The warning I set at 300 Mb seems about right to avoid these things, e.g. by saving the flight and maybe doing something like reloading memory or aircraft, to force a memory defrag.

Regards

Pete

[Flapsup]

Hi Pete,

Sorry for dragging up an old thread, but have been meaning to ask ( it was me that Geoff quoted above), when the OOM warning occurs, I switched from full screen to window mode and back to full screen, and the warning stopped. By doing that, is it forcing a memory defrag, or just resetting the warning ?

Rgds

Julian

[Pete Dowson]

Sorry for dragging up an old thread, but have been meaning to ask ( it was me that Geoff quoted above), when the OOM warning occurs, I switched from full screen to window mode and back to full screen, and the warning stopped. By doing that, is it forcing a memory defrag, or just resetting the warning ?

It isn't FSUIPC resetting anything -- it isn't even aware of such a switch -- so it must be FS defragging memory or even releasing some stuff it now finds out it doesn't need any more. Similar effect to saving the flight I suppose.

Regards

Pete

[Flapsup]

Ok, thanks Pete.

Rgds

Julian

[macwino]

Peter, in this thread you indicate 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." Could you please explain this further?

Thanks,

Robert

[Pete Dowson]

Peter, in this thread you indicate 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." Could you please explain this further?

Sorry, did I say "memory"? I meant things which could possibly rebuild stuff in memory and so cause it to free or defragment some. Things like "reload scenery" and/or "reload aircraft", both commands available for key or button assignment. I think they are called "Refresh scenery" and "Reload User Aircraft". Other things which might help are "Reload panels", and possibly FSUIPC's added "Traffic density toggle" -- use the latter twice to toggle between no AI traffic and your normal levels (this won't work with UT2 added traffic though -- it has it's own shortcuts for that).

Regards

Pete

[macwino]

Peter, thanks for the clarification. Refreshing scenery or the aircraft don't seem to solve the problem for me, but sometimes - at least on an approach - reducing AI traffic can make a difference. I've never tried reloading panels and will do so.

It's interesting, but you are the cause of my having OOMs, at least in Orbx PNW. Let me explain. Previously, my flights in PNW were of very short duration for I was plagued by g3d.dll errors. You solved that problem. But now that I was able to actually fly in PNW for more than 10 or 15 minutes, I then became subject to these OOMs. So I went from the frying pan into the fire. How about a fix for the OOMs? If anyone is going to do it, it is going to be you.

Thanks for all your assistance.

Robert

[Pete Dowson]

How about a fix for the OOMs? If anyone is going to do it, it is going to be you.

Sorry, I really wouldn't know how without wrecking performance -- FSUIPC or some other internal DLL would have to constanty pause the sim whilst it checked all the memory allocations, and made sure the freed ones were all collected. And I don't think that would even solve it because it is entirely possible that the memory genuinely is running short for needed assignments and/or there are lots of blocks which aren't really needed any more but which haven't been freed (yet). How can one detect blocks not being used? Only by intercepting the access to every one so that usage counts can be maintained. Imagine how slow FS would run! And suppose one not used for a while was then required again? The program would have to be able to re-assign and restore the data which it had discarded incorrectly. Not sure where it would store it -- in another Process perhaps (for more Process memory), or else in files. Redirecting memory access to such blocks would be impossible so it would have to work miracles with the memory that was allocated. Ugh. I don't think it is possible. the more I think about it the surer I become!

The only real solution is recompiling the whole thing as a 64-bit program. I bet that would kill many many add-ons stone dead in any case -- until they were also so treated (FSUIPC included).

Oddly, I've only ever experience OOM the once, and that was due to a bug in one of my own programs. I added the OOM detection into FSUIPC to track it down. I've also only ever experienced that G3D crash which I patch just the once, oddly in a standard test flight I use many many times -- EGCC to EGLL, with UK2000 airports. And I fly with pretty dense scenery and just about all of the add-on airports you can get for Europe. I don't fly outside of Europe these days (excepting near the Med coast, and Madeira / Azores / Canaries).

Regards

Pete

[Drew Melia]

Ah.... I've been frantically searching for the cause of the "ding dong".... figured out it was low memory but couldn't figure out what was generating it. Here's the thing though..... with version 4.751a I get nice smooth performance and no OOM warnings, and indeed no OOM failures. With version 4.8 or newer, not only do I get OOM warnings, but I get significantly lower performance - drops from the usual 18-20 FPS to 9-12 FPS - with a complex aircraft at a complex airport, no traffic, normal auto gen and FSX generated weather, but all the other settings at max -. If I regress to version 4.751a the performance springs back up again. Now, far be it for me to cast aspersions... but is there something in the newer versions that uses significantly more memory than the older versions, and might it be possible that something isn't releasing memory as it should? Are there functions - like logging - that I can switch off in FSUIPC?. Please appreciate, though, my system is pretty low-end... some products clobber my performance in FSX - notably pretty much any Aerosoft Scenery add ons.. I've got a lowly 3 gig RAM - I could go to 4, but that's about as much as my main board will take. If I'm careful which add ons I use, I can get away with it, but FSUIPC is pretty much essential, so if there's a problem there, I could do with some help resolving it.

Best Regards

Drew Melia

[paulmidd]

Thanks to Peter Dowson for his "024c" monitoring and "ping" in FSUIC. For me that has solved my particular OOM problem.

In hindsight, it all started when I installed MyTraffic X (which I now still prefer to UT, even though it did give me this problem). I didn't immediately blame it, because there were a number of other potential changes I made around the same time, including flying the PMDG NGX a lot, which does exacerbate rather than cause the problem. I was finding the system slowing, and FSUIPC "pinging", whenever I was in major city areas such as London, Amsterdam, Paris and even Venice with the Aerosoft Venice X scenery. They had been slower than other areas in the past, but never fatal. Now I found I couldn't fly into Paris in the NGX without the system dying from OOM. Paris had become a "no-go area".

I put 2 and 2 together when editing some AFCAD's, and noticing that there always appeared to be a duplicate (or triplicate if you include the MS default) AFCAD in the MyTraffic X folder. I shunted them all off to the recycle bin, and the free memory in Paris went up from around 200Mb to around 800Mb - no more OOM's.

Obviously this won't answer everybody's problem - there are lots of other add-ons out there waiting to guzzle our storage, but for anyone with MyTraffic X, it's definitely worth doing. There's no point in having all those AFCAD's with airline gate assignments for obscure airports in Bongo-Bongo Land if they are stopping you getting into your favourite airports.

[Pete Dowson]

With version 4.8 or newer, not only do I get OOM warnings, but I get significantly lower performance - drops from the usual 18-20 FPS to 9-12 FPS - with a complex aircraft at a complex airport, no traffic, normal auto gen and FSX generated weather, but all the other settings at max -. If I regress to version 4.751a the performance springs back up again. Now, far be it for me to cast aspersions... but is there something in the newer versions that uses significantly more memory than the older versions, and might it be possible that something isn't releasing memory as it should?

No, if anything performance is improved with 4.80 as several areas have been streamlined. The OOM check isn't currently optional, but i am going to make it so, so you could check with that switched off. However, all that does is read from Windows the amount of available and used process memory once every 10 seconds approx, so i don't really see how that could have such an effect.

The recent versions are of course reading PMDG 737NGX data is it is enalbed in the latter's INI file It is only doing this when SimConnect notifies it of a change, of course, but when flying such changes will be frequent. I don't think this will afftect anything noticeably though, it is a single block of memory of less than 512 bytes.

Are there functions - like logging - that I can switch off in FSUIPC?

Logging is negligible (take a look) unless you've enabled some options. But definitely check the log in any case. One thing that can clobber performance is a SimConnect problem which causes FSUIPC to continually try to reconnect. Those events are logged.

Regards

Pete

[Drew Melia]

OK, Thanks Pete.... I didn't expect there to be an issue with your code... I've been using it for years now, and on its own is the single most significant enhancement to flight simming - without it, very few of the things we take for granted today would have ever been possible. Pity you don't work in healthcare informatics - would make my life a whole lot easier!

I'll check the logs though...it could well be that I have a problem with SimConnect.

All the best, Drew

[Pete Dowson]

OK, Thanks Pete.... I didn't expect there to be an issue with your code... I've been using it for years now, and on its own is the single most significant enhancement to flight simming - without it, very few of the things we take for granted today would have ever been possible. Pity you don't work in healthcare informatics - would make my life a whole lot easier!

I'll check the logs though...it could well be that I have a problem with SimConnect.

Okay. The latest version (4.828) now has an "OOMcheck=Yes" entry in the INI, so you can turn it off if you like by changing that to 'No'.

Pete

[zulhilmi202]

Okay. The latest version (4.828) now has an "OOMcheck=Yes" entry in the INI, so you can turn it off if you like by changing that to 'No'.

Pete

Okay. The latest version (4.828) now has an "OOMcheck=Yes" entry in the INI, so you can turn it off if you like by changing that to 'No'.

Pete

Mind if I ask, where do I get that (4.828) version of the FSUIPC? I'm using FSX and I'm getting those warnings sounds and it annoys me. It would be great if I could turn that thing off. Thanks!

Regards,

Zulhilmi

[WebMaximus]

Thanks to Peter Dowson for his "024c" monitoring and "ping" in FSUIC. For me that has solved my particular OOM problem.

In hindsight, it all started when I installed MyTraffic X (which I now still prefer to UT, even though it did give me this problem). I didn't immediately blame it, because there were a number of other potential changes I made around the same time, including flying the PMDG NGX a lot, which does exacerbate rather than cause the problem. I was finding the system slowing, and FSUIPC "pinging", whenever I was in major city areas such as London, Amsterdam, Paris and even Venice with the Aerosoft Venice X scenery. They had been slower than other areas in the past, but never fatal. Now I found I couldn't fly into Paris in the NGX without the system dying from OOM. Paris had become a "no-go area".

I put 2 and 2 together when editing some AFCAD's, and noticing that there always appeared to be a duplicate (or triplicate if you include the MS default) AFCAD in the MyTraffic X folder. I shunted them all off to the recycle bin, and the free memory in Paris went up from around 200Mb to around 800Mb - no more OOM's.

Obviously this won't answer everybody's problem - there are lots of other add-ons out there waiting to guzzle our storage, but for anyone with MyTraffic X, it's definitely worth doing. There's no point in having all those AFCAD's with airline gate assignments for obscure airports in Bongo-Bongo Land if they are stopping you getting into your favourite airports.

Sorry to wake up and old thread here but I found this one very interesting. I just learned about that Windows "dong" sound I've been wondering where it came from and what triggers it until someone told me in another forum it's FSUIPC warning you you're getting close to an OOM error.

Then after reading through this thread and in particular what you're saying about removing stuff you don't use to save memory and resources for stuff you do use that made me start thinking maybe there are some things in FSX I could remove/disable as well. I don't use My Traffic since I do all my flying online on IVAO but maybe there are other things I could remove that would have a similar effect freeing up resources for FSX.

I have a rather powerful FSX rig and I seldom have problems and my overall performance is very good but sometimes I still get problems like with the newly released Mega Airport Helsinki by Aerosoft which has given me some OOM errors. I'm thinking that since I do all my flying to only a limited number of specific airports maybe I could free some FSX resources for flying to these airport/areas by removing/disabling airports/areas where I never fly...would that be possible and would it have a positive effect on FSX's resources/performance?

[Pete Dowson]

I have a rather powerful FSX rig and I seldom have problems and my overall performance is very good but sometimes I still get problems like with the newly released Mega Airport Helsinki by Aerosoft which has given me some OOM errors. I'm thinking that since I do all my flying to only a limited number of specific airports maybe I could free some FSX resources for flying to these airport/areas by removing/disabling airports/areas where I never fly...would that be possible and would it have a positive effect on FSX's resources/performance?

I think removing airports and sceneries you never go near would only improve loading times, not really help with performance and OOMs -- excepting that one side effect of less airports is less AI traffic arriving from those airports.

Pete

[WebMaximus]

I think removing airports and sceneries you never go near would only improve loading times, not really help with performance and OOMs -- excepting that one side effect of less airports is less AI traffic arriving from those airports.

Pete

OK, thanks Peter - what you say makes sense.

[doudou]

It seems with FSUIPC 4.90 that I have lost the FSUIPC warning when I am getting close to an OOM error. I appreciate this warning. How to get it back ?

[Pete Dowson]

It seems with FSUIPC 4.90 that I have lost the FSUIPC warning when I am getting close to an OOM error. I appreciate this warning. How to get it back ?

There's no difference, it is still there.

Pete

[von]

FSUIPC 4.9

My first looks at memory using FSUIPC.

"Additionaly, if you set the Log Extras option in the logging tab, it logs the memory "in use" and "available" values, in Mb, once per minute during the whole session."

I looked in the log for this : "in use" and "available" values, in Mb"

But I do not see it in the log.

I see this in the log for example:

168574 Ready Flags: Ready-To-Fly=N, In Menu=N, In Dlg=N

174019 Monitor IPC:024C (S8) = -112

184050 Monitor IPC:024C (S8) = -84

204158 Monitor IPC:024C (S8) = -80

....

.... ETC

695483 [buttons] 13=R1,38,C65671,0

695514 [buttons] 13=R1,38,C65671,0

695514 Repeating flag set: bRef=0, Joy=1, Btn=38 (RepeatDelayCtr=11)

695514 FS Control Sent: Ctrl=65671, Param=0

695546 [buttons] 14=U1,38,C66416,-1

695546 FS Control Sent: Ctrl=66416, Param=-1

696794 Monitor IPC:024C (U8) = 108

698057 Ready Flags: Ready-To-Fly=Y, In Menu=Y, In Dlg=Y

698057 Sim stopped: average frame rate for last 33 secs = 29.1 fps

704641 System time = 22/05/2013 13:34:12, Simulator time = 07:38:15 (14:38Z)

704641 *** FSUIPC log file being closed

Average frame rate for running time of 466 secs = 29.1 fps

G3D fix: Passes 28360, Null pointers 0, Bad pointers 0, Separate instances 0

Memory managed: 191 Allocs, 191 Freed

********* FSUIPC Log file closed ***********

[Pete Dowson]

"Additionaly, if you set the Log Extras option in the logging tab, it logs the memory "in use" and "available" values, in Mb, once per minute during the whole session."

I looked in the log for this : "in use" and "available" values, in Mb"

But I do not see it in the log.

Ah, sorry. Yes. A typo in the code. Sorry. I'll fix that in 4.903 later today. Meanwhile you CAN get this display every TEN seconds by adding these two lines to the [General] section of the INI:

Debug=Please

LogExtras=4096

The "Debug=Please" allows the Log Extras option in the Logging tab to contorl a lot of different logging options, mainly used to debug folks' problems.

You can change the value "4096" in the Logging tab once "Debug=Please". Change it back to 1 for the normal LogExtras=Yes option.

Regards

Pete

[von]

Pete,

Thanks for the follow up answer.

Have a nice day.