Since currently the Zcash miner is not taking advantage of all cores available to it (it only maxs out a single thread on my multi-core machines) would it be possible to run multiple instances of Zcash on the same machine or would it be better to run multiple VM’s to try and max out the cores of the host?
How would one go about launching multiple instances with one wallet? -edit I’m going to follow @Austin-Williams EC2 guide to figure this out, are most settings the same for a single machine at home vs Amazon Ec2?
Also I recall one of the developers talking about the code not being parallelized yet, can anyone confirm if the final version will or won’t be?
You can set genproclimit = -1 in zcash.conf to permit zcashd to mine on all available processors.
When I run zcashcli -getinfo it returns with a -1 value for genproclimit already set, but still seems to use just one core? I noticed that nMinerthreads is set to (1) in chainparams.cpp would this be adjustable?
@Shawn maybe there’s a bug. I’ve looked at my configuration and I realized I addressed this issue by just setting genproclimit=[my number of cores].
For everyone else who sees this thread, it is my understanding that it is currently planned to make mining inherently multi-threaded, so this issue will likely be resolved by v1.0.
@aniemerg Thanks for the tip, I’ll try that!
I’ll let you know if it works
This could be stretching the definition of multi-threading but, unless those individual cores each have their own memory channel and their own data set to access (along with their own range of nonces to work through), I would only expect a negligible gain (at best) over the current, single-threaded approach to mining.
What I described above is more along the lines of separate mining instances (like a small, private mining pool in a single computer) that are intended to take best advantage of a single computer’s resources for the particular problem at hand - ie: solving Equihash. Whereas other problems that can be solved by a true multi-threaded approach would involve multiple cores working on a single set of data…
The reason I’m laboring this point is that I don’t think it’s such a simple modification to the existing code to ensure that additional mining instances are both established and confined to fixed memory regions that correspond to individual memory channels.
Then again… For all I know, this particular multi-core / multi-channel problem has long been solved by compiler designers…
It seems as though they are working on multithreading for the miner, it’s just not currently implemented: Multi-threaded mining via command-line option -genproclimit duplicates work by using the same nonce values · Issue #1033 · zcash/zcash · GitHub
Your suggestion for setting genproclimit to number of cores is spot on, thank you!
In Bitcoin Core =-1 is supposed to take advantage of all cores available but as you mentioned this may be a bug.
Now that I am crunching at top rate, any ideas why the zcash-cli listunspent and listtransactions commands returns nothing? getinfo shows work, connections, etc… ?
Do you have an existing balance / immature balance? If not, there shouldn’t be any transactions.
-edit Nevermind, I just had to be patient and wait for it to mine for a short while before it returned a value. It’s working fine now
I’ve managed to mine some coins in a 24hr period and I have a few more questions.
The listunspent command returns many separate address with an average of 2 coins per address, is there a way to send all separate coins into a single address? And why does it seem to only add about 2 coins before creating a new address for the next 2?
Also, it seems since z5 I haven’t been able to run the solveequihash command, it just hangs forever?
How many loops of solveequihash have you been trying to do? My friend’s DDR3 1333, i7 iMac (running Ubuntu) managed an average of roughly 50 seconds with the new Equihash parameters.
Also, z5 seems to be going through the slow-start mining reward period. At the very start the reward was closer to 0.5
re: Sending your whole wallet balance in one transaction, mined coins now have to be protected before any other type of transaction can be done with them. This is what prompted me to post the following: Protect coins and then ...?
Well that explains why it was taking forever, I did a solve equihash 10 I was still looking for the previous 1-2 second solve times…
So does it simply assign a new address every time a block is found then its up to the user to transfer all the coins in to a single account afterwards? Or if we had a proper wallet all the separate address wouldn’t matter?
And I agree with your other post, I think we may be reaching the limits of Zcash current functionality/documentation.
Even if a consistent coinbase was used, doesn’t protecting coins only work one input at a time? Maybe that’s just how it’s presented in the PAG to keep the example as simple as possible…
Yes, it assigns a new address every time a block is found.
I didn’t realize the parameters had been updated! Thanks for pointing that out. Anyone know what the current N & K values are?
The z5 release has parameters n = 96, k = 3
, which is supposed to give a peak memory usage of 340 MiB, but seems to be spiking much higher than that in the final round. I’m still tracking down why
AIUI you can have as many transparent inputs to a “protecting” transaction as you want - the JoinSplit can simply take their total sum as its transparent input quantity. The limit on number of inputs and outputs is on the JoinSplits themselves, which are required to have two JS inputs and two JS outputs (for indistinguishability AIUI).
I don’t understand the syntax but, with a little trial and error, I managed to use two inputs at once:
~/zcash$ RAWTX=$(./src/zcash-cli createrawtransaction ‘[{“txid”:“fbda4acf52bd87d8e560a3c89df587a6e6ae5ec68e3957b20e875e219e8042f9”,“vout”:0},{“txid”:“dff392e1838cc3ed890d1f115ee4e1558e275d797c88500235f5828226a4dbfb”,“vout”:0}]’ ‘{}’)
Although, at least so far, trial and error has not won out in my attempts to follow these instructions for spending back to a transparent address…