Jump to content

Confusion Over 4 GB Limit???


Recommended Posts

Shalom and greetings all my pals,

 

Experts told me in their words "FS2004 and FSX as well as FSX Steam are 32-bit programs, so neither will recognize nor use more than 4 GB of RAM, no matter how much RAM your computer may have."

 

Actually, I am very baffled!!!  If it is limited to 4 GB ram, why do people need powerful systems to run FSX with addons?  I must have missed something or PC PILOT magazine forgot to explain about this??? :)

 

Regards,

Aharon

 

Link to comment
Share on other sites

RAM isn't the main issue. It's your CPU that's most important. A good running CPU with good cooling system is essential for running FSX smoothly for extended periods.

 

That's not to say that RAM isn't important. It is. But like you said, FSX will only use 4GB of RAM from whatever RAM is available. Having 4GB of RAM on your PC still won't be running at full strength though. Ideally, you need at least 8GB of RAM. If you only have 4GB, some of that will be allotted to other background tasks on your PC, so you may find that FSX only has 3GB of RAM available.   

Link to comment
Share on other sites

  • 1 month later...

In addition to RAM, 32 bit programs have a limitation on Virtual Address Space (VAS), which is how much processing data you can load before the system runs out of available memory and your sim crashes (approx 4MB).

 

A "vanilla" FSX installation is running 20 FPS, autogen is low, level of detail (LOD) is medium, special effects (ie, jetways) are low.

 

When you start increasing FPS, add on scenery, add on airports, add on weather textures, AI traffic, add on vector (roads and coastlines) and increase the LOD, it will need to use more and more of VAS to process all the eye candy.  Increasing your settings to max with all those add-ons can run you out of VAS "memory" (you could still have lots of RAM available) and the system will crash.

 

Faster CPU's and more powerful GPU's make the sim run smoother, but you will still be chasing the VAS limits of 4MB.

Link to comment
Share on other sites

Virtual Address Space (VAS) is simply a mechanism by which a 64bit-native environment can host 32bit processes.

 

It's all about memory byte addresses. In a 32bit environment, memory addresses are 4 octets long. In a 64bit environment, memory addresses are 8 octets long.

 

Imagine we're building a [crazy] new telephone system. Everybody we connect to our system of course needs a unique number, so that the right person can reach the right person. We also need to set a format (limit) to the numbers, so telephone numbers are uniform in length and therefore recognisably phone numbers. Let's say we only ever expect to connect a few thousand people to our telephone service, so we decide a 32bit range of numbers is more than enough. That means our available phone numbers are 0000000001 to 4294967296. Now, there's a population explosion, and suddenly we need lots more telephone numbers; so we decide to move to a 64bit range. Now our numbers are 00000000000000000001 to 18446744073709551616, but immediately there's a problem. Our first customers (the 32bit ones) all expect to use the shorter number format, so if we wanted them to continue to operate in our new 64bit system, we'd have to block-out the first 4,294,967,296 numbers for those customers, and somehow zero-pad them at the exchange when they're called.

 

In computing terms, this would mean that for 32bit programs to run in 64bit address space, the first 4,294,967,296 byte adresses (4GB) would have to be reserved for 32bit programs. This would work, but it's far from ideal, because it means that the first 4GB of memory in a 64bit computer isn't available to 64bit programs - let's say the computer has 16GB memory, 32bit programs would be able to use up to 4GB as they always have (because they use the shorter telephone numbers which our telephone exchange zero-pads), but 64bit programs would only be able to use 12GB, because the first 4GB worth of addresses are blocked-out run [zero-padded] 32bit programs.

 

Ideally, we'd have all 16GB of memory available to 64bit programs, and just give 32bit programs the memory they need if we ever use them. Of course the problem here is that if you're using the first 8GB of memory in Photoshop 64bit, you can't start a 32bit program, because all the [zero-padded] addresses it understands (and more) have been taken up by Photoshop.

 

Enter Virtual Address Space...

 

In effect, a system for virtual addressing works as a container and a translator. To run our 32bit program when we already have Photoshop chewing 8GB, we 'fence-off' some memory (up to 4GB - because that's all it could ever understand) for the 32bit program, inside the fence (container, Virtual Address Space) we effectively give each of our 64bit addressed memory bytes another (fake/virtual) 32bit long address, so the 32bit program can read from and write to physical memory after the first 4,294,967,296 bytes without ever needing to know about it.

 

Regards,

 

Rob.

 

PS> Memory in excess of 4GB for a FSX/P3D system is preferable because with more, the simulator can be given a full 4 gigabytes of virtual addresses, and there still be physical memory available to other processes.

 

PPS> Mathijs' assertion that MHz is most important for RAM is fair, but not strictly accurate. DDR4 architecture does have throughput advantages (despite its often higher latencies), such that DDR4 clocked at the same speed as DDR3 should in theory be faster; however DDR4 is generally clocked at far higher speeds (DDR3 tops out at 1800(ish) [stock] MHz, DDR4 3200MHz+), which as Mathijs says, will yield massively higher throughput; and is the architecture of the memory controllers in the quickest CPUs - and as nealmac suggests above, FS chews CPU. The other advantage(?) is the availability 16GB modules - in case you like to leave huge Photoshop projects open while you fly FS! ;)

 

NB: Memory throughput is only really good for FPS, though - memory being read/written faster means the sim can render frames quicker, so you get more per second. Memory throughput doesn't really help with OOM however; you can fly 200fps toward a huge airport covered in AI all with 4096px textures, but as soon as the system tries to load more than 4GB worth of stuff into the memory, it'll run 200fps into the same OOM :)

