There are no "disadvantages" that I can think of. Just as with any such tweaking though, it is possible to go overboard and thus starve the operating system of it's needed share of the virtual address table. This is why the recommendation from Phil to begin with 2056 as the targeted value was made. It will increase the allocated VAS for FSX a modest amount yet still leave enough for the OS to use.

Bill,

Does this apply to 64 bit OS and if so do you know what the default userva value is for windows 7 pro 64bit? I tried a Google search and didn't find an answer.

Ted

Again, it does not apply to 64b OS's. There's no point in setting the userva on your system Ted

 

 

Applications that are compiled with the /LARGEADDRESSAWARE option, as would be required to take advantage of the /3GB switch in 32-bit Windows, will automatically be able to address 4 GB of virtual memory without any boot time switches or changes to x64 Windows. Plus, of course, the operating system does not have to share that 4 GB of space. Therefore, it is not constrained at all

 

source: http://support.microsoft.com/kb/294418

Thanks Dazz. I always thought that a 64bit OS assigned 4gb of VAS to each 32 bit program and that is why I bought  W7 64 bit. However today I have read in a few threads that some of that 4gb is assigned to the kernal even in a 64 bit OS and that you needed to use the userva edit to allocate more to the program.

Are there any disadvantages of implementing the Fixit thing and settings the userva value in a x64 environment?

I manually changed the heap settings some time ago (edited the registry directly) and I've not found any drawback to it. On the other hand, I don't see much value either. I don't get a lot of OOM's, but in testing VAS limits, I didn't see any particular advantage. As others have mentioned the userva thing is a 32-bit issue only and worked in conjunction with the /3gb switch. It is not necessary or supported on 64 bit systems. There are numerous articles available confirming this.

 

On a 64bit system, FSX (and other 32 bit large address aware applications, of course) get a total of 4G of VAS.

 

Scott

More generalised, Windows assigns 2Gb of the 4Gb available to the application, the other 2Gb is for Windows. You can increase to 3Gb for the app with the switch.

 

Instead of worrying about that, take a look at your dll.xml. Since these dlls load with FSX and are called "in-process". Limit them to only those you need.

 

Addons like IF do not rob your FSX of memory since they are "out of process" and get their own 2Gb to muck around in. Have as many of those going as you like.

 

 

Avoid tweaking the fsx.cfg, it won't do much, more likely you'll crash.

Steve,

Just to clarify, based on what Dazz just wrote I am assuming what you wrote applies to only 32 bit operating systems and the switch isn't needed with a 64 bit OS.

Ted

 

More generalised, Windows assigns 2Gb of the 4Gb available to the application, the other 2Gb is for Windows. You can increase to 3Gb for the app with the switch.

 

Yes, ON A 32 bit version of windows, where the entire addressable address space for programs and OS is only 4G.  This does NOT happen on 64 bit systems.

 

From Mark Russinovich's blog on memory (and echoed in many other places):

 

"Because the address space on 64-bit Windows is much larger than 4GB, something I’ll describe shortly, Windows can give 32-bit processes the maximum 4GB that they can address and use the rest for the operating system’s virtual memory. If you run Testlimit on 64-bit Windows, you’ll see it consume the entire 32-bit addressable address space:"

 

All of this divvying up of the 4G space is irrelevant on a 64 bit version of Windows.

 

Scott

Yes, as I said if you want to talk about the /3Gb switch then I'm talking about the 32bit versions of Windows. On 64bit Windows there is a WOW64 process that provides a translation layer and other stuff in the 4Gb allocated to the 32 bit app. so you still don't get 4Gb, but like I said, you really don't need to worry about it.

 

Yes, as I said if you want to talk about the /3Gb switch then I'm talking about the 32bit versions of Windows. On 64bit Windows there is a WOW64 process that provides a translation layer and other stuff in the 4Gb allocated to the 32 bit app. so you still don't get 4Gb, but like I said, you really don't need to worry about it.

 

Steve, with respect, I'm clarifying because people are getting terribly wrapped around the axle with the difference between 32 and 64 bit Windows and are talking about applying 32-bit Windows tweaks to 64-bit Windows systems (the OPs) where they simply don't apply.

 

And to address your second point, I respectfully disagree again, though this may just be a matter of semantics.  A 32 bit, large address aware process (FSX in this case) can address a VAS of 4G.  All of it.  Yes, there is overhead inherent in the WoW64 dlls, and some potential memory inefficiencies from thunking, but the fact remains that the process can address 4G, not 3 and not 2, the address space does not include "windows kernel" stuff or system reserved space, and it can do it without special switches or options in the end-user's configuration.  That's what matters here from an end-user configuration point of view.

 

BTW, I agree that preventing unneeded dlls from loading is certainly good advice, but those that push limits (with complex aircraft, texture rich airport and scenery, high LOD radius and 4096 texture settings)will still find ways to OOM. :unsure:

 

Scott

Yes, I'm not disagreeing with anyone, I had just read through all the posts and concluded with the "generalisation" passage on memory use, I thought enough had already been said about it in the thread, certainly the fact that with the 64 bit o/s one need not worry. Not sure what you are disagreeing with me about though. My point was it's other stuff you need worry about.

I had never had an OOM until after I used "Word Not Allowed's Tweaks".  The culprit is the LOD setting.  6.5 will almost guarantee OOMs.  If you have the LOD=6.5 setting in FSX.CFG set it back to 4.5 and you won't have anymore issues.

 

I think that you all missed this...  He is spot on, LOD is the main culprit here (when running W7 64).  Reduce that and the OOM's go away.

From Mark Russinovich's blog on memory (and echoed in many other places):

 

"Because the address space on 64-bit Windows is much larger than 4GB, something I’ll describe shortly, Windows can give 32-bit processes the maximum 4GB that they can address and use the rest for the operating system’s virtual memory. If you run Testlimit on 64-bit Windows, you’ll see it consume the entire 32-bit addressable address space:"

 

This to me is the last word on this subject. Mark Russinovich is probably the most knowledgeable person on the planet on how Windows works at the core. His sysinternals tools are legendary and he was hired by Microsoft 5 or 6 years ago as a kernel design specialist.

 

The short answer on getting out of memory errors in FSX is that the "memory" being referred to isn't your physical RAM, it's the virtual address space for the FSX.exe process, which is mathematically limited to no more than 4GB. (it's technically the number of possible values for a bit - 1 or 0, so 2, raised to the 32nd power, which is 4GB when you do the conversion math to get to GB) Your in-use video memory also counts against this 4GB limit, so if you're running really high resolutions and setting really high AA levels and stuff, that's increasing the memory load on the video card, which means there's less address space available for FSX itself to use. It's very easy to get FSX itself up above 2 or 2.5GB of memory usage if you're using a lot of high end scenery and a high end addon aircraft - add a bunch of video memory usage to that and you're running on the edge - if it tries to go even 1 bit past 4GB you're going to get a crash.

 

Not sure what you are disagreeing with me about though. My point was it's other stuff you need worry about.

 

No worries Steve.  As I said, it was most likely a matter of semantics.  I think in this case we can agree to agree.

 

Scott

I was just amusing myself about not actually having all the 4Gb to itself. The thing you picked up on was really only a short line to lever off with my main points about dll's and tweaks.

 

Something to also consider may be the addon airports all enabled at once. Several could be in the bubble at once and if only one is required for the flight then it's best to have only that one hi res airport enabled.