CPU: i5-750 (4 cores, 4 threads) 2.66 GHz, 64 bit
4 GB DDR3 1333 MHz (10666 MB/s )
70 seconds for the 2 hashes.
I took out one of the two DIMMs (2 GB)
and got 79 seconds.
How do I run 2 or more threads?
Thanks to Austin-Williams. I never use linux and was running in a few minutes without a hitch after getting Ubuntu on a dual boot.
In the config file add this line:
genproclimit=8
(8 being the number of threads you want to run, or more or less depending on the machine)
I can’t get it to affect it. Is the config file in
~/.zcash/zcash.conf
like A-W’s guide says?
Yes, the zcash.conf file is in the .zcash folder. It’s the same document you set up for mining.
You will notice more threads being used while mining if you look at your system monitor, but for benchmarking if you use the solveequihash command it currently only runs on one thread, so you are essentially only measuring your single thread performance.
As I mentioned in another thread, they are still working on parallelizing the code so hopefully we will be able to get faster solve times with more cores.
76 seconds is 10x slower compared to previous comments. Although someone mentioned it might increase like this.
I had to include gen=1 in zcash.conf to get multiple threads going. “gen=1”
is in A-W’s guide, but not the official Alpha guide.
I had to run as root to get CPU core use percentages from 1% to 90% and memory usage from 1% to 40% (4 threads) or 80% (8 threads). Each thread as root used 10% RAM (0.4 GB) which I believe someone else mentioned. Subsequently trying to run as superuser again required rebuilding the block database.
Running the benchmark as root did not speed it up.
I guess this is due the z6 build? i get around 60 s with an i5 6th gen and 16 gb DDR4-RAM in a VM.
anyone?
On earlier releases I was testing Zcash on a few different computers with a bootable Ubuntu usb stick - which is another option to avoid the need for creating a dedicated Linux partition. The point of which being I think your system might be able to do better without the VM and / or host OS overhead.
In github they were getting these kind of speeds a few days before its release.
I guess I expected a little more from ddr4 - although a friend’s aging i7 iMac with ddr3 1333 did better than I expected on a previous release.
I ought to start a speeds and feeds thread…
btw This is what I just got on my i5 5200-U ddr3 1600 laptop…
59.530226
55.381696
63.689817
54.879578
60.087954
55.451085
55.654323
56.79635
57.528476
59.126605
57.812611 Average
54.879578 Minimum
63.689817 Maximum
I tried to run ./zcash-cli zcbenchmark solveequihash 10 and there was no returned data, just the blinking cursor and eventually mining on 7 out of 8 cores stopped and it basically hung. I tried restarting and running it again but the same problem happened… I am new to a lot of this including Ubuntu so maybe I am missing something obvious…
First try running zcash-cli zcbenchmark solveequihash 1 and give it a minute or two to complete. The benchmark is quite time consuming.
It can take a long time to finish that command. On a server with newish hardware it can take up to 10 minutes for that command to complete.
Try it with ./zcash-cli zcbenchmark solveequihash 1 instead.
Note that in the next release (z8), there will be an extra parameter to the “time solveequihash” benchmark to specify the number of threads. Thanks to @Shawn for pointing out this omission.
What is the format of the command to test the extra threads in solveequihash? Does any mining need to stop when running the test?
Add another numeric argument, ie: time solveequihash NUM_ITERS [NUM_THREADS]
When I execute
time solveequihash 1 4
What does the one number output mean? The average time of the 4 threads?
That’s not how I understand what’s happening with the newly multi-threaded benchmark. Setting additional cores to work cooperatively on a single data-set is not an instance where averaging should be used.
An average could be used to interpret a benchmark result If cores were working individually on different data-sets. But I don’t think that’s what’s happening here.
Imagine shuffling a deck of cards with one hand, vs shuffling a deck with two hands, vs each hand shuffling its own deck.
I assumed it was different data sets because 4x threads = 4x RAM requirements.
I had read on github a discussion about it still having problems of not being representative because some threads would be finished, waiting on the slowest thread to finish before beginning the next data set(s).
It’s currently the maximum time of all the threads. As mentioned in Make the solveequihash benchmark more representative of solution latency / add another benchmark for throughput · Issue #1191 · zcash/zcash · GitHub , this is not what we want since it isn’t a good measure of performance. Until this is fixed, I’d recommend just ignoring the multi threaded benchmark option, and instead using genproclimit and measuring from logs the number of solutions that are difficulty-tested in a given time. (This is essentially what the throughput-oriented benchmark will do.)
Here’s how to get the log output: Zcash daemon logging settings? - #3 by str4d
