4

I installed 16GB of RAM on a motherboard that shouldn't take it. Should I buy a better motherboard or change anything at all? It seems to be working fine.

Memory: Crucial Ballistix Sport "(8GBx2) DDR3 PC3-12800"
Board: Asrock N68C-S UCC "Max. capacity of system memory: 8GB"

  1. Does gnome-control-center.real info lie?

    Memory: 15,7GB
    
  2. Does dmidecode -t16 say my board can take 2x 8GB or 8GB total?

     Maximum Capacity: 8 GB
     Number Of Devices: 2
    
  3. Does free -h lie saying 11 out of 15GB is used?

                 total       used       free     shared    buffers     cached
    Mem:           15G        11G       4,2G       7,8G       140M       9,3G
    
  4. Shouldn't this output of dmidecode -t 17 say 1600 MHz speed?

    Handle 0x0010, DMI type 17, 27 bytes
            Size: 8192 MB
            Speed: 400 MHz
    Handle 0x0012, DMI type 17, 27 bytes
            Size: 8192 MB
            Speed: 400 MHz
    
  • 1
    I would venture a guess that the description text on that site is incorrect or misleading. If the board isn't supporting the extra memory, it certainly shouldn't show up in free. – Tom Hunt Nov 18 '15 at 0:44
  • But dmidecode reads the same restriction from the motherboard and not from the website... does this mean the manufacturer made the same mistake twice? – cprn Nov 18 '15 at 1:25
6

The short story:

If your mobo posts, and your system boots, and free/top show your ram as 16 gB, then it works. Even mobo makers can under-report capacity of system boards, so the real test is if ram is installed correctly, matched correctly, runs, ie, boots, and runs with stability, ie, doesn't crash, then it works. You can also test by trying to use all your memory for something or other, and seeing if the system remains stable. Because you got very good ram, crucial, it's quite possible that lower grade ram might not have worked at 16gB. That can be why they don't say it supports 16gB but opt for the more conservative 8gB.

Your tools, like free, top, that report real memory of system, are not lying, that is the usable memory the kernel has access to. Tools that read dmi data do lie, because dmi lies randomly based on the companies who filled that data out.

Does gnome-control-center.real info lie?

Memory: 15,7GB

No, it is telling you the truth.

Does dmidecode -t16 say my board can take 2x 8GB or 8GB total?

 Maximum Capacity: 8 GB
 Number Of Devices: 2

It says 8gB total. You can see it clearly when looking at a sample type 16 (mine, in this case). The capacity refers to the capacity of the array. This is a single memory array. This array has an alleged (though false in your case) capacity of 8gB (correct in my case), and in my case, it has 4 devices. In your case it has 2 devices. Note that you cannot deduce the overall capacity by the max stick you can use in one slot, unfortunately. That is, you could have 4 slots, with an 8gB capacity, but a 4gB per slot max, which would mean you could use either 4x2gG sticks, or 2x4gB, but not 4x4gB.

Handle 0x0012, DMI type 16, 15 bytes
Physical Memory Array
        Location: System Board Or Motherboard
        Use: System Memory
        Error Correction Type: None
        Maximum Capacity: 8 GB
        Error Information Handle: Not Provided
        Number Of Devices: 4

Does free -h lie saying 11 out of 15GB is used?

No, free is telling you the truth. top will tell you the same truth (though the question of what the kernel considers free or not free is highly arcane, and varies with the implementations of these tools, but that veers far off topic of this question). This is the kernel reporting to userland what ram it has access to, and what is used.

Shouldn't this output of dmidecode -t 17 say 1600 MHz speed?

It depends on your system. And on how dmidecode is interpreting the data. I'm rusty on this part of the question.

The long story:

Since I had to deal pretty heavily with ram reporting issues, I had to discover the variance in quality of the dmidecode ram data reports. Note that this is NOT the fault of dmidecode, since its job is to report the dmi data, not to interpret it or correct it.

First: dmidecode essentially reports two sets of data: 1: some data that someone filled out, that is, a low paid drone at the motherboard vendor has a form to fill out, and either doesn't bother doing it right, or does it right for one model, and then just copies over that data to another. 2: real data, like whether a ram slot has ram in it, it's size, type, speed, etc.

So in the case of system board ram capacity, dmidecode is NOT telling you the capacities based on any actual technical specifications available to dmidecode when it runs. What it's doing is repeating the data that the aforementioned underpaid person was told to fill out to check some box prior to shipping the hardware.

