|
I have not moved on, but in this period of end-of-year festivities, I am spending more time with family and less working on SA. So v6 will be ready when it is ready. Right now it is a work in progress. I have code mostly finished that in theory should be roughly as fast as Claymore, but I am unable to tell how fast it is because a bug I have yet to track down leads to incorrect results being generated.
|
|
|
|
Hello all, I am finally back online for good after my move. It's good timing that this coincides with learning that I won the $10k Zcash miner challenge prize, as it can justify to the wife that the time I spent working on it so far was worth it  I am now working on optimizations that will bring SA to the performance level of Claymore & Optiminer. In fact I spent a few hours on this already over the past week or so, but more work is needed. zawawa: good luck with your fork! I hope you too can achieve good performance. We need more open source alternatives. (But please don't call your fork "SILENTARMY v6" as I am going to release that... it would confuse people.) |
|
|
|
Hey devs, I have been playing with eXtremal's latest kernel and trying to optimize kernel_sols() now as it seems to be one of the bottlenecks as far as I can tell with CodeXL with NUMVGPR being over 170 on RX 480. I was able to reduce it to 50 something, but I cannot get rid of scratchpad registers that are 512 bytes in size. They must have something to do with array indexing, but I was not able to pinpoint the exact portion of the code that is causing register spills. Do you guys have any ideas?
kernel_sols is not a bottleneck. It only takes 1.2-1.5 ms on the R9 Nano out of 17 ms of a full Equihash run. |
|
|
|
You are incorrect. Cache lines are 64-bytes long because AMD memory channels are 64-bits wide (i.e. 2 DDR5 chips). The GCN memory controller is not 32-bits wide, with 2 consecutive bursts to fill a cache line. "Each memory controller is 64-bits wide and composed of two independent 32-bit GDDR5 memory channels." - pg 10: https://www.amd.com/Documents/GCN_Architecture_whitepaper.pdfI read tons and tons of docs (including this whitepaper), but somehow missed that one line. Ok. Misconception clarified |
|
|
|
don't need to rush, you are already 40-50% behind claymore  That's even more a reason why I would want to be able to rush and beat him! |
|
|
|
Update: I am quite busy at the moment because my wife and I are preparing to move to a new house (worst possible timining in this fast-moving zcash mining world... :-/) but I should have enough time to at least continue accepting small changes submitted by people, and then get back to working on silentarmy optimizations "soon". PS: I committed the Nvidia busywait fix: https://github.com/mbevand/silentarmy/commit/a6c3517fc189a934edfa89549664f95b51b965d8
|
|
|
|
The reason is that AMD memory channels are 64-bits wide, and GDDR5 transfers a minimum of an 8-bit burst, so AMD GPUs transfer a minimum of 64 bytes of data to RAM at a time. In addition, if the GPU kernel writes less than 64 contiguous bytes at a time, the memory controller will read 64 bytes, modify some of the bytes, and then write 64 back to RAM.
This is actually incorrect. The GDDR4-5 channels are 32 bits wide, so the data granularity is 32 bytes. However, cache lines are 64 bytes long, so in practice you often have 2 consecutive bursts, hence 64 bytes read or written. And for HBM memory (R9 Nano & R9 Fury) the channels are 128 bits wide, however the burst length is reduced to 2, maintaining the same granularity of 32 bytes. |
|
|
|
1 out 7 480s (4 GB) is hashing lower than others. Is there something that could be done to fix it? Not that I am complaining, it is hashing way higher than Claymore V4, just curious what is causing 1 GPU (dev6) to hash lower.
Assuming you run with --instances 2 (default), one of the 2 sa-solver processes may have crashed for this GPU. Does it go back up to 80+ sol/s after restarting silentarmy? |
|
|
|
The developer of this miner should correct the mining.authorize stratum command to include the expected number of parameters (params) as being an array of the worker name and password. It is currently sending only an array of one item, the workername and is breaking existing stratum code which has always included, and is defined as per protocol description as needing worker name and password.
example, {"id": 12, "method": "mining.authorize", "params": ["worker"]}
needs to be , {"id": 12, "method": "mining.authorize", "params": ["worker",""]}
This currently improper command breaks compatibility between this miner and some pools/services.
Will fix. But in the mean time you can just specify: on the command line and it will do the proper thing. |
|
|
|
Can you add print("Total %s sol/s [%s] %d share%s" % \
(rate_avg, info_gpus, shares, '' if shares == 1 else 's'))
sys.stdout.flush()In python script ? When running with redirecting to log files, nothing recorded for a while. Done. But http://linuxcommand.org/man_pages/unbuffer1.html is your friend |
|
|
|
try different combinations of --use --use 0,1,2,3,4,5
--use 1,2,3,4,5,6
--use 2,3,4,5,6,7
thanks Just use --list to see what IDs are your GPUs. |
|
|
|
Hi, mrb
Could you implement some very usefull, ccminer-like option: -S --syslog
-S, --syslog use system log for output messages
that would be nice for KopiemTu support, i.e. for monitoring
It's low priority, but I will consider it. In the mean time I am happy to accept patches from contributors. |
|
|
|
nm no idea tried and get the same thing . What is their stratum endpoint? I can't find it after 30 sec looking around www.miningrigrentals.com |
|
|
|
I think in terms of speed claymore and sav5 are almost the same, but with share finding, I can conclude that claymore does find more. I tracked all the shares with SA5 and compare it with the logs on claymore miner and the difference is 27% for 24 hours.
Either you are wrong, or you are using a fork of silentarmy that is broken/buggy. I can only vouch for code and binaries obtained from https://github.com/mbevand/silentarmy It's very easy to verify: because pools compute the sol/s based on the number of shares submitted, if the pool shows you an average sol/s rate that matches what silentarmy reports then it means silentarmy is finding the expected number of shares. Also you can't compare the # of shares between different runs of a miner (even different runs of the same miner), because many pool use vardiff which means different miners mining at the same sol/s rate will find a different number of shares that depends on the target sent to the miner. |
|
|
|
may be also better to add "--extranonce-subscribe" description to the help?
It does not take --extranonce-subscribe. Instead you add "#xnsub" to the stratum URL (that's described in the usage help). |
|
|
|
EXTRANONCE SUBSCRIBE (#XNSUB) --
The acronym "#XNSUB" is used to tell some mining software to use extanonce subscribe code, as in "algo.usa.nicehash.com:1234/#xnsub". Yes, your miner may have worked on nicehash since verssion four (v4). However, getting it to compile and run on my own Lubuntu 14.04 rig was not so simple. I am grateful that krnlx provided both a binary, and code, that simply went together immediately.
The nasty red "X" that appears in the extranonce subscribe column of the NiceHash stats (statistics) page is bothersome. Your miner does mine on several different pools as-is. I left some dust at about three. NiceHash pays in BitCoin (BTC), and the perservering wallet problems for Zcash (ZEC) are not in play there. All my nVidia cards are currently minning CryptoNight (XMR) or Zcash (ZEC) on NiceHash at the moment, and the BTC payout offsets the recurring ZEC wallet problems encounterred by my Linux AMD ZEC rigs.
Thank you for your coding efforts. Please keep up the good work! --scryptr
Ok I added xnsub support: https://github.com/mbevand/silentarmy/commit/47d4497ec7e516259674eb7dbdd4b39cbc95ab32 |
|
|
|
is this something in addition to v5, or I can just make after cloning from the current github?
Just clone and make. I simply uploaded a pre-compiled binary for lazy ones  @greaterninja thanks! |
|
|
|
|
Show Posts
