Alpha Memory Configuration: DIMM Pairing, ECC and Interleaving
Most "dead" Alpha boards that land on a collector's bench are not dead at all: they are fed the wrong DIMMs, in the wrong slots, in the wrong quantities. This guide walks through how Alpha-era systems expected their memory to be arranged, why, and how to use the SRM console to find the stick that is actually failing.
Why Alpha memory is fussier than a PC
A late-1990s desktop PC would boot with almost any single DIMM you pushed into slot zero. Alpha systems were designed to a different brief. The 21164 and 21264 were built to move a lot of data, and the chipsets around them, from Digital's own server logic to the Tsunami/Typhoon family (21272) used in the DS10, DS20, ES40 and the UP2000 family, got their bandwidth by making memory wide rather than just fast. A single memory "array" on many of these machines is 128 or 256 bits of data plus check bits, and that width is assembled from several physical modules working in lockstep.
The consequence is simple: on most Alpha servers the unit of installation is not a DIMM but a set of DIMMs, typically two or four identical modules. Install three and the firmware will usually ignore the odd one out, or refuse to size the array entirely. Mix capacities within a set and you can get anything from a silently disabled bank to intermittent machine checks under load.
API's own boards sat at both ends of this spectrum. The UP1000, built around AMD's Irongate northbridge, behaved much more like a PC and took ordinary 168-pin PC100-class SDRAM one module at a time. The dual-processor UP2000 used Tsunami-class logic and followed the server rules: registered ECC modules, installed in matched groups.
Registered, ECC and what the chipset actually checks
Two separate properties get lumped together in auction listings, and it pays to keep them apart.
- ECC means the module carries extra DRAM chips for check bits: 72 bits wide per 64 bits of data on a standard 168-pin DIMM. The memory controller computes a code on every write and verifies it on every read, correcting single-bit errors and detecting double-bit errors.
- Registered (buffered) means the module has register chips that re-drive the address and control lines. That reduces electrical load on the controller and is what allows a server board to hang many DIMMs off one channel.
Server-class Alpha chipsets generally required both. Unbuffered modules on a registered-only board typically fail the memory sizing step before the console banner appears; non-ECC modules may be sized but will throw correctable or uncorrectable errors immediately because the check bits read as garbage. Some platforms also expected particular form factors: several DEC and Compaq AlphaServers used 200-pin proprietary-ish DIMMs rather than JEDEC 168-pin parts, so read the label on the existing modules before shopping.
Bank pairing rules in practice
The exact rules differ per machine, and the original service guides are the authority, but the same handful of principles show up almost everywhere:
- Fill the lowest-numbered array or bank first. The firmware usually sizes memory starting from array 0 and may stop at the first empty one.
- Within an array, every module must be the same capacity, speed grade and organisation. Same part number is ideal.
- Install the largest arrays in the lowest positions. Many controllers map address space in descending size order and are happiest when the physical layout agrees.
- Keep sets together. If you pull memory to test, label which modules came from which set and return them as a group.
- After any change, power-cycle fully rather than issuing a console reset, so the controller re-runs its sizing and training.
Typical configurations
The table below summarises what we have seen on common boards and systems. Treat it as a starting point: module counts and maximum capacities varied with board revision and firmware, and some figures are approximate.
| System | Module type (typical) | Install unit | Practical maximum (approx.) |
|---|---|---|---|
| UP1000 (Irongate) | 168-pin PC100 SDRAM, ECC optional | Single DIMM | On the order of 1.5-2 GB |
| UP2000 / UP2000+ (Tsunami-class) | 168-pin registered ECC SDRAM | Matched sets | Roughly 2-4 GB depending on revision |
| DS10 / DS10L | Registered ECC SDRAM | Single or paired, per guide | Around 2 GB |
| DS20 / DS20E | 200-pin registered ECC | Sets of four | Around 4 GB |
| ES40 | 200-pin registered ECC on memory riser boards | Sets of four across risers | Up to roughly 16-32 GB |
Interleaving: where the bandwidth comes from
Interleaving means spreading consecutive cache blocks across independent arrays or banks so that while one is busy precharging or returning data, the next access can already be under way. On a 21264 with its 64-byte cache lines and aggressive out-of-order memory system, keeping several misses in flight is exactly what the chip wants, and the chipset can only satisfy that if there is more than one place for the addresses to land.
In practice this has two effects that surprise people. First, two small matched arrays often outperform one large array of the same total capacity, sometimes noticeably in memory-bound code. Second, an unbalanced configuration, say one array of four 512 MB modules and one array of four 64 MB modules, may interleave only across the portion of address space where both arrays overlap, leaving the rest effectively single-array. If you care about benchmark numbers (see our piece on SPEC results), balanced arrays matter more than raw capacity.
Some firmware exposes interleave behaviour through console variables, others decide it automatically from the population. Where a variable exists, the default is almost always the right answer; changing it is a way to isolate a suspected faulty array, not a tuning knob.
Diagnosing memory errors from SRM
The SRM console is the first tool to reach for, before any operating system is involved. Command sets varied between platforms and firmware versions, so treat the following as representative rather than universal:
>>> show memory
>>> show config
>>> show fru
>>> memtest
>>> show error
show memory reports how the firmware sized each array. If you installed 1 GB and it reports 768 MB, one set has been rejected, and the output usually tells you which. show config and show fru give the broader inventory. Where available, memtest exercises memory from the console, and platforms with error logging will retain correctable and uncorrectable events that can be inspected afterward.
A practical isolation procedure
- Record the current
show memoryoutput and photograph the slot layout. - Reduce to the smallest legal configuration: one known set in array 0.
- Run the console memory test, then boot an operating system and run a memory-heavy workload for at least an hour.
- Add sets back one at a time, re-running the test after each, until errors return.
- Within the failing set, swap modules one at a time with a known-good spare of the same organisation to find the individual bad DIMM.
Correctable single-bit errors that always point to the same module are usually a failing DRAM chip. Errors that move around, or appear only when the machine is warm, point more often to dirty contacts, a marginal power supply or a riser board connector. Clean the gold fingers with isopropyl alcohol and reseat before condemning anything; our UP1000 restoration notes cover the same approach for board-level work.
Sourcing and testing modules in 2026
Registered ECC SDRAM from this era is still reasonably easy to find because the same modules went into many x86 servers. The catch is that "PC133 registered ECC" pulled from a random server may use DRAM densities or organisations that older Alpha controllers never qualified. Prefer modules that list the Alpha system by name, or that match the part numbers on a working module. If you run a mixed fleet, buy one spare set more than you need, and keep it in anti-static bags away from the machine room heat.
If you do not have real hardware, emulation sidesteps all of this, and an emulated ES40 is a comfortable way to learn the console before touching a physical box.
Further reading on this archive
- UP2000 board page: the original product description of API's dual-21264 board.
- SRM, AlphaBIOS and MILO: a primer on the consoles used to diagnose and boot Alpha machines.
- Running Linux on Alpha hardware today: what to install once the memory checks out.
- Archived support pages: API's original support material for its boards.