2

I have an old pc powered by an Intel Core2 Quad CPU@2.4GHz (both Bios and linux dmidecode don't tell more than that), I can add that the CPU belongs to: Family 6, Model 15, Stepping 7(LGA775 socket).

The motherboard does support ECC but I am wondering if the CPU does it also. I can see that the result of the command dmidecode --t cache gives information about L1,L2,L3 and I can see that on L1 and L2 "Error Correction Type: Single-bit ECC" while L3 "Error Correction Type: Unknown".

Given what I observe from L1 and L2, can I conclude that the CPU does support ECC and I could use it for my ZFS NAS?

Tiutto
  • 179
  • 1
  • 12
  • 2
    The name and clock speed alone nail this down almost surely as a [Q6600](https://ark.intel.com/products/29765). – Iwillnotexist Idonotexist Jun 15 '18 at 19:42
  • 3
    FWIW, ECC RAM is no more necessary on a ZFS system than with any other filesystem (although of course ECC is useful for any system where data integrity is important). This is a myth about ZFS that seems especially virulent. See Matt Ahrens’ (co-creator of ZFS) response to the myth here: https://arstechnica.com/civis/viewtopic.php?p=26303271&sid=4f1061bf30729ec77194da69a68b71d0#p26303271. – Dan Jun 16 '18 at 14:48

1 Answers1

4

No, you can't conclude that ECC DRAM is supported or not based on what the internal caches use to protect data in the cache. The two things are unrelated.

You need to check the CPU and motherboard specs to make sure that both support ECC DRAM. (In your case your Core2 doesn't have an onboard memory controller, so the DRAM is connected to the CPU northbridge. It was the last generation to not integrate the DRAM controllers.)

All recent Intel CPUs use ECC in their L2 / L3 caches, but L1D is actually just parity, not ECC. (To support efficient single-byte and unaligned stores without as much ECC overhead.)

Core2Quad doesn't have an L3 cache.

And BTW, its memory bandwidth is significantly worse than a Nehalem or newer with DDR3, which might be an issue for ZFS copying data around a lot. I think memory bandwidth might be part of the bottleneck in my old Core2Duo running an XFS RAID5 which doesn't saturate individual disk bandwidths for sequential read.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • 1
    You can determine the error correction mechanism used at any memory level using `sudo dmidecode | grep "Error Correction Type"`. This will print 4 lines per socket, corresponding to the 4 levels of memory (L1, L2, L3, and memory). I've run this on three Intel systems: client Haswell, server Broadwell, client Coffee Lake. On Haswell, all of the caches use Single-bit ECC. On BDW and CFL, the L1 uses Parity and the L2 and L3 use Single-bit ECC. On client systems, the DIMMs have no error protection. On the server system, the DIMMs are protected using Multi-bit ECC. – Hadi Brais Mar 24 '19 at 23:57
  • So it seems that Intel does use ECC for the L1 in some microarchtiectures. – Hadi Brais Mar 24 '19 at 23:58
  • @HadiBrais: Interesting, I wonder if that's really accurate. I think that comes from the BIOS, not CPUID directly, so there's room for doubt. My C2Duo also reports single-bit ECC for its L1i/d caches and its L2, while my SKL reports Parity for both its L1 caches, single-bit ECC L2, and multi-bit ECC L3. I guess L1i doesn't need ECC because it can just re-fetch, while L2 might be holding precious dirty data that doesn't exist elsewhere. (dmidecode reports "128 kiB" for both, I guess because that's the total across 4 cores.) – Peter Cordes Mar 25 '19 at 00:53
  • Yeah I think it comes from the BIOS, but I don't know where the BIOS gets this information from. The Pentium Pro also uses ECC for the L1 and L2. The Pentium 4 uses Parity for the L1 and ECC for the L2 (and L3). You can find this information in the old Intel docs. It's not surprising that some Intel processors use ECC for the L1. Other vendors such as AMD and DEC also used ECC for the L1 in some of their processors. – Hadi Brais Mar 25 '19 at 01:27