Curious if you have links to the 16GB stick versions. I picked up a W680 and 12500T for my build but have been looking for ECC that is supported for the full fat 80-bit ECC
LGA 1700 Alder Lake "Servers"
- Thread starter tjk
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
If you are running Linux then modern distribution kernel initrd's apply microcode updates. Not sure about the other stuff. I am probably going to ask for more information.
From looking at part numbers on Micron's site, it appears they are offering non-ECC (i.e. on-die ECC only) DDR5 at 64 bits wide, and ECC DD5 in both 72 bit and 80 bit wide variants. I have only seen 72 bits wide for the unbuffered ECC variant, but both 72 and 80 for the registered variant. This is a characteristic of the memory chip part apparently.
The documentation on DDR5 is not really good and contradictory in some places.
The documentation on DDR5 is not really good and contradictory in some places.
So judging by this video, could we conclude that DDR5 UDIMM ECC RAM with 5 chips on each channel should have the 32+8bit layout? Because I see a lot of RAM advertised as DDR5 ECC but pictured with 5 chips on one half and 4 on the other, which would likely be a 72-bit config which wouldn't give you that full-fat ECC experience. Wonder if we could use this to help visually find more RAM options that would work.
There's also these Kingston sticks with 10 chips but 72-bit
(report as single bit ECC to OS)I'm optimistic that this is still functionally the same as DDR3/4 unbuffered ECC, i.e. 1 bit correction 2 bit reporting, but would love some clarity
I guess the question might be more whether the single bit ECC is in addition to the standard on-chip ECC of DDR5 or not, perhaps it is for 10 chip modules but not for 9...?
dang, the info out there really is sparse. I have some regular DDR5 in my pile of parts I guess I am going to run until I can find myself some 80-bit 16GB sticks.There's also these Kingston sticks with 10 chips but 72-bit
I'm optimistic that this is still functionally the same as DDR3/4 unbuffered ECC, i.e. 1 bit correction 2 bit reporting, but would love some clarity
I would suggest that the 80bit is the only true indication that ECC is working correctly in a UDIMM configuration. Based on what my RDIMM ECC DDR4 server's reporting that it has "multi-bit" error correction which I interpret as "detect/correct and report" vs. my WS680 reporting a ECC level of 5 - which I interpret as "detect/correct" only - but I am not sure if I would see an "event" in Windows indicating that an error has been corrected, like I would expect in an RDIMM configuration.
The 72 bit depth, is what I would continue to presume to be the onboard ECC - which is a new feature added to DDR5 modules to enhance the reliability of the memory, given the cell size.
There are still a few posts that are after this post back to me - I would still suggest that unless a module specifically says "ECC-UDIMM" on the label, I would other presume it to be standard on-die ECC.
Hope this helps - cheers!
Not sure of it from the memory chip count, but it looks to be the case, that if you see something indicated in the spec sheet to be the same as that Kingston spec sheet, then it is still on-die ECC - for DDR5 memory at least - 72-bit = On-Die ECC, which I would think that all DDR5 modules that are common on the market are specified as.There's also these Kingston sticks with 10 chips but 72-bit
I'm optimistic that this is still functionally the same as DDR3/4 unbuffered ECC, i.e. 1 bit correction 2 bit reporting, but would love some clarity
I guess the question might be more whether the single bit ECC is in addition to the standard on-chip ECC of DDR5 or not, perhaps it is for 10 chip modules but not for 9...?
Could you confirm the CPU you bought in the end - I thought from reading an earlier post you had gone for an i5-12500? Though I guess might have gotten confused after reading 25+ pages of comments
Just asking as was wondering which CPU the power consumption numbers you posted are based on.
Also is there a model number or any other identifying info on the IPMI card? Where I am I can't seem to get the IPMI version, but have found a card available separately described as -
"
Asus Ipmi Expansion Card W/ Dedicated Ethernet Controller Vga Port Pcie 3.0 X1 &
ASUS IPMI expansion card with dedicated Ethernet controller, VGA port, PCIe 3.0 x1 interface and ASPEED AST2600A3 chipset to provide the intelligence for IPMI architectures "
Last edited:
I have the non-IPMI version, but I can confirm that PL1/PL2 can be set in the bios.
Can confirm the PL1/PL2 can be set in bios. I had issues with mine continually going over what I set and had to disable the Asus feature that dynamically changes PL's. I'm running a i5-12500T at stock wattage and my server pulls about 90watts at low load. That's with 12HDD's, 3x m.2's, 2x sata SSD's and 2x HBA's in the case.
I have the IPMI version and struggled to find any identifying marks that told me much about the card. All I can really say is it's a AS2600 based board. It works well so far for me. Wiring is kind of clunky, but it's to be expected.
The only real issue I've had is getting the iGPU to show up. At first it was fine, but I stopped getting output from the board HDMI at one point and the iGPU fell off as a device. I found the server was only picking up the IPMI card as a GPU and ignoring the iGPU even with the iGPU set as primary display output in the BIOS. Ended up enabling the feature allowing the iGPU and dGPU to both be used simultaneously for displays deep in the advanced settings to resolve the issue.
Thanks so much for this response, you've really helped me out hugely and covered all of doubts I had in my mind
On the ECC saga...
My understanding is that that on-die ECC is a required part of the DDR5 specification. This is not optional. It is also internal to the stick and is not reported out at all. This would mean a 64 bit width. 72 and 80 bit width are different choices on true ECC to the outside. There is obviously some subtlety to this story that is not entirely clear yet... It would be nice for the manufacturers to clear this up
My understanding is that that on-die ECC is a required part of the DDR5 specification. This is not optional. It is also internal to the stick and is not reported out at all. This would mean a 64 bit width. 72 and 80 bit width are different choices on true ECC to the outside. There is obviously some subtlety to this story that is not entirely clear yet... It would be nice for the manufacturers to clear this up
this is
Last edited:
No. from the JESD79-5/A/B standard that defines DDR-5, on-die ECC is required. Here is a quote from the draft version (the only version not behind a paywall):
4.29 On-Die ECC - Q1’17 Ballot #1830.50 DDR5 devices will implement internal Single Error Correction (SEC) ECC to improve the data integrity within the DRAM. The DRAM will use 128 data bits to compute the ECC code of 8 ECC Check Bits. For the purpose of describing the ECC code, the 128 data bits are divided into four code word quarters - a top 64 bits (63:0) comprises Q1 and Q2. And a bottom 64 bits 127:64), Q3 and Q4 as shown in Table 82 and Table 83 respectively.
Note the term used is "will" which is the same as "shall".
4.29 On-Die ECC - Q1’17 Ballot #1830.50 DDR5 devices will implement internal Single Error Correction (SEC) ECC to improve the data integrity within the DRAM. The DRAM will use 128 data bits to compute the ECC code of 8 ECC Check Bits. For the purpose of describing the ECC code, the 128 data bits are divided into four code word quarters - a top 64 bits (63:0) comprises Q1 and Q2. And a bottom 64 bits 127:64), Q3 and Q4 as shown in Table 82 and Table 83 respectively.
Note the term used is "will" which is the same as "shall".
Because the JEDEC standard is the defining standard for DDR-5. (Actually JEDEC has defined the standard for all flavors of DDR.) All three major memory manufacturers, Samsumg, Hynix, and Micron vote on the standard and agree to comply with it. If you look in the specs sheets for the their DDR-5 drams, they all are JEDEC compliant.
that means they can not implement something better than on-die-ECC ? you wll never know if its there or not.
I haven't gotten this deep into this type of technical documentation in a long time, but the JEDEC standards are pretty clear on on-die ECC standards.
For example Micron's specific version of their implementation of the JEDEC DDR-5 standard, https://media-www.micron.com/-/medi...core.pdf?rev=f76eb9631b674e66a2026c324a95cb67. See page 137.
For example Micron's specific version of their implementation of the JEDEC DDR-5 standard, https://media-www.micron.com/-/medi...core.pdf?rev=f76eb9631b674e66a2026c324a95cb67. See page 137.