Some mobo vendors supply this data perfectly, and you can fully trust their statements. Others offer completely nonsensical statements, which leads dmidecode to correctly report 4x2gB ram installed, but a capacity of 4gB.

For example, dmidecode will I believe almost always, if not always, tell you the exactly correct information about your installed ram, quite accurately, but the dmi data will then often contain wrong data about capacity.

When I had to deal with this issue, I always used the per stick reporting as authoritative, and I always let it override dmidecode data about actual capacity, because the latter is not real data.

# can be true, false, totally off, or pure fiction re capacity
# the rest of the data is usually pretty good though
dmidecode -t 5 

# extremely accurate and reliable, per stick information. Trust it.
dmidecode -t 6 

# same as 5, might be right re maximum capacity, might not be
dmidecode -t 16 

# extremely accurate, can trust it, but can't learn max 
dmidecode -t 17 capacity.

Basically it depends on the motherboard vendor, did they complete the data fields that 5 and 16 use correctly? I'll give you an example that clearly shows the fields they didn't feel like filling out.

Handle 0x001A, DMI type 17, 27 bytes
Memory Device
        Array Handle: 0x0012
        Error Information Handle: Not Provided
        Total Width: 64 bits
        Data Width: 72 bits
        Size: 2048 MB
        Form Factor: DIMM
        Set: None
        Locator: DIMM3
        Bank Locator: BANK3
        Type: DDR2
        Type Detail: Synchronous
        Speed: 400 MHz
        Manufacturer: Manufacturer3
        Serial Number: SerNum3
        Asset Tag: AssetTagNum3
        Part Number: PartNum3

You see this all through dmi data, and inside of /sys, data that was not filled out, half filled out by the vendors, or filled out wrong. The items after speed were not filled out right. My personal favorite is this, which is far more common internally than you'd think:

[Field Name]: To be filled by O.E.M.

You'd think that in this day and age there would be something that actually tells systems exactly what it is, but that's sadly not the case.

I could show you hundreds of instances of machine dmidecode data that demonstrate this issue, but really you only have to see one or two. I tend to think that the better mobo makers tend to fill out their dmi data sets better, and the lower end ones tend to not do that, but there's no hard and fast rule about it.

As a basic rule, this is the information you can trust from dmidecode and ram:

DMI type 5
# Almost nothing in there except some generic information
Error Detecting Method: 64-bit ECC
Error Correcting Capabilities::
                None
Associated Memory Slots: 4
Enabled Error Correcting Capabilities:
                None


DMI type 6
Socket Designation: DIMM3
Current Speed: 167 ns
Installed Size: 2048 MB (Double-bank Connection)
Enabled Size: 2048 MB (Double-bank Connection)
Error Status: OK # probably

DMI type 16
Number Of Devices: 4

DMI type 17
Data Width: 72 bits
Size: 2048 MB
Locator: DIMM0
Bank Locator: BANK0
Type: DDR2
Type Detail: Synchronous # usually anyway

From Gilles, in comments:

Another reason why dmidecode might underreport the maximum capacity is when X GB sticks didn't exist yet when the board was manufactured (or the board manufacturer didn't bother to test with them for some reason), so the board documents Y GB as the maximum with Y < X, but when X GB sticks appear they turn out to work.

The key is to realize that the max capacity that dmidecode reports the memory array having is not calculated, it's just some data someone entered when they create the dmi table for the mobo. I generally trust the vendor mobo documentation over the dmi data, but as this poster discovered, even that's not reliable.

| improve this answer | |
  • Wow! As comprehensive as it gets! :) Thank you very much! – cprn Nov 18 '15 at 3:04
  • Another reason why dmidecode might underreport the maximum capacity is when X GB sticks didn't exist yet when the board was manufactured (or the board manufacturer didn't bother to test with them for some reason), so the board documents Y GB as the maximum with Y < X, but when X GB sticks appear they turn out to work. – Gilles 'SO- stop being evil' Nov 18 '15 at 22:18
  • Yes, there are a lot of reasons, what you say might be another. Updated to add a bit more about that. – Lizardx Nov 18 '15 at 22:41
  • 1
    DDR2 ram transfers 4 times per clock, so it is really running at 400 MHz, but effectively that is "1600" when you count the x4 multiplier. – psusi Nov 19 '15 at 0:30
  • Thanks for the reminder psusi, that clarifies his last question. – Lizardx Nov 19 '15 at 1:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.