What about dual channel mode? I have to be honest that I’m not exactly what the requirements for dual channel mode are, but would going 2x1GB and 2x512MB work properly with dual channel mode? Each channel would have 1x1GB and 1x512, so it seems like it should work…
Windows XP will use 4 GB, but you have to do some tuning. You can do this as described in some Microsoft articles. Here is an example: http://support.microsoft.com/kb/291988.
My understanding is that this will allow it use “most” of it, but even then, it may appear in XP as less then 4 GB… even though it is indeed using it for “most” software applications.
First it was the hard drive size in Windows 98, and now RAM. Microsoft doesn’t plan far enough ahead.
Joe: this problem does NOT exist on Linux. It’s been many years since this problem was fixed in the Linux kernel. With Linux you can use at least 8GB of RAM (I believe it’s 16GB, but not sure) on a 32bit architecture. And no, applications don’t need to specifically support it or any of that crap. It just works right out of the box, without you having to mess with it.
So this IS in fact a Windows problem. Sure, it’s caused because of the architecture’s 32bitness, but other OS’s have worked around this for a long time.
I run Vista 64 RTM as my primary OS. Not in a VM, but on my Dimension 9200 with 4 GB of RAM. I must say that I am very impressed with the driver support on it. Everything works, from my GeForce 7900GS (some major glitches with the driver right after RTM, but they’ve been fixed now) to my soundcard (a C-Media… – though it can’t pipe mike/line-in sound directly to my speakers… WTF…).
I’ve had a lot of iTunes crashes (until 7.1 came out, that fixed the problem) and VMWare Server still isn’t supported on my platform at all (though that’s a Vista thing I believe, not a Vista 64 thing). 32 bit apps run great (you’d never know they weren’t 64-bit), with the exception that Visual Studio.NET 2005 can’t do edit and continue on 64-bit apps (wtf?).
Other compatibility issues: some browser plugins (Flash, I’m looking in your general direction) aren’t compatible with IE7 64-bit, so I have to use IE7 in 32-bit mode most of the time. Not a big deal, though.
What I was most surprised at was the memory utilization. ALMOST ALL OF THE TIME, NO MATTER WHAT I AM DOING, over 2GB of RAM is used. I chalk a lot of this up to SuperFetch. And I must say that SuperFetch uses the memory WELL. Apps launch incredibly fast. VS.NET 2005 comes up (even with the .NET 3.0 CTP designers all installed) in about a second. So far, I’ve been extremely pleased. And yes, for a developer, 4+GB on a desktop with Vista is definitely worth it (especially if you also consider that apps intrinsically use more memory if they’re 64-bit native).
that is why i work on a mac. the g5 for the past 4 years gave us 64-bit memory space, worked great for us video editors, and there is no fall out between a 64-bit Mac OS X and a 32-bit. Acutally there is all this talk about dual binary (intel. ppc) for the past year but apple has been doing this since they had the G5 out there, 64-bit or 32-bit. now with the intel core duo 2s people can use more then 4GB of Ram… 64-bit CUP and all
cheers
Brandon: seriously, when you’re claiming the Mac is “behind the times technology-wise”, you’re making a total fool out of yourself (and no, I’m not a mac fanboy - I don’t even own one).
The effect of using the PAE switch on 32 OSs is NOT uniform based on how many cpu’s are in place. I’ve seen 1gb or less allocated to the OS and the remainder available for application use. When you expand beyound a single cpu, the partitioning of memory is not uniform either
the scheduler is very actively trying to spread out the load across multiple CPU’s. … Also PAE induces a translation table which degrades performance versus direct access. Memory above 4gb can only be used for db buffer space.
If we were all using DEC/Compaq/HP Alpha Processors invented
by Digital Equipment Corp and runs Windows NT 64, Linux, Tru64 Unix,
VMS, etc this discussion would be moot. The Alpha world was done
clean as 64bits from the ground up, 64 bit cpu registers, cache, and
memory, file system, etc etc. Intel stole proprietary info about
the Alpha from DEC, got caught, and guess what the punishment was?
They had to make Alpha chips for DEC at LOW cost for several years
in a brand new foundry. The Alpha processor (now hanging on only by
the virtue of the endless popularity and reliability of VMS which
everything from Blockbuster Video to Wall Street to hospital systems
to …
is pretty much the only exciting thing to happen in hardware
IT since the VAX which was the most exciting thing since the PDP-11.
Oh well, we always take a step forward and then take 2 back and we
have Intel to blame. You’d think they would have learned something
from what they stole about Alpha’s internals but no, we get the
Itanium and Itanium 2 abominations. All because everyone wants to
run ancient software FOREVER.
An interesting article. Thanks.
I still don’t own any computers with more than 512MB of ram, but me and my friend were arguing the possible benefits or myths of a 64-bit operating system just two days ago. This was very interesting.
What’s worse is that you’ve got a 64-bit processor (hey, wouldn’t that cover the 4GB’s of RAM) and you’re only running a 32-bit OS. Get a 64-bit OS and get rid of the problem, no hardware upgrade necessary.
Why are you running 32-bit Windows on a 64-bit machine anyways?
For those claiming that 32-bit flash will not work with 64-bit Firefox, do a search for “nspluginwrapper”. I have it loaded, and I can view any flash site in 64-bit Firefox 2.0.0.1 (on Linux).
Hmm, seems like it’ll only work on *nix platforms at the moment. Here’s the link if you’re a 64-bit Linux user and want to try this
http://gwenole.beauchesne.info/projects/nspluginwrapper/
Also check your distro, they may have this available as a package (Gentoo did).
In the interest of correcting the inaccurate information posted in this thread.
Physical Address Extensions (PAE)
Every IA32 processor since the Pentium Pro has had PAE36 allowing 64GB of memory to be physically addressed. Most AMD64/EMT64 processors have PAE40 allowing 1TB to be physically addressed however I believe the early 64bit P4s didn’t.
Cacheable Area.
On many processors the address space cacheable by the processor, and therefore practically usable is less than the size of the address space. For example the old Slot 1 Celerons could only cache 512MB and PII era Slot 1 CPUs could only cache 4GB. Having a 64GB cacheable area starting in the Xeon line and migrated down.
PAE OS Support
A poster further up was correct that a 32 bit OS cannot address more than 4GB. Address is the key word here it means that each process cannot have no more than 4GB of virtual address space. Nothing says that has to map onto physical RAM below 4GB. However the original poster was correct in that device memory must be below 4GB.
Microsoft artificially limited desktop versions of Windows to only support 4GB of physical address space probably due to the issues with device driver quality. However some server versions can address more, Microsoft can very tightly control what device drivers run on systems running these versions of Windows and therefore allow the PAE suport code to be switched on.
Windows 2000 Advance Server - 8GB Physical
Windows 2000 DataCentre - 32GB Physical
Windows Server 2003 Enterprise - 32GB Physical
Windows Server 2003 DataCentre - 64GB Physical
All other versions of Windows including Windows Vista do not have the PAE code enabled and cannot access memory which has been relocated above 4GB in order to make room for device memory.
Every version of Linux since the early 2.6 kernels has supported 64GB assuming the kernel was configured for it.
Chipset Support.
Even if the OS and the CPU support PAE it still might not be possible to map the physical RAM that has had to be moved to make space for the device memory above 4GB so it can be used. Chipset support is required to make this magic happen and, especially on laptop and “value” segment chipsets this magic is not present. This is the reason the MacBook Pro cannot support more than 3GB of physical RAM but the Mac Pro (based on Xeon processors and chipsets) can.
Address Window Extensions
This is a Windows API to allow a 32 bit process to address memory outside it’s 4GB virtual address space. It works by remapping memory below the 4GB barrier. It’s a horrible slow hack and never really caught on. MS did it because they needed it internally for things like the 32 bit version of SQL Server and Exchange.
AMD64/EMT64
As noted above processors implementing a 64 bit x86 instruction can address 40 bits or 1TB of RAM. A 32 bit program running under a 64 bit OS can still only use 4GB of virtual address space, where as a 64 bit program can use 64GB of virtual address space. The machine is therefore capable of physically addressing less memory than the programs running on it can virtually address.
Both MacOS and Linux support running both 32 and 64 bit binaries on a 64 bit kernel with no slow down.
Windows cannot do this and requires and emulated 32 bit subsystem called WOW (Windows on Windows) which incurs a slow down. Exactly the same was done with the transition from 16 to 32 bit Windows, in that case having a 16 bit emulated system on 32 bit Windows.
Real Big Iron processors such as POWER, Alpha generally have 48 or 50 odd bits of physical address space. In fact when the Alpha was being designed a customer complained that the processsor couldn’t do 64 bit physical addressing. DEC replied that if the customer was willing or order enough RAM from DEC to require the physical address space DEC would redesign the processor to support it 
To sum up
A good idea (PAE) was hamstrung in the consumer market by lacklustre OS support from Microsoft leading to supporting hardware not being designed to be compatible with it and driver support being broken.
PAE did extremely well in the server market due to rapid OS support via Linux and the ability for third parties to fix broken drivers in this OS. As it was in constant use supporting chipsets were designed and qualified to support it. Microsoft also eventually supported it in the server market but attempted to charge a premium for it.
PL - you asked “what 64 bit chipset uses 32 bit addressing ? That is by definition not a 64 bit chipset then”
Plenty of systems ship 64-bit processors with 32-bit chipsets. So you’re asking the wrong question. You’re right that no 64-bit chipsets use 32-bit addressing. But that doesn’t stop vendors wiring a 64-bit CPU into a 32-bit chipset. (In just the same way that the presence of a 36-bit address bus on most of the CPUs Intel has shipped since the Pentium Pro hasn’t stopped vendors only providing 32-bit addressing in the chipsets.)
Matti - you said “Not really knowing what the 32-bit Windows can or can not do, probably it does not know how to use memory at above 4 GB physical address,”. Not true. You’ve been able to use more than 4GB on 32-bit versions of the server versions of Windows for years. (Although not all editions supported it.) It was possible even back on Windows 2000. (Maybe even NT 4 - I can’t remember exactly when they brought in this support.)
Incidentally, the ‘double buffering’ DMA issue has been with Windows since NT 3.1 - I know this because I used to write device drivers for NT back then… You had to do it for the various RISC systems (Alpha, MIPS, PPC) because most of those systems did something completely different from the x86: the physical addresses seen by the CPU were, in general, not the same as the physical addresses presented on the peripheral buses like PCI. They had a mapping layer in there of exactly the same kind that you need for a 32-bit PCI device to be able to DMA into a 64-bit address space. Drivers are supposed to use the APIs that work with this mapping layer on all hardware. (The exact details of the mapping layer, and whether it was even present, were dealt with by the HAL - the Hardware Abstraction Layer. On typical pre-PAE x86 hardware, the HAL would provide a ‘do-nothing’ mapping layer.)
Device drivers that are written correctly should just work - you don’t need to do anything different to enable a device on a 32-bit bus to DMA into the higher ranges of a 64-bit physical address space. The Windows NT memory APIs have supported the necessary mechanisms since day 1, and a driver written back in, say, 1995 that used the APIs correctly should work today with 4GB on a /PAE-enabled system.
However, lazy device driver writers may have noticed that the relevant APIs for mapping from CPU physical addresses to bus-specific physical addresses are always a NOP on 32-bit x86 systems, as are the APIs for creating DMA mapping ranges. So if they decide not to bother calling the appropriate APIs those drivers will stop working when you enable /PAE. This has never been ‘correct’ - it’s in clear violation of what the documentation tells you to do. However, it happens to work on the vast majority of x86 systems, so you just know there will be some drivers out there that do this. (I would hope that any that have been through the WHQL certification won’t have this problem, but loads of drivers aren’t certified.)
My understanding is that this is the issue that makes /PAE a potential non-starter even where your motherboard happens to support it. The reason switching to a 64-bit OS makes this a non-problem is that the driver writer will have had no option but to write the driver correctly, whereas if you’re using 32-bit drivers, you have to hope that it was written correctly. And there are a lot of crappy drivers out there.
I have read the posts and most if not all is way above me. But is there a consensus about how much RAM the average user should get? So if I a person buys a PC or makes one, and plans on using Vista 32, they only should invest in 3 gigs of memory because anything over that won’t be seen without some workarounds. Is this right?
If anyone is interested, I managed to get the FULL 4GB to get recognized on my machine. Its an A8N32-SLI Deluxe and previously was only getting about 3.3GB.
- Update bios to v1303.
- Enable Memory Hole. (This is Important!!)
I also disabled the serial parallel port and a few other things but I’m pretty sure thats not of much concern.
Cheers.
Thank you for the clarification. So the most common Windows versions (XP and Vista) actually don’t support PAE to access RAM beyond the 4 GB limit, due to concerns about driver compatibility.
That explains why I only see 2 GB under XP when telling my BIOS to remap memory around the PCI “hole”, even though Memtest can see all 4 GB. So PAE is really a nonstarter for most readers of this blog.
xp and vista is no god I personaly stick whit my win 2003 server
i have sql servers whith 16 G of ram
but a guy from microsft told me that 2003 server will not work whith more then 20G of ram i have a server where ai can plug 120G of ram 
This is confusing. Even the “sum up” has a few points wrong.
Enabling “PAE” means that an extra level of page tables gets used. This leads to the following changes:
-
One extra level is added to the page table lookup. This can possibly make memory address slower, but usually the difference is not noticeable since the lookup is cached in TLBs.
-
Data Execution Protection (DEP) is possible. Adding the extra level of page tables frees up a few bits in the page table descriptor. One of these newly freed bits is now used to mark a page as not-executable.
-
Access to up to 16 GB of physical memory is possible.
-
Some kernel pointers are now 64 bits.
So if you enable PAE, and your motherboard actually connects at least 33 address pins from the CPU to the memory, and your BIOS supports memory remapping, you should be able to get a full 4 GB of RAM, right?
Nope. Not if you have XP SP2 or Vista, anyway.
Notice that part about kernel pointers being 64 bits. A whole bunch of drivers don’t handle that correctly. So as of XP SP2 (also in Vista), even in PAE mode, pointers are limited to 32 bits. Even though the OS and the hardware is fully capable of working with more memory, the OS never touches anything above the 4GB boundary. This was a conscious decision. Stability of the system was considered more important than access to the extra physical memory.