Link to comment
Share on other sites

  • 1 month later...

Thanks Buddydog and Factionone for more explanations.

 

My apologies for not realizing that discussion in my thread had continued.

 

Regards,

 

Aharon

Link to comment
Share on other sites

  • 1 year later...

Since there is some information about the 4GB-limit and running out of "VAS-memory", I will add my question to this thread. I'm using FSX.

 

So when I had a flight with a few addons (FTX Global, Vector, Weather, Addon-Aircraft), I would always end up in a sim-crash after some time (45-90mins). The sim always crashed when I clicked on something (e.g. cockpit switch or menu button).

 

My sim was not a clean set up, with addons that I had added over the time, probably conflicting with each other. I always read in forums that OOMs occure, when the sim was not set up in a clean way. So I decided to do a clean reinstallation of the whole sim and only installed addons I really wanted to keep.

 

But hey, problem continues. I just got only the FTX products installed (Global, Vector, LC, no weather) and did the Apple mission (=default AC, airports) - just before the finish afer ~60min, lights went out.

 

I was aware of the RAM-problem with FSX, but some aspects I read in the last few days on the internet were new to me: That the VAS-memory has often the problem, that it does not "empy" itself while the sim runs. So it keeps filling and filling until... boom. Sim crash. And that you can't really do anything about it but delay the inevitable by reducing the rate the pot gets filled = reducing VAS-intensive addons. Or you have to save your flight in intervalls and restart the sim to empy the pot before you continue.

 

Is that true? I can't really believe it, I always assumed the crashes were related to my messy FSX. I mean, how is one supposed to do a long haul flight with the PMDG 777 then? Do I have to restart FSX in 60min-intervalls to avoid crashes, assuming I use some addons? I'm really interested in information about this topic...

 

System Info:

Win 7 HP 64bit

FSX Gold Edition

i7-2600

GTX 1050ti

8GB RAM

Link to comment
Share on other sites

  • Aerosoft

Long haul flight in a complex aircraft with a large set of other add-ons is indeed not without risk. Keep in mind you are using a 11 year old simulator in a 9 year old Operating System. That comes with serious limitation that you simply can't ignore without consequences. Why do you think so many people moved to Prepar3D v4 that does not have these limits and allow far more (and far more complex) add-ons, better stability and better FPS?

 

Win 7 and FSX are both not great in memory management, they often do not release memory fast enough. Running on Win10 helps with the PS part of the problem, it makes the sim simply more stable. Some add-ons have memory leaks, that's why you need to keep an eye on the available VAS while you use a complex set of add-ons, at least you see the problem coming that way.

 

In the end, only using less add-ons, using lower settings or upgrading to better software will solve the issue. 

 

Link to comment
Share on other sites

Alright, thanks for your quick answer! That was never clear to me before, I always thought you can fix the OOMs by setting up everything correctly... At least I know now that the problem is bound to Win7/FSX and I can consider if I want to move to Prepar3d. Thanks!

Link to comment
Share on other sites

  • 1 month later...

Just stumbled across your explanation of VAS, @FactionOne - and also two years later, it is still an excellent and very informative post! If only every computer expert could explain those difficult subjects in such understandable words. ;-) Great job!

Link to comment
Share on other sites

If you talk about memory and memory speed, do not ignore the latency. Nowadays, you can get RAM modules with clock rates of 4000MHz and above, yet sometimes the latency is sacrified for those high clock numbers. Example:

 

you can buy 3200MHz modules with CL14. This provides you the bandwith of 3200MHz (roughly 51GB/s, DualChannel) together with a rather low latency translated to roughly 8.75ns. Now, Marketing still focuses on the MHz number and you can find modules with 4133MHz and CL19 or even CL20. While those modules will offer you higher bandwith (roughly 66GB/s), the latency is actually worse than for 3200MHz CL14 modules (CL19 = 9.2ns, CL20 = 9.7ns). To have a comparable latency with 4133MHz modules, you would need CL18 or below.

 

As a matter of "fact", some tests back in the FSX days by Rob Ainscough showed that as soon as you are around 50-60GB/s, you reach a plateau where more bandwith does not provide you any benefit anymore. That's why rigs with Quad-Channel mainboards usually do not need that high clock speeds on their memory. Thanks to the Quad-Channel, already the basic 2133MHz DDR4 modules will provide you with 68GB/s. This is basically also the reason why using 2x modules is always better than a single module. Loosing the DualChannel Interface simply reduces your bandwith for no benefit.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy & Terms of Use