delray_kevin

Well, 23 days after I handed my previous sample over to UPS, the replacement has arrived. (Yes, the vendor accepted the return and sent a replacement chip.) So far, the new one has been running small FFT's without an issue for a couple of hours (the old one wouldn't last 2 seconds.) I cleared CMOS when I took the old chip out so I wouldn't forget. Everything is stock and everything has been excellent. There will be some smallest FFTs and Blend runs before I call this good, but so far I'm further along than with the last one.

Update on 6/16/20. At the end of the day, I just couldn't accept the fact that this thing couldn't do math without having LLC cranked to "Medium". ("Low" only bought me a bit of stability, I had to go to "Medium" to get real stability.) There is just no reason that at stock settings, any CPU should fail to run any software. So my chip got RMA'd back to the vendor. It will not probably be two to three weeks before I have a chip back. It sucks, but at the end of the day I know it's the right thing to do. Hopefully I draw a better sample the next time through.

OK, I bit. At least OCCT is more entertaining to watch than P95. An hour and some with all 32 cores at turbo (4.19 GHz) and no errors. I'll probably need ot let this go longer, but I couldn't really figure out what OCCT is doing to the machine and decided to stop it for the night. The temps were lower than with P95, and the program held the CPU at Turbo the whole time. It's actually that transition (specifically down off of turbo when the CPU has had "enough" that I think is the issue.)

@ShrimpBrine, you don't know how true that is. No tempered glass and almost no RGB (only the bits I couldn't avoid because they were pre-built into the gpu and the mb, and as much of that as I can muster is turned off.) For a hot minute I considered I'd make something that would make Vegas jealous and then I came back to reality. This will sit quietly and elegantly in a corner looking a bit like the monolith from 2001 A Space Odyssey. OCCT is on my list to throw at it. I am slightly concerned about thermal performance because of where the case will be (there is good clearance around and behind it) and I do have four 120 fans in the case, plus the two 140's on the NH-D15 (push pull, aimed directly at the exhaust on the back) and the fans on the gpu and that stupid little bugger on the chipset, but that's all close up in a box with several components that are very effective space heaters.) I just want to make sure it's not going to cook itself quietly in that corner. Is the doc for OCCT decent? I downloaded it, but haven't looked yet. I have not heard of Linpack, I'll consult the oracle (Google), I'd been planning on another old school choice: Memtest. I'd have preferred G.Skill memory (I'm sure that will trigger someone) but I couldn't find any that would clear the cooler. That's a personal preference, it's Ford and Chevy, they're both fine, but people get loyal to one or the other. The thing that really irks me that is that I couldn't find anything on the QVL that used Samsung chips and afforded 16GB sticks, and wasn't loaded down with RGB (which adds almost 1 cm to the height of the stick.) G.Skill has several kits, but that would lead to displacing the front fan on the cooler, etc, etc., all for the sake of an RGB strip I was never going to see. Anything that was low profile, or bare, and on the QVL and had Samsung chips also only came in 4X8GB sticks (for the initial 32GB target). So you KNOW that memory is going to get turned inside out before I sign off on it.

@Eighjan I'm sure I cleared CMOS when I flashed the UEFI (simply because that's part of any BIOS flash update), but I also don't remember that explicitly. I'm surprised that I don't remember and will likely do it again just to make myself feel "complete" (that's not to suggest that it's a bad, or fluffy idea, but I really am surprised that I don't remember reaching for the screw driver to short the jumper (no, this board doesn't have a Gucci button to push.)) @svmlegacy I need to go back and look. I didn't take a voltmeter to it, but I should be able to get that out of HWMonitor of HWiNFO when I get a chance.

So I have a bright and shinny 3950x. So far this thing has proved to be the beast it was advertised to be. But there's always that one fly that gets in the ointment. The whole rig (which is not at all intended for gaming) looks like this: 3950x Gigabyte X570 Aorus Pro 32GB Corsair memory (don't remember the model, but I chose it off the QVL for the MB and to clear the cooler.) MSI GTX-1660 Super (no, I'm really not gaming with this) 1 TB Intel MVME (because I could) Seasonic GX-750 gold PSU Noctua NH-D15 Windows 10 Pro All the latest drivers have been installed and I flashed the board to the most recent UEFI. It has handled Cinebench and Aida64 testing with no problem (both were run for hours, I know not complete tests, but I only built it yesterday.) Temps are reasonable (hovering around 61 under load, with occasional spikes to around 80 for a second or two, can't really explain why, but they're there) and I don't see any errors reported. Being a bit old school, I then fired up Prime95. And right out of the gate got errors on small FFTs. There were consistent on the same "core" numbers (18 and 19, so I assume them to be virtual as the physicals seem to be 0 through 15.) Long story short, I could "walk" the errors around by messing with the number of works I used and how many "cores" I told each to exercise. Everything in the UEFI was set stock, I hadn't even enabled XMP yet. (Though when I did that it made the errors worse.) I didn't disable Turbo (or whatever AMD is calling it these days.) So in a sense the chip was trying to OC itself when it detected load. I consider that "normal" behavior and should have been included in the test. I started playing with XMP as the memory voltage seemed low. But that got me looking at other voltages and ultimately lead me to start thinking about vdroop. (That was a long and twisted path that I won't bore everyone with.) Ultimately if I did find that if I set LLC to "Low", the system stopped throwing errors and Prime95 ran for slightly over 8 hours before I stopped it. I have another small FFT run going right now and it's behaving similarly. What I'm now faced with is what do with this mess. I do think the chip is beast and even in my short time I've come to really like it, but I also want something that's long term stable and doesn't have monsters lurking inside it just waiting for the right (and inopportune) time to come leaping out and reeking havoc. While I now know how to keep said monsters locked up where they don't show themselves, I don't really like that I had to tweak something in the UEFI to get it to be stable. I've never had to do that with any other chip and I've never seen a chip that didn't pass basic (albeit strenuous) tests. I cannot decide: If there is some problem with how the "Auto"/"Normal"/"Standard" LLC setting is implemented in the Gigabyte UEFI (all three seem to be the same.) If there is some system power supply issue that is showing up on power hungry chips like the 3950x and the Threadripper series (there are several folks in other forums reporting similar issues with Prime95 and these chips) If this has something to do with the fact that the memory seems to be under-volted. If there is a problem with my specific chip. If there is a problem with some other component (motherboard, memory, or PSU.) All are going to get tested as best I can. Or if I should be glad that I know how to keep this controlled and be happy with what I have. I did also read a description posted by a guy in another forum who had an issue similar to mine. He decided to RMA his chip, and has ended up, two RMAs later, with one that behaves worse than either of it's predecessors. That is train I totally don't want to get on. I figured that I'd see what folks here thought about this. Thank you in advance for any input you might have, and sorry for the long post.