No errors detected for potentially bad RAM; splash page only detects SPD of 1st stick

[byte99]

My system: 2019 27" i9 iMac, Monterey 12.6.1

A few weeks ago I used MemTest86 on 4 x 32 GB used Apple OEM RAM, and it ran without issue. One pair was Hynix, and one pair was Micron. Specs were PC4-21300 DDR4, 2666 MHz, CL 19-19-19-43 . MemTest86 recognized the SPD modules on all four sticks, and finished without errors. I ran the test twice.

However, the vendor was supposed to send me identical sticks. Because of that, and because I got a kernel panic during the brief time the RAM was in use (this might have been a coincidence), I decided to replace these with new 4 x 32 GB GSkill RipJaws (two matching pairs). Specs are the same as the Apple OEM RAM, except it’s CL 18-18-18-43.

I found an issue with one of the four sticks: It must be in either of the DIMM0 slots (nos. 1 or 3) for the machine to boot. When it's in DIMM1 (slots 2 or 4), I hear fans but get a black screen. This is reproducible, and it's the only one of the sticks I see this with. The first time ran MemTest86 with the stick in one of the DIMM0 slots, it froze, but the second time it completed without errors. With the stick in DIMM0, the machine ran without issue.

Another curiosity, seen both before and after replacing the problematic stick, is that the MemTest86 splash page only recognizes the SPD module of the stick in the first occupied slot. For all remaining modules, it says "SPD not detected". This is independent of which slot is the first one occupied, and which stick is in the first slot. If slots 1–4 are occupied, it only recognizes the SPD info. for the stick in slot 1. If slots 2 & 4 are occupied, it only recognizes the SPD info. for the stick in slot 2, etc.

However, when I look at the HTML report, it says the SPD modules are recognized for all slots (see screenshot below).

Also, a few questions:
1) Is there any significance to the RAM speed listed in the HTML report under "Memory". E.g., with the "bad" stick, I got 18.5 GB/s. After replacing the pair containing it with an identical pair, it dropped down to 17.7 GB/s.

2) When companies sell matched pairs of RAM, is it actually matched? I.e., do they do an extra QC step to select out the sticks that have the closest measurements and pair them together?

3) If you have two pairs of matching RAM, should the members of the same pair go into the same DIMM, or into the same channel?

[David (PassMark)]

According to Apple the 2019 27" i9 iMac only comes with 8GB of RAM (2 x 4GB) and supports 64GB of RAM max. So very likely apple never tested 32GB sticks nor tested running with a total of 128GB.
So seeing some strange behaviour isn't too surprising.

Specs are the same as the Apple OEM RAM, except it’s CL 18-18-18-43.

There are a lot more specs for RAM that go beyond those 4 numbers. Voltages, clocks speeds and lots of timing values. The full specs are stored in the SPD data. There are dozens of different numbers. If this was a PC, I would say it would be fine, as generally PC BIOS is pretty flexible. However with Apple, no one knows. It would be trivial to have a situation where they only work with a a few different types of sticks to lock you in to buying just their RAM.

In answer to your questions.
1) RAM speed reflects the timing values, clock speed and CPU specs (cache, etc..). It is also impacted by single channel and dual channel availability. So yes, it is was consistently different, then likely there was some spec difference between the sticks or a different test setup.

2) I don't think there is any general answer. Different companies do different things. For me matched means 100% identical specs (even for the normally hidden sub-timings in the SPD data).

3) I think you are confusing the terminology. DIMM isn't the slot. DIMM is the memory stick (Dual Inline Memory Module). All motherboard have manuals the cover which slots to use first. But of course Apple, being Apple, probably don't. But matching pairs should be used in the same channel (generally there is channel A and channel B, and each channel is made up of two slots. Hopefully Apple labelled these somewhere).

[byte99]

According to Apple the 2019 27" i9 iMac only comes with 8GB of RAM (2 x 4GB) and supports 64GB of RAM max. So very likely apple never tested 32GB sticks nor tested running with a total of 128GB.
So seeing some strange behaviour isn't too surprising.

MacSales.com, which is one of the best-known Apple aftermarket vendors, did extensive testing and found that the 2019 iMac can support 128 GB without issue, and has been selling these for a while. Though that's not the same as Apple doing the testing, and it's possible one could still see odd interactions with a sensitive test like MemTest86.

