Peak transfer rate isn't the only critical spec when it comes to selecting and implementing DRAMs in a system design.
The CMT and SFF systems both came refurbished from SJ Computers via Amazon’s “Renewed” program; I supplemented each PC purchase with an inexpensive 3-year extended warranty. Each system shipped with 8 GBytes of DRAM inside, in the form of two 4 GBye DDR3 1600 (PC3 12800) 240-pin DIMMs. I moved the CMT system’s two DIMMs over to the SFF system to fully populate all four available memory slots, translating into 16 GBytes of total system memory.
I had two 8 GBye DDR3 2400 (PC3 19200) 240-pin DIMMs (complete with removable heat sinks!) lying around from a never-completed DIY PC project, so I decided to press them into service for the CMT system. The Intel Q77 Express chipset only supports up to DDR3 1600 (PC3 12800) SDRAMs, but I assumed the faster DIMMs would appropriately down-throttle. I also purchased two 8 GByte DDR3 1600 (PC3 12800) DIMMs, translating into 32 GBytes of total system memory. Only one problem: the BIOS reports that the aggregate memory subsystem is now running at slower DDR3 1333 (PC3 10600) speeds (apparently a common problem).
As some of you likely already know, peak transfer rate isn’t the only critical spec when it comes to selecting and implementing DRAMs in a system design. I suspect that one of the DDR3 2400 (PC3 19200) DRAM parameters is incompatible with the Q77 Express chipset’s requirements for full DDR3 1600 (PC3 12800) operation, resulting in a further downgrade to DDR3 1333 (PC3 10600) mode. And (unsurprisingly, given that these are corporate-tailored desktops, not enthusiast systems) the Elite 8300 UEFI doesn’t support Intel’s Extreme Memory Protocol (XMP), which if it existed might have enabled me to fine-tune the memory settings.
Frankly, the performance difference between DDR3 1333 (PC3 10600) and DDR3 1600 (PC3 12800) is scant at best anyway, and really only notable at all when the CPU’s integrated graphics are in active use (which won’t be the case in my situation, given that I’m relying on graphics add-in cards for both CMT and SFF systems). That said, if I ever get around to actualizing my DIY PC aspirations, I’ll make sure to get DDR3 1600 (PC3 12800) replacement DIMMs for this system for peak performance.
Speaking of DDR3 1333 (PC3 10600), it’s (in a different module variant) the primary impetus for this particular post. As I’d mentioned in a prior writeup, the USDT system form factor is essentially an AC-powered laptop design, complete with 204-pin SoDIMMs. I’d bought it used off Ebay, and it came with two Kingston HP698656-154-KEB 4 GByte DDR3 1600 (PC3 12800) SoDIMMs, combining to create 8 GBytes of total system memory (and each SoDIMM curiously containing eight 4 Gbit Kingston-branded DRAMs … actual semiconductor manufacturer unknown):
They work great when running Windows 10:
Given that these “Hackintoshes” are intended to approximate Mac Pro high-end desktops, however, I was motivated to max out the USFF system’s memory allocation. I had two 8 GBye DDR3 1333 (PC3 10600) 240-pin SoDIMMs lying around (sound familiar?), Patriot Memory PSD38G13332S products to be precise, which were originally intended for use in my Intel Sandy Bridge CPU-based mid-2011 Mac mini. That particular system is officially only upgradable to 8 GBytes max of system memory, but plenty of anecdotal evidence suggests that unofficial upgrades to 16 GBytes are possible.
They’d always seemed odd; as you’ll see in the following photos, one SoDIMM was fabricated using a blue-color PCB and contained 16 SpecTek (Micron) PE041-125 TP SDRAMS, while the other used a green-color PCB and was made up of 16 Hynix H5TC4G83BFR SDRAMs (both vendors’ chips are 4 Gbit x8 variants):
But the Mac mini had always seemingly run stably with them, at least in normal operation … transitions into and out of sleep mode were unpredictable in outcome, and I wasn’t running anything on the system that was particularly memory-demanding at the time, so I’d set them aside.
This project gave me an opportunity to dust them off. Immediately after installing them, however, I experienced unreliable Windows 10 operation. Sometimes, the operating system would crash and reboot almost immediately; other times it would run for a few minutes before throwing a cryptic “IRQL NOT LESS OR EQUAL” or other error. Regardless, I saw a flickering display, complete with random visual “garbage” in various-sized and -orientation pixel clusters, for the entire duration of however long Windows ran before crashing.
At first, I thought the mistake might be mine … in more closely re-reading the system’s Hardware Reference Guide and Maintenance and Service Guide, I came across indication that while either memory module slot could hold up to 8 GBytes of RAM, total system memory was also restricted to 8 GBytes (similarly, the CMT and SFF systems’ four-slot configurations were supposedly limited to 16 GBytes of system RAM). This just didn’t make logical sense to me, however; I knew that the Q77 Express chipset itself wasn’t capacity-constrained in this way, and unless HP had artificially hobbled the system’s UEFI, 16 GByte system memory configurations should be supported … as a subsequent perusal of the system QuickSpecs confirmed was in fact the case (and as careful readers already realize from my earlier mention of the CMT system’s successful 32GByte configuration). Nice typos (or now-obsolete documentation references, not sure which), HP.
Next step: reach out to Patriot. They suggested I try two things to narrow down the root-cause variables list: fire up a memory test program, and reset the UEFI to defaults. Since Windows wouldn’t run long enough to enable me to initiate its own built-in testing utility, I went with PassMark’s MemTest86, which is cost-free to use in its basic configuration (open-source MemTest86+, built on the original MemTest86 foundation, is another commonly recommended utility). MemTest86 boots and runs directly from a USB memory stick, bypassing any operating system idiosyncrasies. And … it reported no problems whatsoever with either the old 4 GByte or new 8 GByte SoDIMMs, regardless of whether I was using one (in either slot) or two (in either slot order). Trust me, I tried all possible configurations (and each test took about 2 hours to run).
Next step: reset the UEFI to defaults. I thought I’d solved the problem (and sheepishly so, given that this was a used PC, in retrospect I should have done this from the get-go) when the very next system boot completed stably with only a bit of initial display flicker, and the computer even successfully completed a subsequent multi-hour HeavyLoad burn-in run. On a hunch, however, I pulled the PC back out of storage a couple of days later and its misbehavior had returned. Further UEFI setting resets didn’t solve the issue again, either.
More experimentation has resulted in more data to share, albeit without any further root-cause insights. As I’ve already mentioned, the system runs completely stable with 4 GByte SoDIMMs in both slots. It also, as it turns out, runs completely glitch-free (not even any display flicker) with either the blue- or green-color 8 GByte SoDIMM in the lower memory slot (labeled XMM1 on the PCB, and described in the manual as “SODIMM1 socket, Channel B”:
Put either 8 GByte SoDIMM in the upper memory slot (XMM3, “SODIMM3 socket, Channel A”), however, and Windows will sooner-or-later (usually sooner) reliably crash. And of course, as I’ve also already mentioned, populating both slots (in either SoDIMM order) gives Microsoft’s operating system fits, too:
—Brian Dipert is Editor-in-Chief of the Embedded Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company’s online newsletter.