AMD Ryzen 9 5950X is faster than the Intel Core i9-12900K for mining Raptoreum

The results speak for themselves.

 

The AMD Ryzen 9 5950X is faster at mining Raptoreum than Intel's latest and greatest 12th gen Core i9-12900K.

 

System/hardware specs:

AMD:

CPU: AMD Ryzen 9 5950X (16-core, 3.4 GHz stock base clock, 4.9 GHz max boost clock, SMT enabled)

Motherboard: Asus X570 TUF Gaming Pro (WiFi)

RAM: 4x Crucial 32 GB DDR4-3200 unbuffered, non-ECC RAM CL22 (128 GB total)

CPU HSF: Noctua NH-D15 with one stock 140 mm fan, and one NF-A14 industrialPPC 3000 PWM fan

Video card: EVGA GeForce GTX 980

Hard drive: 1x HGST 1 TB SATA 6 Gbps 7200 rpm HDD

NIC: Mellanox ConnectX-4 dual port 100 Gbps 4x EDR Infiniband (MCX456A-ECAT)

NIC: Intel Gigabit CT Desktop 1 GbE NIC (Intel 82574L chipset)

Power Supply: Corsair CX750M

OS: CentOS 7.7.1908 kernel 5.14.15-1-el7.elrepo.x86_64

Intel:

CPU: Intel Core i9-12900K (16 cores (8P + 8E), 3.2 GHz/2.4 GHz base clock speed, 5.2 GHz/3.9 GHz max boost clock, HTT enabled)

Motherboard: Asus Z690 Prime-P D4

RAM: 4x Crucial 32 GB DDR4-3200 unbuffered, non-ECC RAM CL22 (128 GB total)

CPU HSF: Noctua NH-D15 with one stock 140 mm fan, and one NF-A14 industrialPPC 3000 PWM fan

Video card: EVGA GeForce GTX 660

Hard drive: 1x HGST 1 TB SATA 6 Gbps 7200 rpm HDD

NIC: Mellanox ConnectX-4 dual port 100 Gbps 4x EDR Infiniband (MCX456A-ECAT)

NIC: Intel Gigabit CT Desktop 1 GbE NIC (Intel 82574L chipset)

Power Supply: Corsair CX750M

OS: CentOS 7.7.1908 kernel 3.10.0-1127.el7.x86_64

Configuration notes:

I had about two weeks over the Christmas break 2021 to receive all of the hardware, assemble the systems, and get the systems set up and up and running. And that was quite the endeavour because with the latest and greatest hardware, the older versions of CentOS (7.7.1908) and the older kernel didn't work with all of the features and functions with this level of hardware.

As a result, I had to "jumpstart" both systems by first installing the OS using my Intel Core i7-3930K system (Asus X79 Sabertooth motherboard, 4x Crucial 8 GB DDR3-1600 unbuffered, non-ECC RAM, Mellanox MCX456A-ECAT, GTX 660) first, and then update the systems (at least in part) before I can transplant the hard drive with the OS install into their respective systems and finish setting the systems up. (I will write more about that "journey"/clusterf in another blog post here shortly because it was quite the journey to jumpstart both of these systems simultaneously, which took pretty much the full two weeks that I had.)

You will find out how and why I ended up with the respective hardware choices in that blog post.