There are a lot more specs for RAM that go beyond those 4 numbers. Voltages, clocks speeds and lots of timing values. The full specs are stored in the SPD data. There are dozens of different numbers. If this was a PC, I would say it would be fine, as generally PC BIOS is pretty flexible. However with Apple, no one knows.

I don't see, in the HTML report, the complete set of SPD info. that MemTest86 reports on-screen. Would it be possible to get it from the log file, or is the only way to record it by writing it down with pen and paper?

It would be trivial to have a situation where they only work with a a few different types of sticks to lock you in to buying just their RAM.

I don't believe that's what's going on here. Apple openly supports aftermarket RAM for this machine ( https://support.apple.com/en-us/HT201191 ), and many Mac user forums have reported success with a wide variety of aftermarket RAM. I myself ran this machine for a while with other aftermarket RAM. What is true of this machine is that it is sensitive to RAM, so it's more common to find reports of non-working RAM with this machine than is the case for most desktops.

In answer to your questions.
1) RAM speed reflects the timing values, clock speed and CPU specs (cache, etc..). It is also impacted by single channel and dual channel availability. So yes, it is was consistently different, then likely there was some spec difference between the sticks or a different test setup.

What I'm asking is whether different values for this spec in the HTML report would be expected to have performance implications. I ask because the sets that gave 17.4 GB/s and 18.5 GB/s, respectively, in the HTML report, nevertheless had nearly identical PassMark memory benchmark scores.

2) I don't think there is any general answer. Different companies do different things. For me matched means 100% identical specs (even for the normally hidden sub-timings in the SPD data).

Ah, I was thinking of non-discrete values, which would never match even with otherwise identical parts (e.g., consider the interunit variation in CPU production that causes two otherwise identical CPU's to have different max overclocking frequencies). Those are the kinds of things I assumed they would check for when they identified matching pairs, to ensure the sticks are closely matched for such non-discrete values.

To give an analogy: Even high-quality skis will have interunit variation in their stiffness. Since they are sold in pairs, the manufacturer assembles pairs by measuring the flexes and identifying pairs with closely matching values And they have certain criteria for how closely they need to match to be considered a matching pair. They will never exactly match, of course, since the flexes are measured rather than discrete values. So I assumed there were values they measured to track interunit variation in RAM sticks, and put together pairs where the difference between their values was below a certain cutoff.

But I gather from what you wrote that this is not what "matching" means to you for RAM--you just mean that values are discrete are the same, like clock timings. E.g., a clock value can be once every 19 cycles, or once every 20 cycles but it can't be once every 19.00234 cycles.

3) I think you are confusing the terminology. DIMM isn't the slot. DIMM is the memory stick (Dual Inline Memory Module). All motherboard have manuals the cover which slots to use first. But of course Apple, being Apple, probably don't. But matching pairs should be used in the same channel (generally there is channel A and channel B, and each channel is made up of two slots. Hopefully Apple labelled these somewhere).

Here's how Apple labels their slots. For channel A, there's a DIMM0 slot and a DIMM1 slot. And the same for channel B. Given what you wrote, one could interpret that to mean that, in channel A, there's a slot for memory module #0, and a slot for memory module #1, etc. So what I found, with my "problematic" stick, was that the computer would only boot when it was in BANK 0 or BANK 2, i.e., in the first slot for each channel.

[David (PassMark)]

... and found that the 2019 iMac can support 128 GB without issue

And yet here we are, with an issue.

There are others as well
https://forums.macrumors.com/threads.../post-27841708
and
https://forums.macrumors.com/threads...b-ram.2263538/

Clearly it does work for some people however. A few people seem to have had bad sticks as well. Might be slightly marginal. e.g. unexpected high current draw causes slight voltage drop which some modules don't like. Just speculation. We don't really know.

You could ask Apple why they don't support it when the CPU does and there is enough slots. Maybe there is a good technical reason. It is their product after all.

Different RAM performance would translate to different performance in real applications. How much of a difference the 1GB/sec extra would make depends on the application, CPU cache and other factors. I would expect the difference to be unnoticeable unless very careful measurements are done.

[byte99]

