I'm no scenery expert but I was under the assumption FSX builds a scenery database with indexes ... if not, what exactly is FSX doing any time I change my scenery and FSX shows me a message "Building database/indexes" at startup?

 

Yes, it does collate some information and creates a file for it in each layer's folder. I have no idea why it didn't use that method more gainfully.

 

I do remember the days of TSR ... hmmm ... in todays OS I think one would need some kernel driver that could communicate to a user-mode app (aka FSUIPC) or maybe a Windows Service to "try" to solve this problem.

 

 

Actually you can hook regular Windows API calls pretty easily. I do it with Jeppesen FlteMap in FStarRC to create FS and APL plans. FSUIPC does quite a bit of "hooking" in order to achieve the things it does. But I've not wanted to venture into this area as I don't really understand what it is doing sufficiently, and to be honest i'm no spring chicken any more and my investigative skills are waning (and of course i am getting lazier ;-) ).

 

I get around it in my system by limiting my flying area to greater Europe (my cockpit is a 737NG so that suits me fine), and using SSDs which, despite what others say, I do think help with smoothness, provided you separate things out. I have one SSD for Windows, one for FSX and the stuff it can't do without, them most sceneries on a separate SSD.

 

What FSX really "needed" was a better "internal" memory management system, that prevented Fragmentation

 

It's not an area I'm so well clued up on these days, but on the subject of memory fragmentation, as far as I was aware this is all "virtual memory" in any case, mapped to physical memory via tables, so fragments can often be made into continuous chunks by re-mapping, not by having to move things around. I think the problems arise more because of the time taken to do this sort of thing. If the demand rate outstrips the computation and rearrangement rate you risk having to deny (temporarily) a memory request.

 

FSUIPC's free memory is a total of all fragments. I did do something based on sizes but it can be quite time consuming and in the end, by experimentation, found that the total free was the more reliable measure.

 

Finally, I have a very strong feeling that some, maybe all, OOM events result from either corruption of data such that memory is not freeable, or simply memory leaks. Whether these are really due to bugs in FSX code, or bugs or mistakes in add-ons, is another matter. I think many add-ons do try to stretch any 'rules' about scenery and cockpit design rather, and may go too far at times. The G3D crashes folks experience are definitely down to coruupted chains of data blocks in memory -- at least the ones I've examined.

 

Regards

Pete

 

 

To enable it, go to the. FSUIPC "logging" tab.

In the first box marked "specific value checks", enter the value "024C"

Change the "type" associated with that value from "S8" to "S32"

You may then select the checkbox to have the value at offset 024C displayed either within the FS main window, or in the upper title bar.

 

Sadly, couldn't get this to work ... FSUIPC 4.9 (May 2013).  Always displays a value = 0.

Sadly, couldn't get this to work ... FSUIPC 4.9 (May 2013).  Always displays a value = 0.

 

I think you must have set "OOMcheck=No" in the FSUIPC4 INI file. That switches it off.

 

Pete

 

 

I think you must have set "OOMcheck=No" in the FSUIPC4 INI file. That switches it off

 

Thanks Pete, that did the trick.

 

Did some more testing with disabling of scenery and how it affects memory usage and a few other misc. notes:

 

1.  Default Garmin G1000 GPS window consumes about 500KB (ouch) and doesn't deallocate memory after closing the GPS window (will avoid the GPS window usage).

2.  The Bombardier CRJ-700 consumes about 400KB less than my Just Flight BAE 146-200, haven't tested PMDG 737 NGX yet

3.  UK 2000 Heathrow, VFR UK (volumes 1-3), Traffic 360, REX OD - my BGL cap to avoid problems loading HiRes textures appears to be around 8000 (enabled)

