I just ran the benchmark in the Nicehash miner and came up with 435.9 H/s - This is with a 1700X @ 4.0 Ghz and 2933Mhz DDR4. I did have some things running in the background, so that may have influenced it.
Since you are one of the lucky ones that has a Ryzen yet, can you do done tests more?
Maybe try some other miners and report frequencies.I hope that some other miners will outperform nice hash
I installed and ran the latest MinerGate software, the results are below. Compared to the results from Nicehash it would appear that MinerGate isn't utilizing Ryzen very well. The one exception being AEON with a MUCH higher hashrate, but it crashed the PC within 30 seconds.
All with 15 Cores (16 cores made no difference other than making the system laggy)
AEON - ~560 H/s - Not Stable, crashes computer.
BCN - ~160 H/s
DSH - ~160 H/s
ETC - ~887 kH/s
ETH - ~887 kH/s
FCN - ~160 H/s
INF8 - ~160 H/s
MCN - ~160 H/s
QCN - ~160 H/s
XDN - ~160 H/s
XMR - ~160 H/s
XMR with 15 cores - ~160 H/s @ 63 watts
XMR with only 8 Cores - ~340 H/s @ 65 watts
XMR with only 4 Cores - ~195 H/s @ 46 watts
Clearly something if off with the number of cores/threads not being used properly. The XMR results at 8 Cores, 340 H/s @ only 65 watts isn't too bad. With more optimized miners I could see the cheaper R5 series being an option to at least consider for mining down the road when motherboards are more available etc....
This was with a R7 1700X 4.0 Ghz @ 1.35 volts
If you have a different CPU miner that you would like me to test let me know and I might be able to benchmark it.
![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
You DO realise that the R7 1700X is a *8 core* CPU, not a 16 core?
Threads via hyperthreading are NOT additional cores, they are more about being able to split usage on a core to be able to do 2 low-utilization things at once on a core.
A lot of software is MISidentifying the Ryzen 1700/1700X/1800X as 16 CORE cpus, because they mark the first time AMD has put Hyperthreading into a CPU.
Of course I know it's an 8 core 16 thread cpu. I was using the specific terminology in the program so that others can observe, compare, and replicate it if they have a R7 CPU themselves.
Plus the Ryzen 8 cores use two 8 mb L3 cache's and if data is swapped from one L3 to the other it slows things down quite a bit, so I appreciate the info because AMD has a tendency to run unusual cache architecture on some of their cpu's and the more test data that is out the better.
Example on my FX 8320 mining monero:
AMD FX 8320 at 4.4 GHz VERY unusual results! LOL
Running XMR-STAK-CPU: only max listed, after a few minutes it would settle on a slightly lower hash rate.
8 threads= 305 H/s
7 threads= 435 H/s
6 threads= 329 H/s
5 threads= 324 H/s
4 threads= 219 H/s
3 threads= 217 H/s
2 threads= 111 H/s
1 thread = 107 H/s
The 8 core FX cpu's have a 8MB L3 cache AND each module pair has 2MB of L2 cache so the cpu has a total of 16 MB of cache.
So you would think that 8 threads would be ideal for monero, its not because of the cpu module's and 4 threads are not the fastest but they are the only down a little from the max seen with 7 threads and run much cooler and use a bit less wattage.
So look at the results above, 1 thread is 107 H/s and then 2 threads only hash 4 H/s more, then a BIG jump in the hash rate running 3 threads, then another tiny jump running 4 and on and on until 7 threads.
So running 1 thread per module on a FX cpu is the most efficient thing to do.
Running XMR-STAK-CPU on only 1 thread per module and there still is unusual results.
EDIT: I just remembered that I had lowered the speed to 4.0 GH/z before I did the testing below so at 4.4 GH/z it would hash higher.
If I set the affinity to even numbered threads 0,2,4,6 it hashes at ~339 H/s.
If I change it to use threads 1,3,5,7 it hashes at ~385 H/s.
So testing and sharing data can help everyone even tho it may not interest everyone.
I don't know if anybody else are mining monero on a fx cpu but if they are what I have found will help them.
EDIT: My theory on why FX cpu's mining monero is fastest using one thread per module is because of that 2mb L2 cache per module is that cryptonyte is running in L1 and L2 and if you run more than one thread per module the two threads are forced to share the single L2 and then have to swap to L3 therefore there is almost no speed improvement.