Finally we have some new hardware worth writing of – and also spending money on.
I have been using an AMD Ryzen 7 1700X based build for some time now and so far I am really liking it, the CPU is marvelous considering the pricetag and felt like a worthwhile upgrade from the Xeon E3-1241v3 I was using before; it is basically twice the cores clocked at pretty much the same speed. Awesome.
There are a couple of points worth spending some words on tho.
.:. Q: do I really need Samsung B-DIE based RAM?
.:. A: no, not really
The major complaint against Ryzen is its supposedly poor memory support and poor memory overclocking capabilities.
In the last 4 months everyone and their mother became memory experts, said experts started pushing the idea that if you don’t shell out ~200 EUR for a mere 2×8 GB Single Side (or Rank) Samsung B-DIE kit you will never reach anything north of 2133/2400 MHz memory clock.
I suppose I like to prove people wrong (and also don’t like trowing money away), so when I built my new Ryzen machine I went on an picked up the lowest possible bin of 2×16 GB Crucial RAM rated for 2133 MHz CAS 15 with Micron C9BGN ICs in Double Side configuration (part number: CT16G4DFD8213.C16FBR).
They can be had for nearly for the same price of a decent Samsung B-DIE based 2×8 GB kit, are still able to run at 3200 MHz stable but with two times the capacity.
The important settings used to boot at such memory clock are VSOC 1.0 volt, VDIMM 1.4 volt, DRAM PROC ODT 60 Ohm and main memory timings 16-20-14-14-32 1T; they also liked the three tRFC settings respectively at 512/320/200.
But don’t get yourself fooled into thinking that Infinity Fabric speed or even less DRAM clock frequency and timings make a huge difference.
To prove my point I did some testing with stream, which is the industry standard memory bandwidth benchmark for Linux; needless to say results are quite interestings:
clock | timings | Copy | Scale | Add | Triad 2666 | 14-16-14-14-32 | 33265.5 | 22413.1 | 25020 | 24903.5 2933 | 16-18-14-14-32 | 36259 | 25626.7 | 28483.9 | 28445.8 3200 | 16-20-14-14-32 | 38075.3 | 26959.1 | 30132.2 | 30048.5
Stream shows how the impact of memory timings on memory bandwidth is pretty much abysmal, even if CAS 14 would get a 0.5 to 1 GB/s memory bandwidth improvement it would not be worth paying double the price (~400 EUR) for a 2×16 GB Samsung B-DIE based kit.
Stream is compiled the phoronix way:
#!/bin/sh CFLAGS=“$CFLAGS -O3 -march=native” gcc stream.c -DSTREAM_ARRAY_SIZE=100000000 -DNTIMES=100 $CFLAGS -fopenmp -o stream-bin echo \$? > ~/install-exit-status
Famous AMD’s Blender synthetic benchmark results are even more interesting because it shows how not important memory frequency, timings and also Infinity Fabric frequency are:
clock | timings | run0 | run1 | run2 | run3 | run4 2666 | 14-16-14-14-32 | 22.57 | 21.93 | 21.93 | 21.90 | 21.92 2933 | 16-18-14-14-32 | 22.49 | 21.78 | 21.97 | 21.90 | 21.96 3200 | 16-20-14-14-32 | 22.49 | 21.66 | 21.87 | 21.85 | 21.85
Fiddling with memory settings only gather some results in probably poorly coded game benchmarks, in every other scenario the gain is pretty much non existent.
That’s a tough one.
I personally am of the opinion that each and every AM4 motherboard sucks.
At first we had BIOS issues, most of those are gone now, but this can be said only for top of the line motherboards, everything else still sucks to some degree.
There is probably not a single board that does not feel like cheap crap, for example: CPU PWM run hot as hell even on 200+ EUR boards, when overclocking having a fan blowing fresh air onto them is a necessity.
I bought a Gigabyte Aorus X370 K7 because I felt that was the best option, I still need a fan on the CPU PWM but BIOS support is great with beta being posted by Gigabyte on their own forum.
All in all I think I can say I like the board
Asus Crosshair and a couple of Asrock boards are probably the only ones with decent PWM (or decent heatsink) but they still miss an even more important feature: dual BIOS.
That wouldn’t be a critical features if it wasn’t that AM4 motherboards like to kill themselves for some still unknown reason.
.:. Linux support
Linux support is decent, although we are still waiting for AMD to publicly release the paper containing information on how to probe CPU temperature sensors.
Another thing that currently does not work on the X370 K7 is the front panel audio, but I personally don’t care much since I don’t really use it.
Everything else works fine provided that a newish kernel is used (>= 4.11).
Some people report having issues when compiling software, I never had any problem tho; more info can be found here: Gentoo Linux forum
.:. Linux, temperatures and voltage readings
The de facto standard for temperature and voltages monitoring software on Linux is lm_sensors, while we are still missing the needed information to code a kernel module to probe directly cores temperature, it87 modules added support for many AM4 motherboard’s IO chip; this can be used as a temporary workaround to check what I assume is the CPU package temperature.
As of today it87 module included in Fedora 25 is not up to date, the only solution is to compile from source.
$ dnf install kernel-devel lm_sensors $ git clone https://github.com/groeck/it87.git $ cd it87 $ make && make install $ sensors-detect
Edit /etc/sysconfig/lm_sensors to make it load it87 modules at boot:
I/O chip ID also needs to be forced, in my case the correct one is 0x8628:
options it87 force_id=0x8628
Reboot or manually load it87 module via modprobe command.
.:. Putting it all together
Since Linux is still missing a decent hardware monitoring software I hacked around a small Python script, it essentially gathers numerous system information and presents them to the user in a simple command line interface.
I figure this tool deserves its own page: AMD Ryzen-info