3 ms·

Merely anecdotal, but I've run heavy multi-threaded compile tests on my 1950x for days to check whether the chip was stable when overclocked, and have never see

Merely anecdotal, but I've run heavy multi-threaded compile tests on my 1950x for days to check whether the chip was stable when overclocked, and have never seen it segfault. That was my main purpose for purchasing the CPU. I use it for that all day every day. If I were spending millions on Epyc servers, I'd certainly test this on a reasonably large sample before committing.

paulmd 9y ago
Yeah, given the binning that's in play I'm not particularly worried about TR. Out of an abundance of paranoia I would recommend a 24h run of kill-ryzen.sh on literally any Ryzen/TR processor (including RMA replacements) but TR is not likely to be a problem. For that matter, the chips that are taking 24h+ to segfault are not likely to be a problem either. It's the ones that are segfaulting in a matter of seconds or minutes that are going to be problematic for normal users. However, that's my thoughts as to why we're not seeing it on Threadripper despite it being on the same stepping. If it were a simple microcode fix (even if you needed to disable some codepath and cut a few percent off) then there is no reason not to pass that down to consumer Ryzen. So far, however, a microcode fix has not been forthcoming. So it's either TR is better binned and thus less subject to the fault, or that something about TR's NUMA layout is breaking one of the necessary conditions for the cache fault to occur. I do think AMD stepped up their QA after the fault was discovered. I've actually heard of post-week-30 retail samples passing kill-ryzen runs, whereas essentially 100% of the pre-week-25 chips display the fault. However, there are definitely post-week-30 chips that do still display the fault. I assume what's going on there is AMD is doing a quick run of kill-ryzen to weed out the shittiest chips, the ones that die in seconds/minutes. But since there isn't a way to deterministically reproduce this fault, and AMD can't realistically spend 24h testing every single chip for one fault, some of the only-somewhat-shitty chips are still leaking through their QA testing. I would take a random week 33 chip over a random week 08 chip for sure, the quality is definitely up, but week 30+ is no guarantee that your chip won't segfault either.

paulmd 9y ago

Yeah, given the binning that's in play I'm not particularly worried about TR. Out of an abundance of paranoia I would recommend a 24h run of kill-ryzen.sh on literally any Ryzen/TR processor (including RMA replacements) but TR is not likely to be a problem. For that matter, the chips that are taking 24h+ to segfault are not likely to be a problem either. It's the ones that are segfaulting in a matter of seconds or minutes that are going to be problematic for normal users. However, that's my thoughts as to why we're not seeing it on Threadripper despite it being on the same stepping. If it were a simple microcode fix (even if you needed to disable some codepath and cut a few percent off) then there is no reason not to pass that down to consumer Ryzen. So far, however, a microcode fix has not been forthcoming. So it's either TR is better binned and thus less subject to the fault, or that something about TR's NUMA layout is breaking one of the necessary conditions for the cache fault to occur. I do think AMD stepped up their QA after the fault was discovered. I've actually heard of post-week-30 retail samples passing kill-ryzen runs, whereas essentially 100% of the pre-week-25 chips display the fault. However, there are definitely post-week-30 chips that do still display the fault. I assume what's going on there is AMD is doing a quick run of kill-ryzen to weed out the shittiest chips, the ones that die in seconds/minutes. But since there isn't a way to deterministically reproduce this fault, and AMD can't realistically spend 24h testing every single chip for one fault, some of the only-somewhat-shitty chips are still leaking through their QA testing. I would take a random week 33 chip over a random week 08 chip for sure, the quality is definitely up, but week 30+ is no guarantee that your chip won't segfault either.