Motherboard Memory Limitations

digitalunity asks: "When most motherboards with room for 3 DIMMs state their maximum memory as 768MB, it would seem that this is based upon the assumption that a 256MB DIMM is the largest available. I noticed that IBM has said that 1GB DIMMs will be available soon. Are the stated memory limitations of motherboards inherent to their design or can you really put more memory than they state?"

Comments

Re:What about the SS7 mobos?

[Anonymous Coward]

Right - VIA chipset with 2 MB L2 cache makes it to 512 MB -- almost.

I have a FIC 503+, which has same chipset, but only 1 MB. Its L2 cache handles up to 256 MB -- almost.

"Almost" caveat is due to use of a few tag RAM bit patterns to represent ususable states.

How would they test 'em ??

[Hall]

How would they test the boards to see if they support 1gb DIMMS ? It's easy to say "Yeah, it should work..."

Re:How would they test 'em ??

[substrate]

Usually if you look at the datasheets the companies such as Supermicro put out you'll see an asterix next to any specifications that relied on options which were in the pipeline but didn't exist at manufacture. The asterix states that the board hasn't been tested with the parts in question.

The engineers who design the motherboard can make pretty educated guesses as to what the electrical performance required at the socket will be for these parts. As long as the mechanical interface doesn't change and the electrical interface either sticks with preliminary information or doesn't change much from existing implementations they're in good shape. They protect themselves with the disclaimer: If the external manufactures don't make say a 1 gigabyte SDRAM with the projected specifications you can't sue then as it was just a best effort attempt.

BIOS limitations as well....

[Zurion]

The BIOS limitations on the mobo will have a large effect on what will work with the board. If there is an available patch for the BIOS so that it can correctly detect these larger DIMMS then there should be no problem. That is assuming that the 1 GB DIMM has the proper physical connections.

I personally haven't seen any Intel-based mobo's that will accept anything over 256MB modules.

Memory and cache limits

[Colitis]

The BX chipset has a limit of 1gb of RAM. GX (ie Xeon processors) is bigger than this, but not sure what the limit is - possibly 2mb. No idea with the LX.

Effective limits can be less than this, though - the Klamath core (most PIIs = 333, some 300's, a very few 266's, plus Celeron 266s and 300s) and Mendocino (Celeron A's) cores can cache 4gb. Not sure about the Xeons but they'll be at least 4gb.

Re:Memory and cache limits

[Colitis]

Dammit - put a couple of angle brackets in that and it treated the text in between as HTML code and cut it out :-(

I meant that PII CPUs at 333 or greater are Deschutes core (cache 4gb), most at 300 or below are Klamath (cache 512mb) but there are a few PII 300s and a very few PII 266s that use the Deschutes core. Celeron 266's and 300's also use the Deschutes core, Celeron A's use the Mendocino core which also caches 4gb.

Re:SEVERAL FACTORS TO CONSIDER

[cjs]

On a 32 bit plataform, it is doubtfull if it makes any sense to have more than 4 GB, as this forces the os and apps that mght want to use it to do some segment translation

This is not necessarially true. I'm not familiar with just how the P6 MMU works with this, but the programs themselves, so long as they're happy with a 32-bit address space, work entirely in a VM map and have no clue about the amount of physical RAM in the machine. The OS has to be able to provide 36-bit physical addresses to the MMU to map these physical pages into an address space, but given that the OS usually is happy in a fairly small chunk of address space (usually 256 MB to 1 GB at the `top' of every process's address space), it doesn't need to deal with segmentation for itself.

The implication of this, of course, is that more than 4 GB of memory will be useful only if you have several processes that want a lot of physical memory, as an individual process is never going to use more than 4 GB without segmentation support.

cjs

Re:SEVERAL FACTORS TO CONSIDER

[cjs]

BTW, i wonder if the problem of relocating real 32 bit adresser under a > 32 bit plataform (as requiered to talk with 32 bit pci devices taht do bus mastering) would be much of a problem. I wonder if the people that has worked on NetBSD/Alpha has got a look into it.Perhaps the "bounce buffers" from the ISA days might come back....

In fact, this was originally dealt with for the NetBSD/alpha port, and extended to all other ports in a machine-independent way. Drivers no longer have to worry about what memory is DMA-able, or whether a card can access the entire address space; underlying machine-dependent software takes care of that. (The underlying software may use special DMA registers, bounce buffers, or whatever it needs.) Therefore the same driver works for a card whether it's in an Alpha, an i386, an Amiga, or whatever. (NetBSD is, as far as I know, the only OS that does this.)

Have wou NETBSDers discusser if it would be worthwile to implement a PSE36 port ...

I don't know what this piece of hardware is, unfortunately.

cjs

Max Cacheable and registered memory

[abcess]

Check out www.firingsquad.com, they've got a really good guide that goes into alot of this stuff. A previous post covered the chipset stuff well, the BIOS was also mentioned, but what hasn't been mentioned is the Max _Cacheable_ memory, if you install more RAM than the mobo can cache, you'll notice a performance hit. For example, the VIA MVP3 chipset with 512k L2 cache will only cache 128 megs, bump it up to 1MB L2, and you can cache (go figger) 256 megs. However, the mobo i've got supports up to 768 megs, but over 256 does me no good. I don't know what the specs like this are like for the BX, GX and the like.

Also, alot of motherboards require you to use registered memory for modules that are 256MB or bigger. This may depend on the chipset and BIOS as well though.

What about the SS7 mobos?

[Chad Page]

I know the K6-3 can cache the full 4GB, but I'm interested in hearing about how much the AMD-related chipsets can cache... anything out there than can do >=256MB ECC for instance? :) (I've heard the FIC PA-2013 2MB can...)

Cacheing limitations?

[MustardMan]

Correct me if I am wrong, but from the gist of the other posts it seems to me like part of the memory limitation has something to do with the processor. Does that mean by having an SMP setup with dual processors you would effectively double the amount of RAM your system could use?


Tell a man that there are 400 Billion stars and he'll believe you

SEVERAL FACTORS TO CONSIDER

[rdk]

There are several factors that determine the
maximum ammount or RAM that can be plugged
into a given MB

1. PCIset

Modern desktop chipsets are not built for
memory hungry applications. The phisical limit
is

-82440 LX: 512 MB SDRAM or 1 GB EDO
-82440 BX: 1 GB SDRAM
-82440 GX: 2 GB SDRAM (Using registered modules)

And for the server Chipsets

-82450 GX: 4 GB FPM
-82450 NX: 8 GB EDO

On a 32 bit plataform, it is doubtfull if it
makes any sense to have more than 4 GB, as this
forces the os and apps that mght want to use
it to do some segment translation (remember that
the P6 architecure implememnts a 36 bit adressing
mode)

I don't know if any modern OS supports them, however.

Regards
Roberto

Re:SEVERAL FACTORS TO CONSIDER

[rdk]

Agreed ...

Which would be great for server apps but not
very charming for doing large simulations or
database work. BTW, i wonder if the problem
of relocating real 32 bit adresser under a
> 32 bit plataform (as requiered to talk
with 32 bit pci devices taht do bus mastering)
would be much of a problem. I wonder if
the people that has worked on NetBSD/Alpha
has got a look into it. Perhaps the "bounce buffers" from the ISA days might come back
(as ther are still very few 64 bit PCI cards)

Regards ...
ROBERTO

BTW, Have wou NETBSDers discusser if it would be
worthwile to implement a PSE36 port ...
I remember Alan Cox sayng it was a no-no