4.  I ran a closed rectangle flight path around heathrow and London for about 3 hours and memory usage continued to be consumed down to the point of OOM (per Geoff's comments about VAS) - in the CRJ-700, so there does appear to be a deallocation/allocation problem with VAS.

5.  Changing views has minor memory impact and once impacted does NOT seem to continue to impact if I repeat view cycles.

 

For reference, some of what my FSX.CFG contains:

 

AirlineDensity=10
GADensity=10
FreewayDensity=10
ShipsAndFerriesDensity=10
LeisureBoatsDensity=5
IFROnly=0
AIRPORT_SCENERY_DENSITY=3
SWAP_WAIT_TIMEOUT=2
IMAGE_PIXELS_FOR_AUTOGEN_POLYGONS=2048
BATCH_AUTOGEN2=1
LOD_RADIUS=9.500000
MESH_COMPLEXITY=100
MESH_RESOLUTION=25
TEXTURE_RESOLUTION=29
AUTOGEN_DENSITY=5
DETAIL_TEXTURE=1
WATER_EFFECTS=4 

CLOUD_DRAW_DISTANCE=7
DETAILED_CLOUDS=1
CLOUD_COVERAGE_DENSITY=8

Mode=2560x1600x32

MultiSampleQuality=4
MultiSamplesPerPixel=16

TEXTURE_MAX_LOAD=4096
NUM_LIGHTS=8
AIRCRAFT_SHADOWS=1
AIRCRAFT_REFLECTIONS=1
COCKPIT_HIGH_LOD=1
LANDING_LIGHTS=1
AC_SELF_SHADOW=1
EFFECTS_QUALITY=2
GROUND_SHADOWS=0
TEXTURE_QUALITY=3
IMAGE_QUALITY=0
See_Self=1
Text_Scroll=1
D3D10=1

 

Before anyone tells me how crazy I am for running this CFG, I know I am.  BUT, it is what I like to run regardless of the "not designed to do that" clause ... retaining these settings is important to me.

 

Anyway, this is about as much testing as I want to do right now ... time to fly in a very carefully prepared FSX Flight Plan

 

Cheers, Rob.

 

Lol, I'm afraid after seeing these entries in your cfg nobody in the know will want to follow this thread:

 

LOD_RADIUS=9.500000

TEXTURE_MAX_LOAD=4096

 

 

Dirk.

Lol, I'm afraid after seeing these entries in your cfg nobody in the know will want to follow this thread:

 

Not really trying to get followers ... just presenting my data/findings, what other's do with this info is entirely up to them, I'm not selling anything.

 

But in case I didn't mention it already, LOD_RADIUS=4.5 and TEXTURE_MAX_LOAD=1024 made absolutely no difference with the problem of loading HiRes tiles when one has A LOT of scenery areas enabled ... in my testing it appears to be all about BGL quantity issue.

 

1.  Default Garmin G1000 GPS window consumes about 500KB (ouch) and doesn't deallocate memory after closing the GPS window (will avoid the GPS window usage).

 

 

4.  I ran a closed rectangle flight path around heathrow and London for about 3 hours and memory usage continued to be consumed down to the point of OOM (per Geoff's comments about VAS) - in the CRJ-700, so there does appear to be a deallocation/allocation problem with VAS.

 

 

 

 

Cheers, Rob.

 

Rob

 

Ref GPS.   When you say "closing the GPS window", I assume you mean, closing the window  that DISPLAY the GPS ?    The GPS is still running, so I would expect it to continue to be using its memory  ??

 

The only way one would expect to unload the GPS, and let it return memory, would be to switch to another aircraft, that did  not have that GPS.

 

If you are going to do any further testing, you might consider,  distinguishing between FSX scenery memory issues, and aircraft memory issues.

 

In order to test for scenery memory leaks, maybe you need a MINIMAL Aircraft,  without Gauges  -- especially no addon dll gauges  --   who knows what nasties might be going on in those  :(         All you need is to be able to move with the scenery, to cause additional scenery to be loaded, and hopefully, old scenery to be de-allocated.

 

Maybe the "test" gauge you need is one that can be controlled, on user demand, within FSX, to request memory  of various sizes, and to, on demand, de-allocate.

It may then be possible, with that VM monitor program, to see the VM address space getting fragmented, and thus potentially force an OOM.

 

What I have seen, over the years since FSX was first released, is an increasing number of pilots,  with multiple freeware & payware addons, finding it increasing difficult to run FSX for any significant length of time, (Hours) before either locking up, or being told they have run out of memory.

 

I think this is one reason, why those recently installing P3D, see a more stable system, as they have yet to load their system up with a  collection of suspect addons.

One of the best things  have found for reducing virtual Address Space usage in FSX is managing the DLL's that get loaded at start up! Many of which will not be needed in your flight session. (You don't need Wilco DLL's when flying PMDG.) It's a little inconvenient but wort the effort. Add the following line to each of the entries that you do not always need loaded, usually aircraft addons. Leave the ones you always use/need alone.

 

<ManualLoad>True</ManualLoad>

 

If the line is already there, but set to False, just change to True. Now when FSX tarts, it will ask you if you want to load each DLL set. Answer no to all but the ones you intend to use.

2.  Some well know Aircraft developers and Microsoft appear to be referencing fonts that may not exist on the destination computer (not a big deal, just a little sloppy).

 

http://robainscough.com/images/f1f7ca7fccc49854e361a8cfc0365a8b.jpg

 

That is an actual legitimate font file we use. (it's the electrical display on the overhead) Are you missing the file somehow?

One of the best things  have found for reducing virtual Address Space usage in FSX is managing the DLL's that get loaded at start up! Many of which will not be needed in your flight session. (You don't need Wilco DLL's when flying PMDG.) It's a little inconvenient but wort the effort. Add the following line to each of the entries that you do not always need loaded, usually aircraft addons. Leave the ones you always use/need alone.

 

<ManualLoad>True</ManualLoad>

 

If the line is already there, but set to False, just change to True. Now when FSX tarts, it will ask you if you want to load each DLL set. Answer no to all but the ones you intend to use.

 

Yep, been doing this for a while myself too. The other big one is disabling photoscenery areas you are not actually going to be flying over. Those allocate VAS like there's no tomorrow even if they're not in view.

robains, on 01 Aug 2013 - 10:00 PM, said:

 

2. Some well know Aircraft developers and Microsoft appear to be referencing fonts that may not exist on the destination computer (not a big deal, just a little sloppy).

 

 

 

http://robainscough....8cfc0365a8b.jpg

 

 

 

That is an actual legitimate font file we use. (it's the electrical display on the overhead) Are you missing the file somehow?

 

Ryan, I don't have that font either for the NGX, and I don't have a Windows\fonts\fonts folder (I do have the regular Windows\fonts folder itself. I don't see any PMDG labeled font in that folder.)  I did a drive search also and couldn't locate it.

 

Edit: I found it in the same folder Rob found it (Fonts folder under the FSX Home folder)! Don't know why the search didn't find it!

That is an actual legitimate font file we use. (it's the electrical display on the overhead) Are you missing the file somehow?

 

I do have the PMDG_NGX_ED.ttf font, but it's located in E:\Microsoft Flight Simulator X\Fonts not in C:\Windows\Fonts\Fonts ... I believe what is happening here is that a path is not being specified for the Font hence will default to OS path for fonts.  This is not a big deal, but typically an installer should registry a Font with the OS to avoid this problem ... fonts can be registered using gdi32.dll - AddFontResourceW - this would avoid the PATH_NOT_FOUND error.

 

 

 

One of the best things have found for reducing virtual Address Space usage in FSX is managing the DLL's that get loaded at start up!

 

Agree, I already do this as part of my flight planning process ... it would be really nice if there was a Flight planner that could do ALL this wrapped up in a single package (it would manage all the DLLs, scenery areas, FSX.CFG settings, etc. etc.).  Rather than using the ManualLoad, I use Disabled (<Disabled>True</Disabled>).

 

When I'm not flying the PMDG, the only DLL.XML module I have loaded is FSUIPC:

 

<Launch.Addon>

    <Name>FSUIPC 4</Name>

    <Disabled>False</Disabled>

    <Path>Modules\FSUIPC4.dll</Path>

  </Launch.Addon>

 

But another source is also the EXE.XML file, I do have two entries in there that I NEED/USE all the time:

 

<Launch.Addon>

    <Name>Couatl</Name>

    <Disabled>False</Disabled>

    <ManualLoad>False</ManualLoad>

    <Path>fsdreamteam\couatl\couatl.exe</Path>

  </Launch.Addon>

  <Launch.Addon>

    <Disabled>False</Disabled>

    <Name>GoFlight FSX Data Bridge</Name>

    <ManualLoad>False</ManualLoad>

    <Path>C:\Program Files (x86)\GoFlight\GFDevFSX.exe</Path>

    <CommandLine></CommandLine>

  </Launch.Addon>

 

As for the GPS window, it appears to load when I activate the window, hence 500KB hit.  If I never activate the GPS window (Shift + 3) I don't get a 500KB hit.  Sadly, when I close the GPS you are correct, it stays resident/active ... BUT if I never open the GPS window then it never gets loaded.  Note: this is the default GPS for default AC.  I did most of my testing with default AC, I load the BAE 146-200 for some other unrelated testing not specific to anything regarding scenery quantity (BGLs).

 

EDIT: On the EXE.XML front, those two executables actually run in separate threads and don't impact memory usage (at least in any significant way) -- confirmed this with Process Explorer.

Hi,

 

Unchecking hi-res add-on airports unlikely to be used during the flight; I've always recommended this to allow FSX to defer to stock scenery. Disabling unused .dll's is also recommended since .dll's run in the process space of FSX and if an add-on can be made to run out of process with FSX then it should be designed to operate as an .exe. Basically .dlls and over ambitious airports can spoil the show. Avoid using hi-res planes as Ai aircraft for similar reasons.

 

Missing fonts are not an issue in Windows; the system is set up to find fonts and allocate alternatives which may or may not be available on any system, and the reference to a ../fonts/fonts folder is not disallowed and may not necessarily be a sign of sloppiness.

 

Windows allocates virtual memory blocks using page fault allocation and it's difficult to work out what impact an application has on the system via memory use; an application may need 400k and get allocated several Mb. Physical memory use in Windows is not straightforward and what goes on under the hood is getting ever more complex; for example, physical memory use in Windows 8 is deliberately fragmented and scattered with Address Space Layout Randomisation.

 

Regards

Steve

 

 

 

 

 

 

Windows 8 is deliberately fragmented and scattered with Address Space Layout Randomisation.

 

This is done for security so that there isn't a "known/consistent" entry point for Malicious software to leverage.  It does add a little overhead but it's really just another flavor of VAS.

 

Agree on your other points, see my thread just above your post.

 

 

 

and over ambitious airports can spoil the show

 

Only point I disagree ... isn't that why we all buy those titles PMDG, FSDT, etc. ... because of their ambition?

Hee hee, yes Rob “why we buy”, I see what you mean

Although in my defence I did say "over” ambitious, and those add-on's don’t fit in that category, thankfully. :}

Best
Steve

 

 

But another source is also the EXE.XML file, I do have two entries in there that I NEED/USE all the time:

 

Same here! They shouldn't use VAS allocated to FSX, since they are external apps, so they should not be a problem!