And yet here we are, with an issue.

There are others as well
https://forums.macrumors.com/threads.../post-27841708
and
https://forums.macrumors.com/threads...b-ram.2263538/

Clearly it does work for some people however. A few people seem to have had bad sticks as well. Might be slightly marginal. e.g. unexpected high current draw causes slight voltage drop which some modules don't like. Just speculation. We don't really know.

You could ask Apple why they don't support it when the CPU does and there is enough slots. Maybe there is a good technical reason. It is their product after all.

Actually, those links are consistent with what I've been saying. For instance, just a couple of posts down in the first thread you linked, we have this:


I.e., the single failure you linked appears not to be due to an issue with 128 GB per se, but rather is consistent with the general sensitivity of iMacs to aftermarket RAM, which makes incompatabilities more likely for all capacities.

Further, the second link is a failure of 128 GB RAM in a 2020 iMac, in which 128 GB is officially supported by Apple. So this is not a case of using a RAM capacity not supported by Apple but, again, a case of aftermarket RAM not working in an iMac because of its general sensitivity.

So you might be right that 128 GB is problematic in the 2019 iMac. But because 128 GB has been show to work generally there, and RAM incompatabilities are not uncommon at all capacities in iMacs, we would need data showing that 128 GB RAM fails at a significantly higher rate than lower-capacity RAM to know if it truly is a problem.

Those who've looked into this have suggested the reason Apple's max RAM option for the 2019 iMac was only 64 GB, rather than the 128 GB offered on the 2020 iMac, is likely because 32 GB DDR4 laptop (260 pin) RAM modules simply weren't available when the 2019 iMac was in pre-production testing. And since Apple itself didn't test the 2019 with 128 GB, they don't officialy support it.

Different RAM performance would translate to different performance in real applications. How much of a difference the 1GB/sec extra would make depends on the application, CPU cache and other factors. I would expect the difference to be unnoticeable unless very careful measurements are done.

So you're saying the 6% difference between 18.5 and 17.4 GB/s would be unlikely to translate into an ~6% difference in the PassMark memory test?

Then again, maybe I shouldn't concern myself with MemTest86's performance reporting when this particular RAM is installed, since I ran the test again and got 5 TB/s (!) for my L1 cache:



Also, wanted to ask this again:

I don't see, in the HTML report, the complete set of SPD info. that MemTest86 reports on-screen. Would it be possible to get it from the log file, or is the only way to record it by writing it down with pen and paper?

[David (PassMark)]

since I ran the test again and got 5 TB/s (!) for my L1 cache:

Can you send us the debug log for this
https://www.memtest86.com/tech_debug-logs.html

So you're saying the 6% difference between 18.5 and 17.4 GB/s would be unlikely to translate into an ~6% difference in the PassMark memory test?

I am saying most real life apps aren't totally bottlenecked on the RAM speed. Single threaded CPU performance, internet speeds, disk speeds, GPU speed are more common bottlenecks. So 6% difference in RAM benchmark might be unnoticeable in many apps.

[byte99]

Can you send us the debug log for this
https://www.memtest86.com/tech_debug-logs.html

Done! Emailed the log and HTML report to info@passmark.com. Please let me kmow if you find anything interesting!

[David (PassMark)]

since I ran the test again and got 5 TB/s (!) for my L1 cache

Got the logs. It might be 32bit overflow error. This is very old code from maybe 20 years ago. We suspect a 32bit integer is overflowing on very fast machines. We'll rewrite this code in 64bit and see how it goes.

[byte99]

Got the logs. It might be 32bit overflow error. This is very old code from maybe 20 years ago. We suspect a 32bit integer is overflowing on very fast machines. We'll rewrite this code in 64bit and see how it goes.

I'll be happy to rerun it after the code is updated, assuming I still have that RAM. But note that I ran the test a couple of times on that RAM, and only saw the error once, so it may be hard to replicate. If you want I can send you the debug code for the other run, on that same RAM, in which I didn't get this error.

Sounds like a major project to rewrite your code in 64 bit--curious about how long it will take. A month or so?

[David (PassMark)]

We rewrote the important code (the actual memory test) to use 64bit addresses years ago.
This small amount of benchmark code wasn't touched as there was no reason to move it to 64bit.