I used the generic YAM version as none of the others seemed to be the correct one for the Richland AMD CPU.
I do have the cfg in the same folder.
I can't even get it to run at all it just opens and closes. I have no idea what is messed up here. I don't have any issues running any other command line mining software.
This one has me stumped.
I have been perusing the other thread that was mentioned to try and see if I can figure out what I am doing wrong as well.
Frustrating as I know this would boost my performance over mc2.
I cannot even get it to run in finetune mode either.
I'll leave this one to yvg1900 as I don't really know which miner should be downloaded for AMD (generic does sound like the logical choice though).
Also, are you running it from the command line or a batch file?
You could try to see what the error is either by adding "pause" to the batch file or simply running it from the command line and checking the printouts.
Again, Richland is NOT a microarchitecture name, it is core (platform) name. Your choice shall be bdver2 or btver2 (those for Bulldozer and Bobcat) versions. Richland cores seem to be all based on Piledriver microarchitecture, which supports AVX instructions and shall let you some more squeezing of CPU perf.
Also it supports AES-NI, so aesni=on shall be working.
What is important for these CPUs is to start with minimum memory setup (m=1024) and use finetuning to detect proper AV. Besides of commens made by me in AV description shall be valid for most cases, I strongly recommend relying on finetuning in determining proper AV for your system. After you are done with m=1024, it makes sense that you try more RAM, but after some point it may cause some perf degradation as mem bandwidth will become a bottleneck, so there is a balance.
Important note is setting up affinity even for single-CPU machines if you are not running as many threads as you have logical CPUs. Here is an excertp from readme.txt of upcoming version of yam that will be released in few days:
* Thread Affinity and Running less-then-cpu-count threads
If you are planing to run yam with number of threads less than your CPU count (for example, running 4 threads on 4-core CPU with HT enabled),
in some cases it is beneficial to manually specify thread affinity to prevent occasional core-sharing and cross-core thread migration. You may
want to ensure that number of CPUs enabled in your affinity mask matches number of threads you are using for mining, and that you have minimized core
sharing. To complete example above, logical CPUs (threads) 0 and 1 can be assigned to physical core 0, threads 2 and 3 to physical core 1, etc.
In this case when running 4 threads it makes perfect sense to set affinity mask such a way that only logical CPUs 0, 2, 4 and 6 left enabled for mining,
and guarantee than core sharing may not happen.
yvg1900