SILENTARMY v5: Zcash miner, 115 sol/s on R9 Nano, 70 sol/s on GTX 1070

[nerdralph]

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.

[giagge]

Im wait windows x64 on Nvidia .

[tbearhere]

Im wait windows x64 on Nvidia .

Me too  on comp 5.0 and 5.2. 

[mrb]

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/silentarmy

Here is a test machine mining (R9 Nano and RX 480 8GB):

[mrb]

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).

[giagge]

Im wait windows x64 on Nvidia .

Me too  on comp 5.0 and 5.2. 

Im for cuda for gpu pascal ( gtx 1060-1070-1080 ) .

[coinut]

Im wait windows x64 on Nvidia .

Me too  on comp 5.0 and 5.2. 

me 3 , 750ti and 1070 

[ioglnx]

Well I also wait for CUDA8 support and SM/compute 6.1 support.

Will it also support mixed mode(AM/Nvidia mix)?

[vatusasid]

How did you make the R9 Nano or the Fury cards to run so fast? I use the stock setting and the speed is just 25S/s. What driver do you us?

[thaiphamce]

confirm, rx470 45sol/s  ~250 sol/s for 6

[Gataway]

confirm, rx470 45sol/s  ~250 sol/s for 6

Is that the V2 or the V3 of the kernal?

[ioglnx]

1 or two instances?

[mrb]

Will it also support mixed mode(AM/Nvidia mix)?

Probably, yes.

[mrb]

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).

[efficienthash]

@mrb

Which python version do you support?

[thaiphamce]

confirm, rx470 45sol/s  ~250 sol/s for 6

Is that the V2 or the V3 of the kernal?

lastest version, v3

[mrb]

@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/8

For 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.

[efficienthash]

@mrb

thanks, I got around that problem. I run into

Code:

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?

[mrb]

@mrb

thanks, I got around that problem. I run into

Code:

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.

[efficienthash]

@mrb

thanks, I got around that problem. I run into

Code:

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.

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.

Code:

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