Topic: SRBMiner-MULTI GPU & CPU Miner 0.9.4 - page 30. (Read 45082 times)

New video tutorial:

How to change memory timings in real time

you should manually set difficulty much higher ( --password d=5 ) for example

---------------------
Pool:
Workers: 2
NAME   DIFF   HASHRATE (NOW/AVG)
018   0.128   474.75/354.28 MH/s
060   0.128   392.19/433.56 MH/s
--------------------------------------------
Real:
018 RIG - 2 cards RX470-580 x ~650Mh = ~1.3Gh
060 RIG - 4 cards RX470-580 x ~650Mh = ~2.6Gh

Pool = 787Mh
Real = 3.9Gh

Hi
2021-07-24 20:42:55] GPU1[t0] result rejected [job not found] [circcash][0]
[2021-07-24 20:42:55] GPU5[t0] result rejected [job not found] [circcash][0]
[2021-07-24 20:42:55] GPU0[t0] result rejected [job not found] [circcash][0]
[2021-07-24 20:42:55] GPU4[t0] result rejected [job not found] [circcash][0]
[2021-07-24 20:42:55] GPU4[t0] result rejected [job not found] [circcash][0]
[2021-07-24 20:42:55] GPU1[t0] result rejected [job not found] [circcash][0]
[2021-07-24 20:42:55] GPU8[t0] result rejected [job not found] [circcash][0]
[2021-07-24 20:42:55] GPU7[t0] result rejected [job not found] [circcash][0]
[2021-07-24 20:42:55] GPU7[t0] result rejected [job not found] [circcash][0]
[2021-07-24 20:42:55] GPU8[t0] result rejected [job not found] [circcash][0]
[2021-07-24 20:42:55] GPU6[t0] result rejected [job not found] [circcash][0]
[2021-07-24 20:42:55] GPU7[t0] result rejected [job not found] [circcash][0]
[2021-07-24 20:42:55] Socket error : 104 [circcash]
[2021-07-24 20:42:55] Reconnecting to stratum-ru.rplant.xyz:17050 in 3 seconds [circcash]
[2021-07-24 20:42:58] Pool unexpectedly closed the connection [circcash]
[2021-07-24 20:42:58] Reconnecting to stratum-ru.rplant.xyz:17050 in 3 seconds [circcash]

I think this for a rig with a large number of GPUs works fine for 4 cards for sure.

V0.7.8
+ Added algorithm 'circcash' for GPU mining, fee 0.85%
+ Performance increase on 'heavyhash' algorithm on GPU's (~15-25%)
+ Performance increase on 'verushash' algorithm on CPU's supporting SSE4.2 and AES (~4%)
+ Added parameter '--gpu-manual-tuning' for real time editing of memory timings (check Help\Gpu_Manual_Tuning.txt)
+ Added parameter '--log-file-mode' (check Help\Cmd_Common_Parameters.txt)
+ Fixed auto setup on Ethash algorithm for Navi/Navi2 cards that broke in previous version
+ Removed devfee for 'randomwow' algorithm
+ Removed devfee for 'bl2bsha3' algorithm
+ Removed devfee for 'eaglesong' algorithm
+ Removed devfee for 'k12' algorithm
+ Removed devfee for 'kadena' algorithm
+ Removed devfee for 'minotaur' algorithm
+ Minor bug fixes

You can now set/change memory timings in real time! For details refer to Help\Gpu_Manual_Tuning.txt

Have you tried switching to the other compute drivers? I have no idea about RaveOS but on Hive there is a specific driver version the kicks it back up again.

Hi,
I have some issues when using for xhv coin under linux ( RaveOS) comparing with windows.
Under linux my baffin cards like RX 550 2Gb, RX 560 2Gb works only 300 h/s. But it will get 500 h/s more in windows, with same core, mem, and voltage.
Let me know the problem and how to solve it.
Thank you.

Hi,
whats your ETH hashrate/wattage on RX6700xt/6800/6800xt?

Use gpu's 0,1,2

is there a config to select a gpu to mine but not all? example: only 1 of 2 gpus will mine.

Pretty much to keep it from being easily optimized and maintain the reasonably large instruction set. That goes a long way towards making certain types of development a lot harder to do.

You are from the Raptoreum team right? I must ask why not making all CN algos use same scratchpad size? That way there would be no such big HR fluctuations + the num of used cpu cache could be known and so num of worker threads could be chosen much more efficiently. Right now the other miner choses to use ALL threads which might be efficient only when mining the small scratchpad CN algos, but not when doing the 2MB ones.
This is why my miner doesnt use all the threads but let's say it selects num of threads based on an avg. of all scratchpad sizes and available L3, L2 caches.
There is no efficient way of doing this because of the different memory requirements for CN algos..

Not overly with threads other than 1 machine running 40 of 48 threads which cost the expected 8-10%. With intensity I saw no gains just increased heat.

I didn't do 4-way hashes and avx2 for all those algorithms, also no cn tuning config or what it's called over there, so probably that's what it is  
a quick question : did you play with --cpu-threads and --cpu-threads-intensity ?

AMD 3900 3990 5900 5950 5800 5700 3600 3200

Intel E5 2680 v2 v3 v4 v5 2678 v3

All consistently 25-60% slower than with https://github.com/WyvernTKC/cpuminer-gr-avx2/releases/tag/1.1.7

It depends from CPU. on which one have you tested?

Any chance of some tweaking on GR? It's currently more than a bit behind.

Ok thats fine no problem I just wondered as SRBMiner-MULTI is just still mentioned in their docs.
Means I just have to see if I can get it to work with mm,js/mm.exe, I hate to switch miner as
SRBMiner-MULTI works great for me on either xmrpool or supportxmr.

In any case a thumbs up from me 

i abandoned compatibility with monero ocean and that kind of algo switching along the way.

Any idea what the best way is to setup srbminer-multi with moneroocean.stream and algo switching?