Are you still prioritizing nvidia support over windows support?
Yes, because supporting Nvidia is much less work than Windows. ETA maybe in a few days. Anyway, we are getting off-topic in this CCminer thread. SILENTARMY discussion should be held there. |
|
|
|
@mrb Keep getting this error with your miner: Task exception was never retrieved
future: <Task finished coro=<Silentarmy.show_stats() done, defined at ./silentarmy:183> exception=KeyError('1.0',)>
Traceback (most recent call last):
File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
result = coro.send(None)
File "./silentarmy", line 228, in show_stats
rate_gpus = sorted(gpus(last_sols, last_times, period_gpu))
File "./silentarmy", line 193, in gpus
sols[devid] = last_sols[0][devid] - last_sols[idx][devid]
KeyError: '1.0' Get the latest github version. These errors were fixed recently: https://github.com/mbevand/silentarmy/commit/c6851571e159e9aa952c76dbeb5bca9890a51e30 |
|
|
|
Connecting to eu1-zcash.flypool.org:3333
Stratum server sent us the first job
Mining on 5 devices
Stratum: invalid msg from server: type object 'bytes' has no attribute 'hex': {'method': 'mining.notify', 'id': 0, 'params': ['9357f5ac3b7cde47996f', '04000000', '152e2ebe2f52e46c9a88d2b9759e30c321e34891ef49aa7bafab930500000000', 'e16d1c6a08bd3b5e226906ab9cd5f62d25fc916e79b913d70968fd88b0e06e85', '0000000000000000000000000000000000000000000000000000000000000000', '9aa21d58', '8e1e031d', True]}
Am I missing something here???
"bytes.hex" was a Python 3.5-only feature. I fixed it: https://github.com/mbevand/silentarmy/commit/506cadc21162177b06de9528bb444166fb337459 Make sure you get the latest github version of SILENTARMY. |
|
|
|
@mrb, could you please work on some small patches to improve compatibility with our NiceHash.com stratum servers? First of all, you should properly implement client.reconnect ( https://slushpool.com/help/#!/manual/stratum-protocol) [...] And secondly, it would be excellent if you could add a small stratum extension, called extranonce.subscribe. Please see here for the instructions (really easy): https://www.nicehash.com/?p=software#devsYes I saw your 2 github issues that you filed. I will work on them eventually. I don't have much time, so I am happy to review pull requests. I have a question for you: why does 1 of your 2 servers behind equihash.eu.nicehash.com returns a 17 bytes nonce (37.58.117.214) and the other a 5 bytes nonce (5.153.50.217)? Only the latter is supported by silentarmy. |
|
|
|
Hey all, I committed nerdralph's suggestion: https://github.com/mbevand/silentarmy/commit/a33a9065528599f5821c4ca02c5f63fa167e9afd You can enable the optimization by editing param.h, setting OPTIM_FOR_FGLRX to 1, and recompliing. My test machine with an R9 Nano can dual boot into either: * Ubuntu 14.04 64-bit with the Ubuntu-packaged fglrx driver 2:15.201-0ubuntu0.14.04.1 * Ubuntu 16.04 64-bit with AMD's official amdpro-gpu driver 16.40 Performance results in sol/s, running 1 instance of "sa-solver --nonces 100": - 26.8 / 27.7 (fglrx / amdgpu-pro) OPTIM_FOR_FGLRX=0 (default)
- 28.3 / 23.4 (fglrx / amdgpu-pro) OPTIM_FOR_FGLRX=1
It seems to improve performance by +5% with fglrx, but degrade performance by -15% with amdpro-gpu. But I just found out this test is not really conclusive. With the amdgpu-pro driver, if instead of benchmarking with sa-solver I mine with silentarmy for 5+ minutes, the -15% perf degradation disappears and the sol/s slowly converge to a level identical to compiling with OPTIM_FOR_FGLRX=0. Therefore I would be interested if more people with different types of hardware and different drivers could report their results... |
|
|
|
|
Thanks to all those who explained why they prefer Claymore/Windows over silentarmy/Linux.
To rednoW who said "And Claymore is faster, especially on Tahiti" -> this is not true, silentarmy matches or surpasses Claymore even on Tahiti (especially when taking into account its 2.5% dev fee).
Anyway it is apparent to me that many features (temp/fan monitoring, pool failover, Windows support, etc) are what you guys want in a miner. So I will take this into consideration to prioritize my future developments. But on the other I agree with the 80/20 rule: like Bitcoin in its early GPU mining days, it seems 80% of the hashrate comes from 20% of people who operate large Linux mining farms, while 20% of the hashrate is from 80% of people who operate smaller hobbyist Windows mining farms.
|
|
|
|
Ok thanks for the info. I thought you had ported the reference silentarmy miner. |
|
|
|
In case you missed it, Claymores Zcash is out. Looking at 50sols on a 470. Haven't found a 480.
Are people so excited about the Claymore Zcash miner because it supports Windows? My SILENTARMY Zcash miner is as fast as (if not a hair faster) than Claymore. And open source. And zero dev fee. Maybe I should prioritize Windows support higher? |
|
|
|
Yesterday I tested the silent army solver on the 1060 3gb. it does 16sol/s.
Tomorrow I'll start looking into porting SILENTARMY to Nvidia. Seems like you fixed https://github.com/mbevand/silentarmy/issues/6 so please let me know how. That will save me some time tomorrow  |
|
|
|
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: #!/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#L568Since 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  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/fg5ZEiaiDitto: hardware issues. |
|
|
|
I am impressed by your hard work and motivation into porting it to Windows! |
|
|
|
if someone could compile this and make a windows executable he would be a hero
Be a hero yourself: install and run Linux! :-) Seriously, I'll look into Windows support, but not for the next version. Maybe later. |
|
|
|
Thanks, only tried -v. I guess it's then related to bytes.hex throwing an error - and I replaced it with binascii.hexlify - I can't find the documentation to bytes.hex. To solvers: b'4f8d976e1283c0caa145b6f3fdd478e9263108ac1c5a643bdf4f8d976e128300' 9732eb5b92ca5bdbb150 b'04000000455f40ac14ec9f6bad6cc8d5de2714ea84be396203d45e710745605e01000000f963ea196bb8cb2260a2825beca315b6d1e6608d8696338e26b75f8b1a4f93da0000000000000000000000000000000000000000000000000000000000000000fc4e1c58940d041d' b'6493d02292'
From solver 0.0: banner "SILENTARMY mining mode ready"
From solver 0.0: strange: more than 1 line was read
These messages are normal & expected. bytes.hex() is built into Python 3. If you don't have bytes.hex() it sounds like you are trying to run it under Python 2 which is not going to work (doesn't have asyncio, etc) |
|
|
|
@mrb thanks, I got around that problem. I run into DEBUG:asyncio:poll 573.300 ms took 0.016 ms: 1 events
DEBUG:asyncio:process 21691 exited with returncode 1
INFO:asyncio:<_UnixSubprocessTransport pid=21691 stdin=<_UnixWritePipeTransport closed fd=17 closed> stdout=<_UnixReadPipeTransport closed fd=18 closed>> exited with return code 1
DEBUG:asyncio:poll 563.276 ms took 0.014 ms: 1 events
DEBUG:asyncio:process 21692 exited with returncode 1
INFO:asyncio:<_UnixSubprocessTransport pid=21692 stdin=<_UnixWritePipeTransport closed fd=19 closed> stdout=<_UnixReadPipeTransport closed fd=20 closed>> exited with return code 1
INFO:asyncio:poll 999.912 ms took 1001.039 ms: timeout
I can run the solver manual and it seems to work. Is there an easy way to see the output/error of the solver so that I can keep debugging? Weird. Enable verbose or very verbose ("-v" or "-v -v") mode and you'll see the stdout/stderr output of sa-solver. |
|
|
|
@mrb
Which python version do you support?
It requires Python 3.4.5 or above due to this issue: https://github.com/mbevand/silentarmy/issues/8For those running Ubuntu 14.04 (which very unfortunately ships a slightly too old 3.4.x) there is a workaround documented in this github issue by n1koo (4th message from the top). I'll try to fix that in the next few days so SILENTARMY doesn't require Python 3.4.5. |
|
|
|
1 or two instances?
With the latest SILENTARMY v3, there is no more need to care about instances. You run just 1 instance of "silentarmy" in a terminal console, and by default, under the hood, it runs 2 instances of Equihash per GPU (--instances option defaults to 2). |
|
|
|
Will it also support mixed mode(AM/Nvidia mix)?
Probably, yes. |
|
|
|
Marc, have you considered making NR_ROWS_LOG fixed at 20, and clearing cnt for each round? Then each row would have only collisions at each round, avoiding the need to search for collisions. Then NR_SLOTS/OVERHEAD could be significantly reduced.
To avoid time penalty for clearing the cnt values, instead of calling kernel_init_ht at each round, you could zero the count after checking the row. When the DRAM page is already open to check the cnt value, the time cost of doing a write back to the same page (in fact, same 64-byte cache line) is minimal.
Yeah NR_ROWS_LOG is pretty much always compiled at 20. But I have to offer the other options because people want to mine with GPUs having very little memory. And I don't know if you checked the latest commits, but OVERHEAD has been lowered to 9 so 1 Equihash instance needs only 1.2 GB, and I recently made the exact change you suggested (clearing the counter after we are done using/reading it). |
|
|
|
I released SILENTARMY v3 which is now a full miner with multi-GPU support, Stratum support. Check the top post for more info. https://github.com/mbevand/silentarmyHere is a test machine mining (R9 Nano and RX 480 8GB):  |
|
|
|
|
Show Posts
