Five Checks Before a 64GB DDR4 RDIMM Goes Into a Server

A 64GB DDR4 RDIMM can be wrong in five separate ways, and the checks have a fixed order because each answer stops being obtainable at a different moment. The slot question can be settled from a platform manual this afternoon. The qualified-list question closes when the purchase order is signed. The rank question closes when the last channel is filled. The label question closes at the receiving dock. The mixing question never formally closes, which is why it surfaces months later as "the node is slow".

An order line reading Samsung M393A8G40MB2-CTD, 64GB, DDR4 RDIMM is a normal starting point. The number identifies a module design; it does not argue compatibility, and every check below asks about the platform that design has to live in.

1. Confirm the platform is DDR4 at all

A DDR5-only platform makes a DDR4 module wrong however correct its specification is, so generation is settled before capacity or rank.

Both generations use a 288-pin edge connector, so the pin count on a datasheet settles nothing. Keying and supply voltage differ — DDR4 RDIMMs at 1.2 V, DDR5 at 1.1 V — and a DDR4 module does not seat in a DDR5 slot. No BIOS revision changes that, and no supplier document can settle it.

What this protects against is a purchase correct for half a fleet. Refreshes span generations: the older half of an estate takes DDR4, the newer half DDR5, and a request written against "server memory, 64GB" covers both. The delivery seats in one half and waits in a store room for a chassis that will never accept it.

Ask this way. Where one requisition covers machines bought in different years, split the line by platform generation before splitting it by capacity.

2. Confirm the module is on the qualified list for the installed BIOS

Membership in a platform's memory list is decided by the platform vendor's firmware, not by the module's specification, so a technically perfect module can sit outside it.

Vendors publish qualified memory lists per server model, tied to a BIOS generation rather than a product name. A list records which module was validated at which slot count, and entries can be withdrawn as firmware moves, so a copy from two years ago may not apply to the machine in front of you. What a list does and does not certify is worth reading once — see what a compatibility list actually covers.

The cost of skipping it is arithmetic. Four modules per channel across eight channels at 64GB is 2 TB; if the firmware trains only two per channel because the module is absent from the list, the machine comes up with 1 TB, cleanly, with nothing to chase.

Where to draw the line. When the platform owner supplies a part number but not the list entry, ask for the entry or for written approval naming the module, and keep "it should work, the specification matches" on the open-items list, not in the answer column.

3. Confirm rank and organisation, because capacity is the weakest attribute

Rank and chip organisation decide how many modules a channel can carry, which makes them more consequential than the capacity figure on the carton.

A 64GB DDR4 RDIMM is built in more than one shape; the common ones are 2Rx4 and 2Rx8, two ranks of x4 or x8 devices. The difference changes the electrical load a module places on the channel, and population tables count that load, so two modules of equal capacity and speed can have different maximum populations on one board. The mechanism is covered in this explainer on x4 and x8 modules.

Skipped, it produces a capacity plan that is right on paper and wrong in the rack: a design assuming four modules per channel at one rank variant may only hold at two at the other.

Day one: one module in one channel, boots, passes a memory test, signed off. Day fourteen: the second batch arrives in the other rank, same capacity and same speed, and the remaining channels are filled. Day fifteen: a node drops out of the cluster under load and rejoins after a cold boot. Day sixteen: it happens again at the same time. Nothing in the log says "rank", because the log records only that the machine restarted — and the test that passed on day one ran at a population the machine no longer has.

What to write on the order. Where the population table gives a different maximum per channel for different ranks, put the rank in the order line as a required attribute with the same weight as capacity.

4. Confirm registered ECC from the label, not from the description

Registered and unbuffered are different electrical designs, and a board built for one will not run the other, so the question has to be answered by the object rather than by a description of it.

A registered DIMM carries a register that buffers command and address signals before they reach the DRAM devices; an unbuffered DIMM does not. Server platforms are designed around one of the two per slot, which is why desktop memory so often fails to boot in a server even when capacity and pin count appear to match. ECC is separate: a module can be ECC and unbuffered at once.

Skipped, it produces a delivery that fails at first power-on with nowhere to go. No setting converts an unbuffered module into a registered one; the fix is a different module.

The exchange that produces it is short and every line is true. Buyer: "Is the 64GB module compatible with our platform?" Seller: "Yes, 64GB DDR4, same as what you already have." Neither sentence touches the question, because capacity and generation were never in doubt.

Stop condition. Where the description is silent on registered or unbuffered, ask for a photograph of the label on the units that will ship, read it character by character, and do not accept a catalogue image in its place.

5. Decide whether the chassis stays on one specification

Whether a new 64GB module may differ from what is installed is a chassis decision, and the three attributes involved are not equally mixable.

Registered against unbuffered is not a mixing question at all — it is the check above. Rank and organisation can usually be installed side by side and still change what the channel trains to, because the population rule counts the whole channel. Speed bins are the most forgiving: two bins in one channel normally cause the channel to run at the lower one, a performance outcome before it is a stability one. What mixing does to timings is covered in when mixed memory causes downclocking or instability.

Skipped, it produces a machine that works. That is the problem: a mixed population tends to fail quietly, as a channel running below the speed on the label or as a low rate of correctable errors that never trips an alert. The post-incident note rarely mentions memory. It reads closer to "node 7 slower than its peers since the October expansion; no errors in the log; batch jobs finishing late." The memory had run at the lower bin for months; a capacity review that happened to list DIMM speed surfaced it.

The single-specification rule. A chassis has to stay on one specification when any of three conditions holds. First, the planned population already uses the platform's per-channel rank budget, so there is no headroom for a second specification. Second, the workload is bound by memory bandwidth rather than capacity, so a downclock removes performance that was paid for and will be blamed on the application. Third, someone other than the buyer will have to diagnose the machine — a support process, an escalation, a handover — because a mixed population hands that process an easy place to stop.

When none of the three holds, mixing speed bins is a throughput trade you can make deliberately. Mixing types stays off the table in every case.

Five checks, one order: generation, list, rank, label, chassis. The sequence follows the moment each answer becomes unavailable. A module that clears all five is not thereby the right purchase. It is simply not wrong in the five ways the platform, rather than the supplier, gets to decide.