I am using cpuminer-gr-1.2.4.1-x86_64_linux from here (https://github.com/WyvernTKC/cpuminer-gr-avx2/releases/tag/1.2.4.1).

For the Intel system, because of the existence of the combination of (P)erformance Cores and (E)fficiency Cores and HyperThreading, this resulted in more combinations that I had to test in order to find the setting that had the highest Raptoreum hash rate as reported from their benchmarking tool. Each time the CPU configuration changed, I ran a full tune again, which you might well imagine, took quite some time to do. In the cases where the efficient cores were disabled, I also tested and re-ran the full tune for both AVX2 and AVX512.

The AVX512 runs (both times I ran it, i.e. with and without HyperThreading), resulted in thermal throttling with about a 23-24 C ambient at the time.

For the AMD system, testing it was a lot simpler because it was either only SMT on or off.

Results:

The results speak for themselves.

The AMD Ryzen 9 5950X with SMT enabled produces the highest hash rate (3953.64 hashes/second). Compare that with the run where SMT was disabled, enabling SMT results in about a 10.3% increase in the hash rate performance result.

The Intel Core i9-12900K results are an interesting case. Despite the plethora of benchmarks talking about how great and how fast the latest and greatest from Intel is (and there ARE some things that said latest and greatest from Intel are great at), unfortunately, for Raptoreum mining, this is not one of them.

At best, the 5950X with SMT enabled compared to the 12900K with all 16 cores AND HyperThreading enabled puts the 5950X at about 80.9% faster in Raptoreum hash rate performance vs. the 12900K.

Comparing like-for-like thread count, whether it is 8P+8E without HyperThreading, the 16 core/16 thread of the 5950X is still approximately 64.2% faster than the 12900K. Without the efficiency cores, but turning HyperThreading back on (i.e. 8P+0E with HyperThreading), the 12900K again is bested by the 5950X by a 71.8% margin.

Unfortunately, running this in Linux meant that I didn't have or didn't know of a tool like Hardware Info 64 to be able to report power consumption figures/values. Maybe I might get around to re-running this test again in Windows, but for now, this might be helpful to those who might be interested in looking for guidance if mining Raptoreum is on your mind.

Apparently, GlusterFS No Longer Supports RDMA And You Can't Use It Across Ramdrives Anymore

Back in the day, I used to use CentOS 7.6.1810 with GlusterFS 3.7 and I was able to create ramdrives in said CentOS and then tie a bunch of ramdrives together with GlusterFS.

Apparently, that's not the case anymore and it hasn't been since Version 5.0 as RDMA was deprecated.

Bummer.

Here's why this was important (and useful):

SSDs, regardless of whether it's consumer-grade or enterprise-grade, the NAND flash memory cells/chips/modules that's used in them all have a finite number of program/erase cycles.

Therefore; as a result, ALL SSDs are consumer wear components (like brake pads on a car) where they are designed to be replaced after a few years due to said wear. (This is a point that unfortunately, I don't think that the SSD as an industry, as a whole, spends enough time focusing on because a LOT of people were and are using SSDs as a boot drive, and as a boot drive, because it has a finite number of program/erase cycles, this means that it is only a matter of time before the system will fail, but I'm going to write/rant about that some other time/day.)

But for now, the key takeaway is that SSDs have a finite number of erase/program cycles and that can cause SSDs to fail.

So, in the HPC space, where I am running simulations, I can produce a LOT of data over the course of a run, sometimes, into the PB/run territory.

Therefore; if I have a large amount of data that needs to be read and written, but I don't need to keep all of the transient data that the solver produces the course of a simulation, then I want it to be as fast as possible, but also NOT have it be a money pit where I am constantly pouring money into replacing SSDs (again, regardless of whether it's consumer grade SATA SSDs or enterprise grade U.2 NVMe SSDs).

So, this was where the idea came from - what if I were to create a bunch of ramdrives, and then tie them together somehow?

Originally GlusterFS was able to to do this with gluster version 3.7.

I would be able to create a tmpfs partition/mount point, make that a GlusterFS brick, and then create a GlusterFS volume with those bricks and then export the GlusterFS volume onto the Infiniband network as a NFSoRDMA file system.

And it worked ok for the most part.

I think that I was getting somewhere around like maybe 30 Gbps write speeds on it (for the distributed stripped volume).

Lately, I wanted to try and deploy that again, but for creating plots for the chia cryptocurrency.

Apparently, that wasn't possible/capable anymore.

And that just makes me sad because it had so much potential.

You can create the tmpfs.

Gluster will make you think that you can create the Gluster bricks and volume.

Gluster lies (which you only find out when you attempt to mount the gluster volume that it never really created the bricks (on tmpfs) to begin with).

And then Gluster-hell-breaks-loose because it thinks that the bricks are a part of a gluster volume already which locks the bricks and volume together, and nowhere in the Gluster documentation does it tell you how to dissociate a brick from a volume or vice versa.

And that's too bad that because GlusterFS had so much potential.