aff_tim wrote:sounds like an investment priority of faster GPU instead of more video card ram would be prudent for system ram optimization.
Or you could get an x64 OS and not have to deal with half of this madness.
Personal computing discussed
Moderators: renee, mac_h8r1, Nemesis
aff_tim wrote:sounds like an investment priority of faster GPU instead of more video card ram would be prudent for system ram optimization.
aff_tim wrote:No, that's not how it works. A given video card has a set of registers that specify how much space it wants in the system memory map for DMA operations. This may or may not correspond to how much RAM is on the card, but it's set in stone by the firmware on the card. At boot, your system's BIOS reads these registers and sets aside that area. When Windows boots, that chunk of the physical memory map is already unavailable. It does not change over time; the only way it would change is if you flashed a different firmware on the card (and perhaps not even then).sounds like the available memory is actually a moving target with the % of on board video ram being utilized at any given instant to be a factor involved in the available system memory issue.
There's still contention on the bus for that system memory, so it's still much slower than dedicated memory. Sideport memory or on-card memory belongs to the GPU alone, and that makes a difference. Dedicated cards also tend to use fast memory optimized for graphics ops.but as I now understand it, on-board video chips using system ram is not the resource hog I perceived the on-board chip to be.
& the new side port video memory is actually of less benefit than would appear at 1st (well marketed) glance.
SuperSpy wrote:Yeah. But on older hardware that may not help, since (as we've discussed multiple times) there are motherboards that will accept a 64bit CPU but don't offer the option of hoisting RAM above the area set aside for DMA devices, and/or don't offer more than 32bits of physical address lines.Or you could get an x64 OS and not have to deal with half of this madness.
aff_tim wrote:2 to the 32nd (32 bit OS) = 4,294,967,296
& 4 gig = 4,096,000,000
WTF
SuperSpy wrote:aff_tim wrote:2 to the 32nd (32 bit OS) = 4,294,967,296
& 4 gig = 4,096,000,000
WTF
4 gig is 2^32, whoever quoted 4,096,000,000 is rounding
bhtooefr wrote:You know, it really isn't good form to bump a post after only 3 hours.
UberGerbil wrote:On a 32bit OS the setting of this switch shouldn't matter: if it's off, some RAM is inaccessible because it is shadowed by the PCI devices; if it is on, the RAM is inaccessible because it is remapped above the 4GB boundary.
If you are getting errors no matter which way this switch is set (even if they differ in detail) it's possible the problem has nothing to do with the switch. Are you sure your memory is all good (run a memtest on it)?
If you're not encountering a hardware problem (like bad memory) then it's possible that you're hitting some problem with the drivers. You said you upgraded your PC -- was the system running properly with the new hardware before you tried re-installing the OS? What 32bit OS are you trying to install (XP?) Have you tried installing the OS without the new hardware (it's possible Windows is detecting the new hardware and selecting drivers for it, but the default drivers that you'd have on any original Windows XP CD would be very old and might have problems with newer hardware)?
Since we're talking about a 32bit OS and possibly other hardware problems that likely has nothing to do with memory remapping or the 4GB limit (and "lost" RAM below that) you might want to open a fresh thread for this.
axeman wrote:Friends don't let friends buy OCZ.
UberGerbil wrote:So SysInternals' new RamMap utility (mentioned in today's shortbread, which prompted me to update this thread) can give folks a graphical verification that their x64 system is indeed "hoisting" the RAM above the 4GB boundary.
Here's an x64 system with 4GB of physical RAM. Note the .75GB mapped above 4GB (aka 0x100000000).
[Link to picture]
This is a fun tool if this kind of stuff interests you, though you have to have a bit of knowledge to make sense of what you're seeing. (Vista/Win7 only, and you need Admin rights.)
Flying Fox wrote:I see that in memtest86+ too. It splits each test into multiple runs with their own percentages, weird at first but kind of funny now that I am used to it. Sometimes I would see like the 256K-16M range gets scanned, and then it is the 32M - 2240M, and then 3000M - 3200M. It jumps around.
Krogoth wrote:Blame the ancient resource allocation methods for the ~4GB memory limit problems. It mostly goes back to when x86 architect was making the jump from 16bit to 32bit. The designers in those days thought 4GB will never be reached in desktop form factors and 1024KBs (yes you had read that right) was the norm for system memory.
At around that same time there was another problem. In areas where 1024KBs wasn't enough. You had to buy an expensive, separate memory module along with a software hack known as EMS or Extended Memory System.
The 4GB problems is just deja vu all over again!
It will all resolved once x86-64 OS and platforms practically phased out aging x86 platform.
morphine wrote:Nice input, but you realize that the last post in this thread was 6 years ago?