Breaking the 4Gb Barrier w/ a Ram Drive

[mgh 89]

The best way to monitor virtual memory is to run VMMAP available here http://technet.microsoft.com/en-US/sysinternals

[Noel 4,498]

 

 

But if you don't want to listen what other people here are trying to say

 

I like listening to what people try to say, but that doesn't mean I accept it without questioning or clarifying.  The argument I am making hinges on comments I've read elsewhere that certain applications themselves can affect the OS' paging activity and therefore if that is true and those sorts of apps were built during a time when large amounts of physical ram weren't even considered, and paging activity occurs in an environment that doesn't even look for RAM over 4GB, as is the case in 32-bit OS, then ram drives absolutely provide value because they utilize physical RAM not even visible to that 32-bit OS. As I've already concluded in a 64 bit OS that is likely not the case, but even that argument hinges on whether or not an app such as FSX forces paging activity even when there is ample physical ram.

[Noel 4,498]

 

 

You may be interested in this thread over on FlightSim.com.

http://www.flightsim...ght=ssd ramdisk

The conclusion was that the RAM disk wasn't worth the trouble, at least in his setup.

 

Here is his summation:

 

While the SSD matched the RAMDisk's FPS performance, Panning, AI movements, and changing Views, did not seem to be quite as smooth. Awesome to say the least, just not quite as good.
As I saw when moving from a spinning drive to an SSD, the faster RAMDisk cut FSX launch, and flight loading times tremendously.

Was it worth it? Yeah, I had a riot doing it.  I satisfied my need-to-know, and in all actuality it was not that expensive.

If the results would have been more promising, I was ready to pop for a GSKill DDR3-2400 64GB set. No way, now!

 

It appears he noticed a difference for certain, but that it wasn't worth the effort.  He actually installed FSX completely into the RAMdrive so this test was really much bigger than looking only at paging activity.

 

What we are all tacitly hoping to see some day is a robust simulator engine that exploits modern hardware better than the clunker does:  multicore/multithreading, 64-bit native, DX11+ support, etc.  

[ccb777 3]

???

 

Why would you want to emulate a Disk Drive using memory, (RAM,) so you can the use the said emulated HD to emulate memory, (RAM.)

 

Isn't that sort of like robbing Peter to pay Paul?

 

Chris.

[Slayer 190]

???

 

Why would you want to emulate a Disk Drive using memory, (RAM,) so you can the use the said emulated HD to emulate memory, (RAM.)

 

Isn't that sort of like robbing Peter to pay Paul?

 

Chris.

+1  It's a dog chasing it's tail

[Tabs 2,790]

The best way to monitor virtual memory is to run VMMAP available here http://technet.microsoft.com/en-US/sysinternals

 

I don't think this utility can show virtual size, which is the important thing for FSX. Use Process Explorer and enable the Virtual Size column.

[Noel 4,498]

???

 

Why would you want to emulate a Disk Drive using memory, (RAM,) so you can the use the said emulated HD to emulate memory, (RAM.)

 

Isn't that sort of like robbing Peter to pay Paul?

 

Chris.

Let's say you were using a 32-bit OS as I was years ago when I first looked into using a ram drive.  My thinking was, since have 8Gb of RAM installed but my OS can only access 4Gb I can trick the OS into using the extra 4Gb of physical ram because it sees it as a disk drive.  So in this scenario, if when I run an app like FSX loaded fully, my 32-bit OS will write to the page file.  This write activity is much faster to a ramdrive compared to a fast SSD.   This is the basis of my assumption and I'm open to other interpretations for sure.   I've mentioned here it may truly be meaningless now in the 64-bit OS domain anyway.  

[ccb777 3]

And if you left the RAM alone, the OS would not need to generate all of the unnecessary page faults to access redundant RAM masquerading as a dirve. A RAM Drive is a DRIVE, not RAM, just a rather quick one.

 

All you end up doing is giving the system more work and the only thing you will achieve is to slow the system down.

 

Chris.

[LRW 42]

Here is a link to some Microsoft articles on how Windows memory is managed.

 

http://blogs.technet.com/b/markrussinovich/archive/2008/07/21/3092070.aspx

 

I read that series by Mark Russinovich a few years back.  It convinced me to keep a pagefile (which I ran without for a time). 

 

A couple of points come to mind:

1. A ramdisk will reduce the amount of physical RAM available to the system cache and to applications.
2. "1." may not matter once you've exceeded a certain threshold of physical RAM.  

Consider three scenarios:

• You have 8GB of physical RAM and a 2GB pagefile on a hard drive, your commit is 6GB, that will leave 2GB for cache and/or other processes in physical RAM plus the 2GB for swap.  
• You have the same 8GB of physical RAM, but you've allocated a 2GB ramdisk for the pagefile.  That 2GB ramdisk will now count as committed memory and be added to the previous 6GB, leaving you with 0 cache and 0 available RAM, but a fast 2GB swap file.  It's probably not going to end well.
• You have 16GB of physical RAM and you've allocated a 4GB ramdisk for the pagefile.  Your 4GB + 6GB (previous) commit is now 10GB, leaving you 6GB for cache and other applications (more than you had in the first scenario).

So the affect of a ramdisk pagefile will depend on how much total physical RAM is in your system, and how much headroom you had before allocating it.  If your available physical memory was never below 10GB, then allocating some of it to a ramdisk shouldn't hurt and might help.  If your minimum available was 2GB, then it might not be a good idea.

 

As with most things, I could be wrong (as my wife says) and YMMV (not an airport in OZ).

[Noel 4,498]

 

 

All you end up doing is giving the system more work and the only thing you will achieve is to slow the system down.
 
Chris.

 

Not when the alternative is to page to a HDD or even an SDD.

 

 

So the affect of a ramdisk pagefile will depend on how much total physical RAM is in your system, and how much headroom you had before allocating it.  If your available physical memory was never below 10GB, then allocating some of it to a ramdisk shouldn't hurt and might help.  If your minimum available was 2GB, then it might not be a good idea.

 

This, of course, was where I was going.  I have 32Gb of fast ram so the question was worth posing.  From what I gather though, and depending on how much influence the application has on paging activity in the OS, it may be quite moot in the 64 bit OS where the memory over 4Gb can be directly accessed by the OS for other system processes, even though FSX will only use what it can as 32-bit.  I think also even though RAM is way faster for read/write than an SDD even that may not offer much since the SSD isn't holding back much anyway.  I decided to create a fixed page file of 1Gb min/max and while using performance monitor I saw no paging during a longish flight in FSX, so indeed, it's moot in terms of a page file, and like almost moot even when loading other parts (or the entire FSX install) on a big ram drive.

[mgh 89]

I don't think this utility can show virtual size, which is the important thing for FSX. Use Process Explorer and enable the Virtual Size column.

It suggest it does . For example, for my vanilla FSX:

 

Process Explorer shows Virtual Size = 1,089,168 K and Private Bytes = 717.740 K

 

VMMap shows Total = 1,129, 852 K and Private Bytes = 757,396 K.

 

All the numbers fluctuate with time, even with the aircraft stationary on the ground. There's a small difference (4% max) between the numbers because, I believe, of the different ways the two applications count virtual memory.