it took a while to finally code it, but now its there: the first Slean based miner for Cuckatoo-31 supporting it on 4G and 8G cards. You want to learn how the trimmer works? Then watch my presentation at Grin Amsterdam meetup, starting approx 1:14:20: Grin Amsterdam 2019 - YouTube
Cycle finding is completely done on GPU - the CPU is barely used (only on Nvidia there is one core used by the CPU due to the OpenCL back end)
Fidelity should converge to 1 on both solvers. The miner displays fidelity every 5 minutes (configurable) and in its API. Fidelity is calculated for 14 and 42 cycles from startup of the miner.
Fee is 1% as for all other coins in the miner
Miner can be configured in the way it displays stats, api and so on. See the manual
Estimated Performance (Stock clocks)
Card
8 G Code
4 G Code
RX 560
-
0.14 g/s
RX 570
0.45 g/s
0.26 g/s
RX 580
0.49 g/s
0.28 g/s
Vega 56
…
-
Vega 64
0.9 g/s
-
Radeon VII
1.1 g/s
-
GTX 1060 6G
-
0.27 g/s
GTX 1070
…
…
GTX 1080
0.75 g /s
-
RTX 2060
-
0.29 g/s
RTX 2070
…
-
RTX 2080
…
-
Minus sign = Will not be used or is not compatible
… = Compatible but value not yet known
Have fun mining - and appreciate reports of stability, hash rates, problems … what ever you want to tell me
As far as Tromp said, it doesn’t scale well to have 2 instances accessing the memory at same time, but have you tried having one instance accessing double the memory? (Since the bottleneck is memory, it might help)
@josevora Yes, I will likely do a 16G variant of the algorithm for Radeon VII and the 16G RX 570.
As you pointed out multiple instances will rather slow it down, so it will use more memory per instance. My estimate - from where I had to make time-memory trade offs - is that one can gain ~30% hash rate by using 16 GByte of GPU memory instead of 8G.
@tromp Thank you very much Well I did not measure the CPU run time directly. I think for a single GPU the actual time on CPU can be counted as 0, because one usually would try doing that in an extra thread and interleave the execution with the GPU already doing new work. That said with many GPUs in a bigger mining rig a weak 2 core CPU may reach its limits, so for that case the computation on GPU is beneficial. The penalty for doing so is approx 3% on the 8G and 2% on the 4G code. That was worth doing it in my opinion
Yes, thats wired xD
Can you tell me on what pool you see this? It may be that there is a simple explanation for this.
Background: The miner sends the share with “id” = 4+gpuIndex to the pool and expects that this id is also used for the return message to look up when the share was send and to assign the accepted or rejected share to the right GPU in my stats module.
Unfortunately that only works for pools acting so. Yesterday when I did NiceHash support I got back stuff like “GPU 4294967292: share accepted (nan ms)” because the Nicehash pool did send me always “0” as id for accepted shares ^^
So this may be just my grin stratum back end speaking a different dialect then the pool your connected to. But do not worry: the most important is the “accepted” and as long as pool roughly agrees in hash rate with the miner your perfectly fine
OK, I’m using a variant of Grin-Pool.org… and it’s been 6h and I have 2% rejects, but hashrate is 39% higher on the pool! case to say LOL?
14 Cycle Fidelity is 0.99
42 Cycle Fidelity is 1.01
so everything ok…
Well - you got multiple layers of luck between running a graph and whats recorded at the pool - seems many of the solutions were below the pools diff barrier then
Fidelity close to 1 seems healthy
If you like you can pm me the data of your pool (address), then I can run a small test on it to see what it sends and why the miner miner misinterprets it.
Yes, on Linux and Win 7 that will likely work (Windows 10 unfortunately not), but I have no idea about the performance. Most likely ~0.1 g/s on the 4G kernel.
Unfortunately I am no longer able to update the first post here.
But want you to know that lolMiner 0.8.5 was just released including Cucarood-29 support (–coin GRIN-AD29) for the PoW fork tomorrow.
You can find it here:
Supported Cards are AMDs with 4 and 8Gbyte.
Performance is not widely tested yet, but got 2.35 g/s on a 580 4G and 2.8 on a 580 8G. So most Polaris will range from 2.2 to 2.8 I guess.
For Vega I observed that the miner is a little quicker in Rocm then on the normal drivers - currently investigating why.