This is a typo: it should be src, not serc.
Good catch! Thanks @daira ! Does it look like I’m connected to the testnet ok?
Based on the “WARNING: check your network connection” message, it looks like you were not at the time you ran that command. Make sure that you carefully follow all the steps in the Public Alpha Guide.
I don’t think any new installs are getting connected. Where it says “connections” you should see “1”. See the “connections” thread where there is a work-around.
Have we solved this yet? Is there a way to run a benchmark that will let each core solve individually and then give an average time for each core? As of now when I run ./zcash-cli zcbenchmark solveequihash 10 it only uses one core which I guess is fine because they are all the same so essentially this is my solve time per core. Am I correct on this? What is the best way as of now to test say my whole computer if I want to know how fast I am mining on all cores?
I think that zcbenchmark solveequihash doesn’t do what it’s supposed to do. (Either that, or I misunderstand what it’s supposed to do.)
Here’s what I’m expecting. I expect that when I enter
$ ~/zcash/src/./zcash-cli zcbenchmark solveequihash 4 4
that 4 threads will be started at the exact same time and begin solving 1 instance of Equihash each. I also expect that this should be done concurrently (otherwise what’s the point?)
Then, after the last of the 4 instances of Equihash is solved, I expect a list of solve times – one solve time for each thread. Moreover, I expect the entire operation to exactly as long as the longest solve time that occurred (because of concurrency).
But what I actually experience is much different.
I enter $ ~/zcash/src/./zcash-cli zcbenchmark solveequihash 4 4
I notice that four of my eight cores get busy at 100% each. (CPU: 400% usage as seen by $ top).
Then, 285 seconds later, I get this output:
[
{
"runningtime" : 85.91244300
},
{
"runningtime" : 60.99039500
},
{
"runningtime" : 98.62096300
},
{
"runningtime" : 39.67143800
}
]
The length of the execution time of zcbenchmark solveequihash 4 4 is the sum of the lengths of the individual solve times. This seems to indicate that the operations are running consecutively rather than concurrently.
What am I missing?
Is this not a proper way to benchmark the performance of multicore CPUs?
I have never tried the multi-thread option because it was not correct the 1st time and I do not know if there is any way to test if the improvements will be representative of real mining. Even the single thread option is hard to convert to the network. On z8 my 70 second machine got half as many blocks as my 50 second machine. By the ratio, my 50 second machine should have got 42% more blocks, not 100%. Most my comments that do not refer to a H/s or benchmark are based on my measurements of my CPUs on the network compared to the network.
The current multithreaded benchmark is effectively measuring the maximum time of any of the N threads, given that they start together. Because of the variability in total solution run time, this is not useful at all. It’s just a bug.
Remember that we can only release bug fixes in releases! This one already has an ACK’d PR: Measure multithreaded solveequihash time per-thread by str4d · Pull Request #1376 · zcash/zcash · GitHub
I have ran this command several times with multiple threads on a 3rd gen i7 3770-(nonK) 16gb RAM, in a 4 core 8 GB dedicated VM, What times should i be expecting? Does anyone else have a similar platform they are using?
You can see benchmarking from other users here: https://benchmark.minezcash.com
Feel free to add your own results
Thank you @Shawn for the link!
this is fixed now?
I hope the benchmark is up to date now
have installed Zcash on centos 7 64 bit was running ok but recently stucks on " Init message: Activating best chain…"
have anyone run into this error message
Thanks