Search content
Sort by

Showing 3 of 3 results by ruark
Post
Topic
Board Mining (Altcoins)
Re: SRBMiner Cryptonight AMD GPU Miner V1.8.8 - native algo switching
by
ruark
on 15/05/2019, 05:18:01 UTC
livada, could you share how you managed to fix the eio.dll issue?
I'm unable to send you a private message, as my account has a newbie status.

Thanks
Post
Topic
Board Mining (Altcoins)
Re: SRBMiner Cryptonight AMD GPU Miner V1.8.8 - native algo switching
by
ruark
on 14/05/2019, 10:27:54 UTC
Hello doktor,

I have the same problem with EIO.dll as livada on one of my rigs, the other rigs are working fine.

When I stop the miner, disable the auto run of it, and restart the rig I'm still unable to run WinAMDTweak.

Please advise if I can perform any testing/debug steps in order to assist you to debug the issue.

Regards
Post
Topic
Board Mining (Altcoins)
Re: SRBMiner Cryptonight AMD GPU Miner V1.5.5.1
by
ruark
on 26/05/2018, 15:50:30 UTC
Hello Doc,

Thank you for the wonderful miner.

I've upgraded two of my Vega64 rigs from 8 to 10 cards per rig, and had to ditch the blockchain driver in order to support 10 cards.
With the new driver xmr-stak is not performing so well as with the blockchain driver, and I made a test between xmr-stak, cast-xmr and srb.

The results are excellent in favor of the SRB:

10 x Vega64 1408/950 GPU & 1100/950 MEM:

srb miner - 20100 h/s - 0.85% fee = 19930 total  
xmr-stak - 19454 h/s - 0% fee (I'm compiling my version with the dev fee removed, as 2% default is a bit high) = 19454 total
cast-xmr - 19900 h/s - 1.5% fee = 19600 total

Also from the 3 miners only SRB continued to mine with 1 card crashed (with 9 of 10 cards), and the bus ID reorder made it very easily to find which card is this and to tune its mem down a bit.

So I want to thank you and congratulate you for the excellent miner. You also have a very reasonable dev fee so I'm planning to deploy the miner on all of my rigs.

I have the following feature request, that I will be very happy, if it could be addressed.
Is it possible to add a pool priority (xmr stak has this option) so if the primary pool fails and the miner switches to the secondary pool, the miner to start to mine to the primary pool again when it's up again?
Easy walkaround could be if that's hard to implement, to enable a scheduled pool reload  (at this moment at the reload, the miner connects to the primary pool if it's not connected).

Regards