Post
Topic
Board Mining (Altcoins)
Re: SILENTARMY v3: now a full miner! multi-GPU, Stratum support (Linux only)
by
mrb
on 04/11/2016, 18:25:12 UTC
Should I install Ubuntu 16.04 dektop or the other one with black screen ?

The desktop edition works fine. Personally I install the server edition ("black screen") because my system is headless and I admin it over SSH. The README.md file documents exactly the steps to install the drivers and SDK.


That out of the way, I know you need to create a file basically lika a config.txt equivalent for it to trigger this.  I have tried and just don't know how.  It takes me back when I was learning DOS and Qbasic, omg 25 years ago.  I guess my question is how do you get this miner to run?  I have created the file and #!/bin/bash but after that I just don't know what to put in it.  Thanks and I apologize for the ignorance.

You can just put this in the bash script:

Code:
#!/bin/bash
/path-to-the-silentarmy-directory/silentarmy -c stratum+tcp://your.pool.here:1234 -u your-address-here -p password

And to fix your "make" issue, run "sudo apt-get install build-essential libsodium-dev" as described in README.md. This will install "make" and other required dependencies.


I think the vast majority (>95%) of miners have cards with at least 2GB RAM.  The kernel I designed (and only implemented a bit of prototype code) is quite similar to yours, but only supporting 2^20 sorting bins (or rows).  My design has 2 tables like yours (I consider it to be like double-buffering), but I hadn't thought of dividing the saved indexes between the two tables so they could fit in 28 bytes and leaving 4 bytes for the collision counter.
I did see the change of OVERHEAD from 13 to 9, but I hadn't noticed the counter reset at the end of the round.
https://github.com/mbevand/silentarmy/blob/master/input.cl#L568

Since you say you have to support options other than 2^20 rows, I'll probably fork your code and optimize it for 2^20.  I think it should give another 10% performance boost.  I also think even more performance can be attained by optimizing for the 256-byte stride size of the Polaris, Tonga, and Pitcairn GPUs.  Despite your comment in the code about odd values of OVERHEAD being best  for avoiding channel conflicts, I had found 12 was faster than 13 in my testing on Tonga and Pitcairn.

I do not see any performance degradations caused by my code supporting other NR_ROWS_LOG values (I have tried implementing only 20). Because all the non-20 cases are #ifdef'd out of the code. Plus the OpenCL compiler is very good at removing loops such as the for-loop in equihash_round() that becomes useless with 20.

Tweaking OVERHEAD might gain you a few % here and there. I must say I chose the OVERHEAD value for best performance on R9 Nano and RX 480, but yes I expect the ideal value to be slightly different on different GPUs. If you find a much better value on some GPUs, let me know Smiley


I am using ubuntu 14.04 on my 4GPU rig (3x radeon 280x and 1 270)
when I silenarmy it stucks, so I had to add config option to use only 1 instance. Now its running fine and it makes total 67 sols. I do not know if that is good.
When I look at gpu utilisation on atitweak, O see utilization is low. why?
[...]

This sounds like a hardware issue. Check your risers, overclocking, overheating, power supply, etc. And atitweak is wrong about utilization being zero. 67 sol/s is what I would expect with your GPUs and --instance 1.


Hi, using ubuntu 14.04 + amd gpu pro 16.30 on 6-card-rig (stable on ethereum + claymore) rig I have 0.0 (zero) sols after few minutes of mining. Hardware is Asrock H97 anniversary + RX470 refs.
[...]
If stop and restart miner threads could not been initialized, so I need to reboot. I am using zec.nanopool.org
Here is dmesg output: http://pastebin.com/fg5ZEiai

Ditto: hardware issues.