Oh, fair enough -- you are correct compared to 5950x. I was mentally comparing my personal experience with 7950x. Yes 1.7-1.9x seems fair for a bump from 5950x to 9950x (albeit at a higher power draw).
The author used kernel compilation as a benchmark. Which is weird, because for most projects a build process isn't as scalable as that (especially in the node.js ecosystem), even less after a full build.
I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced. I fear something terrible has happened.
I have a Ryzen 9 3900X. Officially it doesn't support ECC memory. In practice unregistered ECC DIMMs work fine, and ECC functions properly (single-bit correction, dual-bit detection).
I assume the 3950X is the same way. The hardware is there, the official blessing is not.
AFAIK, Ryzen 9 3900X do support ECC memory, but it's up to motherboard whether to officially support it or not. There are X570 boards out there with official ECC support, e.g. ASUS Pro WS X570-ACE[1].
They seem to cast doubt on if the bios and software all work together and are really performing the ECC checks even in cases where support might be possible they say things can stop it from working and fixing memory bits. I've no reason to doubt them and this is probably the reason for the lack of official support. Anyone know of a way to validate if it's working correctly?
By opening the case and holding your smartphone near and nearer into it, while having it search for networks. Until it crashes, and then checking the logs, if any :)
edit: I mean near the DIMMs.
Don't try this if you are afraid, or need your hardware. This is a test i'm doing with every build, or any system i have to fix. And it crashes every system, though not at the same places and in the same ways. So far it didn't damage anything permanently, but no guaranties it won't.
Are you serious? How very interesting. Really would like to hear from someone with experience in inducing errors that can say what the risks for permanent damage would be, save for data loss in case of flushing corrupted data to disk for course.
I am. This worked for me since the GSM-era. Imagine slowly pointing it like a wand, sweeping up and down, left, right, going nearer...into, searching. Until it ZAPS. Doesn't need touching. Or less than an inch distance. About 3 to 2 inches it usually is, but i also had crashs/freezes at maybe 10 to 5 inches, just outside the case when it was open.
edit: By searching for networks i mean for the telcos, not wifi. Then it uses all bands it is capable of.
I meant this as a figure of speech, not literally. There are no sparks flying, or something like that. "Zapping/tazing" it by applying some EMF, nothing more :)
Another option is to overclock the ram. Mine is rated for 2400 MHz and works fine up to 2666. It still 'runs' at 2800, but I get maybe 2-3 correctable ECC errors in an hour.
But I'm of course not suggesting to run it in this state whil doing anything important.
Interesting. I guess the DIMMs came blank, without heat sink/spreader on the chips, since ECC and therefore "non-gaming"? In that case i'd try some thin aftermarket clip-on.
Nothing hilarious like "HyperRacerMegaBlingMarkVII" would come with. To see if the ECC-errors occur because of running out of specification frequency wise in general, or if they just occur because of running at too high temperature because running at a too high frequency (and maybe voltage) without cooling.
Because vendor didn't plan/produce/verify for that use-case.
So I'd verify that, and enjoy in case of the latter.
This does not seem to be true in practice.
I use ECC on my systems and they are configured to log any ECC error. And I see ECC erros almost never. Mostly ECC errors start appearing on very old systems when something in hardware becomes bad because of the age (even if just oxidized contacts). I am not sure if I've ever seen a truly random ECC error.
What do you mean by "very old"? This study, which is the only comprehensive public data of which I am aware, says that onset of DRAM errors occurs after 10-18 months.
I've read such studies with great interest, and i prefer ECC whenever possible, but i think these don't necessarily apply to desktops, at least partially.
I think the environment in racks for nodes in whichever formfactor in racks is toxic. Be it EMF interference, power distribution issues, vibrations, and/or temperature. You don't have that in a single system at home, when it is built
in a good way, and has stable power. Or at least to a lesser
degree.
It's not quite fair to just extrapolate numbers for 256MB of RAM up to a modern system. If this was true you'd be seeing OS crashes daily (if you run hundreds of servers with no ECC you will see mysterious crashes every day, but for one server it might be once a year).
Ultimately these flips are caused by charged particles hitting the memory module (a so called 'single event upset' or SEU), and the number of charged particles hitting the modules has not increased with density (although the modules are more sensitive to SEU, it's a smaller effect).
Well it depends what you're doing, if your memory is full of hash tables and linked lists then you'll likely get a crash (say a web backend). If you're a fileserver and it's all cache then you won't.
It‘s usefull for everyone but bit errors happen far far seldom than people do expect. But you should have it just in case. You dont want e.g. a corrupt database file just because the low probability of a bitceroor happened and you have been in bad lick it was on a very critical operation.
> ...bit errors happen far far seldom than people do expect.
Until they happen more often that expected. It's something that varies based on building, temperature, etc. environmental factors. And of course on your luck with memory module lottery.
According to this paper, 8% of DIMMs and 32% of machines suffered from at least one correctable error per year. Without ECC, that's an undetected and uncorrected error. The average machine in the study had over 22,000 corrected errors per year. The paper observes that "memory errors are not rare
events". If you're running without ECC, you are quite likely to have some undetected corruption, which could range from a single erroneous bit over the lifetime of the machine all the way up to constant unexplained crashes and file or filesystem corruption. There are plenty of use cases where it doesn't matter but for workstation use you presumably care about the results.
It prevents corruption from bit flips caused by cosmic rays and other sources. More important for scientific/business purposes and at higher altitudes where there is less atmosphere to block cosmic rays.
One other reason is that ECC is not binned for super high clocks like gaming RAM (even though there is nothing technically preventing it from doing so - it is one extra chip per stick, that's basically it). The fastest you can get is like 2666, where you can readily get gaming RAM in the 3600 range and premium bins go to 4400+.
Ryzen has always been very "sensitive" to low-clocked RAM and shows some pretty good scaling as you increase frequency and tighten timings and the ECC UDIMMs on the market are just not binned to do that.
I still am impressed though, didn't know about that one. Kinda trash CAS latency but I guess that might be because it's registered (I've never seen registered that fast so I guess I don't really have a good perspective on what "good CAS latency" would be for a registered memory).
I wonder if those would run on my Haswell-E xeons. They support RDIMMs, and they are unlocked so nominally they should support higher RAM clocks too (although I've never tried it with RDIMMs, only UDIMMs).
More recently, the W-3175X (Threadripper's real competitor) supports RDIMM as well. So Threadripper actually offers less features than the competition here.
I really would like to see the Threadripper series merged with the 7002P series though. Right now there is no option that gives you both Threadripper-level clocks and large quantities of RAM, the frequency-optimized parts are still a large compromise in performance and aren't widely supported. There is no part that gets you to 4 GHZ on 64 cores with 512+ GB of RAM, despite all of these capabilities existing in their respective segments.
When you are shipping a 64C HEDT processor there is really no longer any meaningful distinction between that and a server processor. And 256GB simply is not enough RAM for a 64C processor. AMD could still upcharge on the multi-socket models, but they are drawing lines between product segments that no longer make sense now that they have pushed core counts so high.
Basically, give us a modern successor to the Intel X5670 series. It's the top of the line, you're paying $4000 for a workstation processor, you should get the whole processor and not have a bunch of disabled features.
The really funny thing is, it's not even a money thing, Epyc isn't even priced significantly higher. 7702P is $4150 at Provantage (HPE p/n P16660-B21) vs $3990 for the 3990X. The 7402P (HPE p/n P16664-B21) is actually $250 cheaper than the 3960X. AMD is no longer using the "traditional" model where workstation is cheaper than server. Workstation is now just as expensive as server. So it's not like giving you Epyc capabilities would mean AMD foregoing any money.
AMD is just drawing arbitrary lines between these product segments because they can.
> I really would like to see the Threadripper series merged with the 7002P series though.
They should've done that when they changed the socket for the latest generation. Just admit that the existence of Socket TR4 was a mistake and release the new Threadrippers on Socket SP3.
I suspect there are even some people interested in dual socket workstations with 2TB of memory that nonetheless have a 4.5GHz boost clock, because workstations often have mixed workloads. And there is no point in doing market segmentation when all the prices are the same anyway, it's just incompatibility for no reason.
Epycs should be readily overclockable. It's the same silicon as Threadripper. AMD does not, to my knowledge, restrict overclocking in server parts.
Cooling would become a big issue, though. Air cooling a 280W 3970X in a big tower with sufficient airflow to maintain ambient temperature internally is difficult. I cannot maintain max turbo on all cores.
Putting this in 1 or 2 Us in a server would likely be impossible without water cooling (requiring piping to external liquid coolers (whether radiators or chillers)). There's only so much that increasing air velocity can do in cooling.
I don't know if this is the primary thing holding back Epyc specs, but I know it will be an issue.
Using RIOT you'll get at least multi-threading, power management, a choice of network stacks, a bunch of community-supported libraries and drivers with an extensive test suite, ...
Also, you'd have a clear upgrade path, as applications written for RIOT's API will compile (almost) unchanged for all of RIOT's target hardware. Arduino becomes to slow? Change some pin defines, re-compile for a fast Cortex-M. Intrigued by RISC-V's openness? Recompile for the Hivife1 to find out it's real-world performance with your application.
