Are you using ECC with 64 GB+?

Geshtar

Limp Gawd
Joined
Apr 15, 2004
Messages
227
There seems to be a good number of people running 64GB+ on systems in the "How Much RAM you Got?" thread/poll. There wasn't a lot of detail on what kind of systems they were running though. Are most of you doing this on consumer systems without ECC? Or with Workstation/Server setups? Have you had any problems with it? I am looking at building a new computer and would definitely benefit from moving above 32GB but I just wonder about the law of large numbers and having data corruption issues. 64 GB is really getting to be quite a lot memory with no protection. I don't really have the money to build a full workstation build, so it seems like my choice is 32 GB or 64 GB on a consumer system(probably AMD AM5 socket) with no ECC since it seems like no one really supports ECC on consumer platforms. =/
 
Ive been running 64 GB on my AM4 system since I built it back in late 2019, and havent had any memory issues with it. I just made sure my kit was on the QVL when I bought it, plugged it in and set XMP.
 
I use ECC RAM wherever possible, including on my current PC with 64GB of DDR4. It's just a normal desktop PC with normal unregistered DDR4. There haven't been any errors recorded to date, except ones from when I was experimenting with overclocking the RAM (where ECC is useful because it lets you know for sure when you've gone too far, with less crashing, and no randomly corrupted Windows installations).

I have seen errors recorded on other systems though - anywhere from just one or two ever, to one or two per week. If I hadn't had ECC in those that had errors, I would at best have had weird, impossible to diagnose bugs every so often, and at worst silent data corruption that might not be discovered until it's too late to fix.

I don't know what it's like on AM5 now, but for AM4, pretty much all Asus and Asrock boards support ECC. My experience is that it Just Works™, though it can be hard to verify that.
 
I use ECC everywhere except on my gaming machine and most laptops. I even have a laptop with ECC. I know what data corruption can do, and how silent it can be, shredding stored data until it's too late.

Most of those machines are using registered ECC ("server class" hardware) but I also have 2 Gigabyte AM4 machines running with unbuffered ECC. Works fine except for the RAM being expensive and rare. You might want to check out W680 boards if you want Intel desktop CPUs with (unbuffered) ECC.
 
When talking about 16-32-64 type of quantity, wonder if it is not more about the data handled by ram than the quantity.

Is it code or program where corruption would either not matter or show up (binary check via git all the time occuring and stuff that would not work if corrupted) versus audio, video, image where for giant chunk of ram all possible value are perfectly legitimate and can go without anyone seeing the error, back in the old days people did build 8-12-16-24-32 gig system with ECC, well 512 gig was a giant amount of ram in 1994 and people used system of the sorts since the 70s when they counted ram in kb.

I imagine there is many use case where 64-128 gig of regular memory is not an issue while for some photo editor on their mac pro that had "only" 32 it would have been, because of the nature of the work, there stuff where data corruption show up and you are lucky it crash or a file system tell you the binary changed since the last save and in what ways and you do not need ECC, there stuff where it cause silent issue that do not crash and is a big deal (and obviously there system where a crash itself would be a big deal, but usually you do not go asking question on message board for those)
 
All of my machines are 32G machines, but I run ECC RAM in my Dell PowerEdge R515 server (effectively just used as a NAS)... and on my Plex machine that connects to it (Crosshair VI Hero with 3900X CPU). The Dell has 2 pools on it, one that is available over network via SMB, and the other is iSCSI to the Plex machine, and the Plex machine "mirrors" the SMB share to the iSCSI link. Basically anything that connects directly to my long-term data storage has ECC.
 
I had heard that the ECC issue would be a non-issue under DDR5 when it came out because ECC is supposed to be a mandatory part of the spec (or something very much like it), but I see that there is still separate ECC RAM for DDR-5 systems. Not sure about how that works at all, would love someone to chime in here about it.
 
I had heard that the ECC issue would be a non-issue under DDR5 when it came out because ECC is supposed to be a mandatory part of the spec (or something very much like it), but I see that there is still separate ECC RAM for DDR-5 systems. Not sure about how that works at all, would love someone to chime in here about it.

The mandatory stuff is only hidden inside a DDR5 DIMM. You can't even get messages about corrected or detected errors out of them, and the transport is unsupported. Overall you could argue that this is worse than no ECC because now you can't test your RAM in memtest to find existing broken cells.
 
When talking about 16-32-64 type of quantity, wonder if it is not more about the data handled by ram than the quantity.

Is it code or program where corruption would either not matter or show up (binary check via git all the time occuring and stuff that would not work if corrupted) versus audio, video, image where for giant chunk of ram all possible value are perfectly legitimate and can go without anyone seeing the error, back in the old days people did build 8-12-16-24-32 gig system with ECC, well 512 gig was a giant amount of ram in 1994 and people used system of the sorts since the 70s when they counted ram in kb.

I imagine there is many use case where 64-128 gig of regular memory is not an issue while for some photo editor on their mac pro that had "only" 32 it would have been, because of the nature of the work, there stuff where data corruption show up and you are lucky it crash or a file system tell you the binary changed since the last save and in what ways and you do not need ECC, there stuff where it cause silent issue that do not crash and is a big deal (and obviously there system where a crash itself would be a big deal, but usually you do not go asking question on message board for those)

The problem isn't so much the data, but the metadata.

When you write to a disk a lot, a lot of RAM is used as a write buffer. Any bit in there can be flipped. But the result might not be a corrupted file. There are all these data structures describing which page goes where, and if you have a bit flipped in those then random blocks are written to random places. You can corrupt any file you didn't even read during the uptime, or you lose whole directories from a single error.
 
The mandatory stuff is only hidden inside a DDR5 DIMM. You can't even get messages about corrected or detected errors out of them, and the transport is unsupported. Overall you could argue that this is worse than no ECC because now you can't test your RAM in memtest to find existing broken cells.

It's better and worse. Well transport errors are the same.

Storage errors will likely be reduced; but lack of reporting means consistent single bit failures are undetectable. So you won't know you have a problem, and when you do have problems, it will all be at least double bit errors.

Maybe, maybe, maybe, single bit corrections will be detectable because there's probably additional delay. But timing based detection is a terrible way.

OTOH, ECC ram costs much more, and I'm cheap. I run memtest when I get new ram, don't get aggressive on ram timings and hope for the best. I've seen ECC works on large server fleets, but yeah.
 
OTOH, ECC ram costs much more, and I'm cheap. I run memtest when I get new ram, don't get aggressive on ram timings and hope for the best. I've seen ECC works on large server fleets, but yeah.

DDR4 registered is dirt cheap right now. Pick up 4x 32 GB for $120 shipped if you go with Ebay auctions.

DDR4 unbuffered is bad. DDR5 unbuffered is OK, $163 for 32 GB sticks on the supermicro store. Compared to regular DDR5 that is livable.
 
DDR4 registered is dirt cheap right now. Pick up 4x 32 GB for $120 shipped if you go with Ebay auctions.

DDR4 unbuffered is bad. DDR5 unbuffered is OK, $163 for 32 GB sticks on the supermicro store. Compared to regular DDR5 that is livable.

Yeah, registered ram from server retirements is cheap. But I'd also need a server board to use it, so no dice this round. i'm not on DDR5 yet, personally.
 
Does the average person need ECC memory if they have like lots of family pictures stored on their computer and don't want it to get corrupted?
 
Does the average person need ECC memory if they have like lots of family pictures stored on their computer and don't want it to get corrupted?

Depends on the backup strategy. There needs to be a backup that goes on the shelf and doesn't get overwritten.

If you just backup to the same USB disk all the time then silent corruption will overwrite your backup before you notice the corruption.

It isn't so much single bit errors from cosmic rays. It is a RAM stick going bad, or a heat problem.
 
Depends on the backup strategy. There needs to be a backup that goes on the shelf and doesn't get overwritten.

If you just backup to the same USB disk all the time then silent corruption will overwrite your backup before you notice the corruption.

It isn't so much single bit errors from cosmic rays. It is a RAM stick going bad, or a heat problem.
What's the best way to check for data corruption, assuming someone has a windows 11 PC and they back their data up to external hdd's?
 
What's the best way to check for data corruption, assuming someone has a windows 11 PC and they back their data up to external hdd's?

Well for photos it is easy since they are generally immutable (always save to a different filename when editing, preserving the original file). Keep a catalog of the sha checksums for existing files somewhere and run a check before running backup.

Regularly running memtest is also recommended.
 
The mandatory stuff is only hidden inside a DDR5 DIMM. You can't even get messages about corrected or detected errors out of them, and the transport is unsupported. Overall you could argue that this is worse than no ECC because now you can't test your RAM in memtest to find existing broken cells.
what??? I had heard about the internal ECC stuff for DDR5 and it not being very useful, but I had not heard that it breaks memtest. That is indeed horrible if there is no replacement for memtest functionality. I have had a system where the RAM went bad and the way I diagnosed it was by running memtest. It really feels like the computer industry is going to shit on the consumer side all around. I have always enjoyed building computers until this one.
 
Does the average person need ECC memory if they have like lots of family pictures stored on their computer and don't want it to get corrupted?
Probably not, that is more of a storage issue. People have had lots of family photos for years. For the most part people aren't editing their photos/videos all the time, so it is mostly read only operations. Even if it got corrupted in memory it would like be unnoticed and cease to be a problem when the image/video was closed since nothing new is being written to disk. If an image/video does get corrupted you may not even notice(maybe it just means a pixel changes color) or it may be fixable. As much as they might have sentimental value, it just isn't as big of a deal as data corruption on important system/program files, intermediate files(like code compilation), or critical data like financial data, or corruption of working memory that leads to instability. Plus you can guard against it with backup strategies like uOpt suggested or by duplicating data with mirrored RAID or online backup, etc.

If you are taking errors and getting silent data corruption, the big fear is weird system instability that can manifest in weird ways. Like when the RAM on one of my systems went bad, it manifested as display corruption because it was a portion of the RAM that usually got loaded with OS code that dealt with the display(maybe the video drivers). But that was a 'lucky' case since it was the RAM physically going bad in one specific spot that usually got loaded with the same code so it was repeatable. With silent data corruption due to things like cosmic radiation it is transient and could cause something to crash one time, another time something else crashes, or it could corrupt newly generated data that then gets written to disk and shows up as corrupted data days/weeks/months later etc. Debugging intermittent/transient failures for anything is usually a nightmare.

From what I can tell, ECC on DDR5 consumer platforms is basically a no go as of right now. Intel has never done much, and what they did was usually on weird low end parts but even that ended with 12th gen I hear. AMD has been better but on AM5/DDR5 no one really seems to support it though there was something about support being added in AGESA 1.0.0.5 I think. On top of that, there is basically no unregistered ECC RAM available if I understand it. Serve the Home had a thread on where to find ECC RAM for compuer platforms incase there was 'stealth' support, but there were only a tiny handful of DIMMs listed. If you want anything off your motherboard's QVL list there will certainly be nothing. I supposed support could trickle in as AM5 matures, but it doesn't look good for the near term. I really think ECC should stop being used to segment markets and just be a standard feature at this point. *sigh*

I think what I learned from this thread so far is people do use ECC with 64GB plus, but it is on the older AM4 or server platforms. Thanks for the info guys. I'll keep checking back periodically to see if anymore people chime in with what they use.
 
Probably not, that is more of a storage issue. People have had lots of family photos for years. For the most part people aren't editing their photos/videos all the time, so it is mostly read only operations. Even if it got corrupted in memory it would like be unnoticed and cease to be a problem when the image/video was closed since nothing new is being written to disk. If an image/video does get corrupted you may not even notice(maybe it just means a pixel changes color) or it may be fixable. As much as they might have sentimental value, it just isn't as big of a deal as data corruption on important system/program files, intermediate files(like code compilation), or critical data like financial data, or corruption of working memory that leads to instability. Plus you can guard against it with backup strategies like uOpt suggested or by duplicating data with mirrored RAID or online backup, etc.

If you are taking errors and getting silent data corruption, the big fear is weird system instability that can manifest in weird ways. Like when the RAM on one of my systems went bad, it manifested as display corruption because it was a portion of the RAM that usually got loaded with OS code that dealt with the display(maybe the video drivers). But that was a 'lucky' case since it was the RAM physically going bad in one specific spot that usually got loaded with the same code so it was repeatable. With silent data corruption due to things like cosmic radiation it is transient and could cause something to crash one time, another time something else crashes, or it could corrupt newly generated data that then gets written to disk and shows up as corrupted data days/weeks/months later etc. Debugging intermittent/transient failures for anything is usually a nightmare.

From what I can tell, ECC on DDR5 consumer platforms is basically a no go as of right now. Intel has never done much, and what they did was usually on weird low end parts but even that ended with 12th gen I hear. AMD has been better but on AM5/DDR5 no one really seems to support it though there was something about support being added in AGESA 1.0.0.5 I think. On top of that, there is basically no unregistered ECC RAM available if I understand it. Serve the Home had a thread on where to find ECC RAM for compuer platforms incase there was 'stealth' support, but there were only a tiny handful of DIMMs listed. If you want anything off your motherboard's QVL list there will certainly be nothing. I supposed support could trickle in as AM5 matures, but it doesn't look good for the near term. I really think ECC should stop being used to segment markets and just be a standard feature at this point. *sigh*

I think what I learned from this thread so far is people do use ECC with 64GB plus, but it is on the older AM4 or server platforms. Thanks for the info guys. I'll keep checking back periodically to see if anymore people chime in with what they use.

The situation is not as bad as you describe.

ECC unbuffered DDR5 has been reliably available from the Supermicro Store for months, and it isn't too expensive.

In the Intel world you have many 12th and 13th gen CPUs that support ECC is the W680 boards.

The situation around AM5 BIOSes is indeed messy right now. But AM4 ECC works fine for me.
 
My personal experience with udimms vs ecc udimms vs ecc reg is that ecc reg systems were more stable with more uptime. Granted, this isn't an apples to apples comparison since it's server vs desktop to be able to see these results, but a server with ecc reg memory had a uptime nearly double the udimm one (which either rebooted on error or needed to be rebooted).

As far as where I'm using the ram--it depends. I'm still on ddr3, but I discovered that the hp z420 that was supposed to be 'ecc udimms only' with a limit of 32GB in reality would support 32GB ecc reg modules when an e5-2630L v0 was installed. Well, I've stuffed 256GB of ecc reg memory in that desktop because it can take it. Some of the other 'workstation' type of systems support ecc reg as well as high memory capacities. I know my hp z600 can take 96GB using 16GB modules, and most of the Dell T-series workstations easily are 128GB+.

What it really comes down to is how much you are using that ram. In server, the ram can yield huge caching benefits whereas in a desktop maybe not so much since that's [badly] managed by the OS. On the other hand if you have huge media files that stay in ram, then the more ram the better. Really just depends on what you are doing and how critical the ram is.

But one thing is for sure, as densities and capacities increase, the likelihood of an error increases--it's just physics. And for the most part, nothing has really been done to reduce the likelihood in a big way as the error rate has been holding steady for the last decade or so.
 
I have successfully ran 128GB of ECC on two AM4 setups. In both instances the RAM has been Unbuffered ECC from Nemix. 4x32GB 2666MHz on Asrock X370 Taichi with both a Ryzen 1700/2700X. 4x32GB 3200MHz with Ryzen 5 Pro 5650GE on Gigabyte X570S Aero G. I didn't start with 4 dual rank sticks of 3200MHz because I didn't think the Zen/Zen+ CPU integrated memory controller could handle it (although I never actually tried). But with Zen 3 I figured it would be no issue, which turned out to be correct.

The way I would try to approach this is like: do my CPU and motherboard support ECC? What type- unbuffered or registered? Non server platforms are usually unbuffered. Then what can the IMC likely handle frequency wise? Looking at 128GB total you'll be running 4 dual rank sticks, which is quite stressful on any platform so speed limitation isn't just limited to ECC. If you're going AM5 or LGA 1700 (seems like only W680 boards support it) 4800MHz DDR5 Unbuffered ECC (e.g. KTH-PL548E-32G) should be a safe bet. I'm not as familiar with the new platforms on AM5/LGA 1700 (W680 chipset), but maybe even 5600MHz would be easily achievable too?
 
My main i7-12700K/Z690 setup runs 64 GB of unbuffered, non-ECC DDR4, but mostly because it's cheap, it's fast, and Intel withholds ECC support from non-W680 chipsets anyway - a chipset that Micro Center doesn't even sell a single motherboard bearing, to my knowledge.

The plan to go ECC was on my Threadripper 1950X setup precisely because it's supported there, but alas, it has to be unbuffered DDR4 because registered DIMM support likely would've encroached on EPYC a bit too much for AMD's liking. Getting 256 GB of unbuffered ECC DDR4-3200 would be over $600 alone - yikes! I'm sticking with the 32 GB of non-ECC DDR4 I have thrown in there for the time being, until prices come down further.

I may have still bit the bullet and gone through with it, had this used Lenovo x3650 M5 server not presented itself as an opportunity to get a whopping 768 GB of registered, obviously ECC DDR4, in a complete enterprise-grade server system, for less than the price of a third of that in unbuffered form for a Threadripper build. Sure, it's slower DDR4-2133 that can't even run at that speed beyond 512 GB due to Haswell-EP memory controller limitations, but it's still loads of memory, more than I really know what to do with for the time being.

Would the 1950X be faster in single-thread workloads? Significantly so, since it's running at 4 GHz all-core. The RAM would be running a bit faster, too. But the cost of going ECC on it was just too prohibitive to the point that I couldn't bring myself to do it, with my gut feeling telling me that unbuffered ECC DDR4 is going to stay expensive like 8 GB DDR2 FB-DIMMs (used in old cheese grater Mac Pros and other Core 2-era Xeon platforms like Skulltrail), 128 MB 5V FPM/EDO DIMMs (the kind mid-'90s Power Macs use) and any sort of proprietary SGI Octane or O2 RAM due to simple rarity relative to more common formats.
 
Current build has Mushkin RedLines 32GB ECC (unbuffered) in B550. Those are the highest performing ECC modules I could find at the time. Happy so far.
 
I have had 64GB non-ECC across multiple systems for multiple years now. I run some of my computers 24/7. I have never had any issues or data corruption that I know of. When exactly is this sort of thing likely to occur?
 
I have had 64GB non-ECC across multiple systems for multiple years now. I run some of my computers 24/7. I have never had any issues or data corruption that I know of. When exactly is this sort of thing likely to occur?

Either randomly from cosmic rays or as a result of a DIMM going bad, or overheating or so. The true benefit of ECC is that you get warning messages before corruption occurs (well, most of the time).
 
My main i7-12700K/Z690 setup runs 64 GB of unbuffered, non-ECC DDR4, but mostly because it's cheap, it's fast, and Intel withholds ECC support from non-W680 chipsets anyway - a chipset that Micro Center doesn't even sell a single motherboard bearing, to my knowledge.

The plan to go ECC was on my Threadripper 1950X setup precisely because it's supported there, but alas, it has to be unbuffered DDR4 because registered DIMM support likely would've encroached on EPYC a bit too much for AMD's liking. Getting 256 GB of unbuffered ECC DDR4-3200 would be over $600 alone - yikes! I'm sticking with the 32 GB of non-ECC DDR4 I have thrown in there for the time being, until prices come down further.

I may have still bit the bullet and gone through with it, had this used Lenovo x3650 M5 server not presented itself as an opportunity to get a whopping 768 GB of registered, obviously ECC DDR4, in a complete enterprise-grade server system, for less than the price of a third of that in unbuffered form for a Threadripper build. Sure, it's slower DDR4-2133 that can't even run at that speed beyond 512 GB due to Haswell-EP memory controller limitations, but it's still loads of memory, more than I really know what to do with for the time being.

Would the 1950X be faster in single-thread workloads? Significantly so, since it's running at 4 GHz all-core. The RAM would be running a bit faster, too. But the cost of going ECC on it was just too prohibitive to the point that I couldn't bring myself to do it, with my gut feeling telling me that unbuffered ECC DDR4 is going to stay expensive like 8 GB DDR2 FB-DIMMs (used in old cheese grater Mac Pros and other Core 2-era Xeon platforms like Skulltrail), 128 MB 5V FPM/EDO DIMMs (the kind mid-'90s Power Macs use) and any sort of proprietary SGI Octane or O2 RAM due to simple rarity relative to more common formats.

If you want large amounts of RAM nothing beats the prices of DDR4 registered. It can make up for the cost of upgrading to a EPYC or Xeon E5. Of course single-core performance is out the window at that point.
 
If you want large amounts of RAM nothing beats the prices of DDR4 registered.
Except for ddr3 ecc reg, which is stupid cheap now--less than 20cents/gb if you're looking in the right place. Is it the fastest--no. But when you're looking at something that is memory bound and you can throw 512GB-768GB at it for $100-150, it might still be worth looking into.
 
  • Like
Reactions: uOpt
like this
I have had 64GB non-ECC across multiple systems for multiple years now. I run some of my computers 24/7. I have never had any issues or data corruption that I know of. When exactly is this sort of thing likely to occur?
Ever have any unexplained crashes? Ever verify the integrity of a game on Steam and have it fix a problem? Or run sfc /scannow and have it find a problem? How would you even know if any other files became corrupt? For instance if you have a collection of photos, do you open them all to check?
 
Either randomly from cosmic rays or as a result of a DIMM going bad, or overheating or so.

I think when I was running memtest86, the maximum ram temperature that I saw on these sticks was about 43C? Or 41? I didn't record it. That is with the voltage at 1.4, and I think I'm going to lower that.

Ever have any unexplained crashes?

Not really, no. I've had my computer up for multiple months straight before without any issues. On my DDR4 3200 16GB*4 setup with the 5950X on an AM4 board anyway. This AM5 7800X DDR5 6000 32GB*2 also has never crashed, but then again it's newer so I can't say with certainty yet. On my old setup, I have left Persona 5 running for probably about a month as I occasionally tuned in and out of it. I never had it crash or had any issues.

With this new setup, I have left Starfield running (after I disabled the buggy DLSS mod) for like a week? Again, kept tuning out and into it. Didn't really have issues. I think the only game I've had crash recently that was absolutely inexplicable is Divinity Original Sin 2 (which is just crash to desktop, not blue screen or anything), on this new platform. But... it crashes on my friend's system, too, and it literally requires a computer restart due to network problems, so my money is on "coded like shit".

Ever verify the integrity of a game on Steam and have it fix a problem?

Not really, no. But I'll note that there are various game bugs and issues where the recommended course of action via google is to just "verify integrity" anyway (though it rarely works in my experience), so I'm not sure if this means much... I kind of doubt that's due to ram corruption.

Or run sfc /scannow and have it find a problem?

I don't really run that much nor have ever needed to, so can't comment. I have about 62 TB worth of HDDs and NVMEs (and 1 SATA SSD) hooked up to this computer at the moment. I assume it would take a while, so I sure as heck am not running that without a good reason.

How would you even know if any other files became corrupt?

I mean, I assume that in order to become corrupt they would have had to pass through the DRAM before being written. Which means if they were in the DRAM, I was actively using them to some capacity.

For instance if you have a collection of photos, do you open them all to check?

I have comics that are archived, so yes if it was corrupt I think I would see some weird images.
 
Last edited:
I think when I was running memtest86, the maximum ram temperature that I saw on these sticks was about 43C? Or 41? I didn't record it. That is with the voltage at 1.4, and I think I'm going to lower that.

I once had a situation where a (fanless) south bridge chip in a vertical case heated up the RAM above it to the point where I got ECC errors. A fan fixed it. Without ECC notifications I might have suffered data and filesystem corruption. This event drove me further into the pro-ECC camp.
 
I have comics that are archived, so yes if it was corrupt I think I would see some weird images.

The corruption you can face is not necessarily inside files. You can also use whole directories or the entire filesystem all at once.

Keep in mind random bit flips might effect RAM words that encode where a block goes on disk and then splatter such a block over something entirely unrelated such as a filesystem allocation table.
 
ECC is one of those nice to have but really not needed features for most. I wouldn't bother with it on desktop/workstation if it means getting slower or less RAM.
 
Not really, no. I've had my computer up for multiple months straight before without any issues.
That's some good uptime for sure, but to see the difference in ecc and non-ecc, you really need to run both in the same environment until they crash on their own. This is where I saw the difference as a non-ecc consumer system stayed up for a few months, while a server with reg ecc ram ran over 2x as long on the same environment before a crash. And it did this consistently when compared to all the consumer platforms I have. This is when I realized that ecc reg is the way to go and so are servers since you get a lot more power for the price and I can just put them elsewhere and RDP into them, which is what I was doing for systems too anyways so it's a good fit.
 
Had an mce [Hardware Error] log in the middle of a multi-TB copy off of an external USB 3.0 HDD into my server's zpool; while admittedly annoying in that it halted the copy midway, it at least warned me that something wasn't right.

Having ECC has already paid off just for that alone, and if it's an actual consistent hardware issue traceable to one of the RDIMMs, I just got a few replacements.
 
NamelessPFG's post made me check my logs, and there has now been 1 corrected error on my PC, which happened in April this year, not long after my previous post where I said this machine had never had an error. With just a single error over the 3 years since I built it, it's unlikely to be because of faulty RAM; it could have been a cosmic ray.
 
I am running two 64GB kits, both C32 Gskill Trident Z kits one 6400 the other 6000 and both kits have been great on windows 11 64bit.
 
Back
Top