AMD Ryzen 3 1200 & Ryzen 3 1300X Linux Performance

[Michael]

I too was disappointed to see no compilation benchmarks as I was thinking of getting a cheap ryzen to offload some compilation to via distcc.
And also, why the sudden drop of CPUs in the benchmarks?

There is a timed kernel build in this article.

I think what would be great would be a fixed set of default benchmarks that you run on every single cpu you get your hands on and create a single regularly updated overview/comparison of all those CPUs

Time/resources...

[Michael]

I might be blind but we seem to miss kernel compilation now that we have the lower end processors it would be nice for a comparison

Check the article, timed kernel compilation is in there.

[plasma5]

Michael, i dont know if your MSI X370 board uses the same nuvoton NCT6795D as my MSI B350 Tomahawk, but there is a workaround to get temperature readings with that. I use that since i got my board.

I just need to load the module "nct6775" with the "options nct6775 force_id=0xd120" to make readout work. The labels of the sensors are a bit wrong but everything is there. On the attached screenshot i labeled a few of sensors output with red text. I hope this helps you reading out temperatures.

http://i.imgur.com/oZRyg3m.jpg

Edit: in11 is the VSoC reading. I labeled it wrong

[Snaipersky]

Ryzen has half the FMA throughput per core and clock cycle compared to Intel's current lineup. But that doesn't explain the Himeno results. Even the Pentium G4400, which doesn't have AVX and therefore no FMA, destroys Ryzen in that test. And Ryzen does well in some other FPU-heavy workloads.

Still no word from AMD on the compilation segfaults? Guess I'll keep my Phenom II for another year or two then...

Just how the hell do they plan on selling their Threadripper and Epyc products when they aren't even capable of what is an everyday task for some potential customers?

The segfaults are from pushing unstable overclocks. AMD chips don't hard lock when they hit an issue, so the system will run barring a kernel panic. Hammering all overclocked cores with compilation can lead to instability issues, which manifest as segfaults under that workload.
Source: several posters here as well as my own 1700. Segfaults at 3.825 GHz, but none under repeated gentoo installs at 3.8 GHz.

[stormcrow]

The segfaults are from pushing unstable overclocks. AMD chips don't hard lock when they hit an issue, so the system will run barring a kernel panic. Hammering all overclocked cores with compilation can lead to instability issues, which manifest as segfaults under that workload.
Source: several posters here as well as my own 1700. Segfaults at 3.825 GHz, but none under repeated gentoo installs at 3.8 GHz.

I'm sorry to break it to you but overclocking or not has no bearing on the segfaults, which you'd see if you'd read through the two forum discussions I'd linked to in my earlier reply to the article. Indeed, my own system is NOT overclocked with default firmware settings and I've been able to reproduce segfaults on both Ubuntu 17.04 and Fedora 26. If you read through the FreeBSD discussion on the problem you'd see it's reproduced on FreeBSD as well and it doesn't matter on overclocking there either. In fact, while it's possible to make things "more stable" no one has managed to completely work around the problem as sometimes even with extensive threading load the system can go for over 24 hours and appear stable then segfault. Windows users utilizing the Linux subsystem have seen the same thing. People using VMs on Windows still seem to see the segfault problem, only it takes longer to happen. I've seen one claim where the user was transcoding video and experienced crashes on a Ryzen system. I don't remember where that particular case was recorded.

People with far more skill and experience than I have have been unable to find full workarounds in either firmware settings or kernel patches. The systems inevitably fail under heavy threaded loads. Disabling OPcache, SMT, ASLR and voltage manipulations only seem to extend the time before the bug is encountered, a crash is encountered, and the system grows unstable till a power cycle.

It appears that AMD either rushed the release without full QA, or they neglected to test anything beyond typical desktop scenarios during the engineering cycle. No, heavy compiling loads aren't typical desktops. Most people browse the web, e'mail, and play games. These don't stress the CPU like things like video transcoding, video editing, and continuous days compiling software do. This particular bug can happen anywhere from minutes to taking days to manifest.

[soulsource]

The segfaults are from pushing unstable overclocks. AMD chips don't hard lock when they hit an issue, so the system will run barring a kernel panic. Hammering all overclocked cores with compilation can lead to instability issues, which manifest as segfaults under that workload.
Source: several posters here as well as my own 1700. Segfaults at 3.825 GHz, but none under repeated gentoo installs at 3.8 GHz.

I have tested three computers with Ryzens, one of them uses memory overclocking, the other two are at default settings (no overclock). All three of them segfault during compilation sooner or later.

Edit: A few details on what I tested: I used SystemRescueCD, and started a Gentoo install to a ramdrive. Then I kept re-emerging mesa until I saw a segfault. Took about 5 hours of continous mesa recompiles on average, but also the machines without any overclocking crashed at some point.

[Mike Frett]

Well goodness...I guess I found a replacement for my aging FX4100. =)

[faph]

Michael
Can you get an A12-9800 APU?

I know it's old news, but they are now finally available for end-customers. And more importantly this is the latest and most recent APU from AMD and will be so for a long time (until Raven Ridge comes out somewhere in 2018).

[Michael]

Michael
Can you get an A12-9800 APU?

I know it's old news, but they are now finally available for end-customers. And more importantly this is the latest and most recent APU from AMD and will be so for a long time (until Raven Ridge comes out somewhere in 2018).

They haven't offered me any review samples and I have no extra funds available, so probably not.

[vein]

The benchmarks in this case happen to be irrelevant to the conclusion. I would very strongly suggest that people do not buy any Ryzen CPUs whether it's a new release or previously released till AMD acknowledges and fixes some rather serious flaws with the CPU architecture regarding long term stability and segfaulting while compiling that eventually causes a complete system crash. A couple of hours of compiling software isn't enough to catch the bug. The bug shows up in Windows, Linux, and FreeBSD and it's been determined to not be a software bug. There is no currently reliable workaround and AMD has been mute on the issue.

https://community.amd.com/thread/215...5&tstart=0

https://bugs.freebsd.org/bugzilla/sh....cgi?id=219399

I have a Ryzen 5 1600 on an MSI motherboard and I can confirm that my CPU will do the same thing sooner or later with simply building LLVM/Clang with a full thread load -- in my case I was using make -j 24 and crashed with a segfault with a little less than 90 minutes the first time it happened on Ubuntu 17.04.

If you want a box to do compiling loads on get an Intel system, at least till AMD actually fixes this major screw up in QA.

I started reading the thread on and community page and I can see the problems of trying to get to the bottom of it. Since yesterday there are people claiming that they have no problems with the kernel 4.11 but they do in 4.12... suggesting it would be a kernel problem and the latest post seems to invalidate the kill-ryzen script as a method to reproduce the problem...

This must be a nightmare to sort out for amd people...