Update documentation to refer to a "solution rate" for mining #1422

Closed
tromp opened this Issue Sep 20, 2016 · 16 comments

Projects

None yet

6 participants

@tromp
tromp commented Sep 20, 2016 edited

It seems the very name of the proof of work, "Equihash" inspires confusion,
as it is not a hash function. The often used notion of hashrate could mean
various things, like runs of the equihash algorithm, underlying blake2 hashes,
or final difficulty filtering hashes applied to solutions.
To me, only the last measure is relevant for miner performance, since alternative
solver implementations may have various numbers of expected solutions per run
(e.g. sacrificing fractions of solutions for speed).
Furthermore, that measure is better expressed not as "hashrate" but as
solution rate or solve-rate. I propose to adopt the latter term in discussing miner performance.

@str4d str4d added this to the 1.0.0-rc1 milestone Sep 20, 2016
@str4d
Collaborator
str4d commented Sep 20, 2016

Putting this into -rc1 but not adding to the engineering agenda, so we will remember to discuss this after beta 2.

@str4d str4d added maybe in 1.0 and removed Monetary Policy labels Sep 20, 2016
@str4d
Collaborator
str4d commented Sep 20, 2016

I think this is a relatively easy change. The only RPC it affects is getnetworkhashps (which we could just alias to e.g. getnetworksolutionps); otherwise it's just documentation changes (and a UI change in #1375). But I'm not going to think any more about it right now.

@artlav
artlav commented Sep 20, 2016

I can add to that an empirical observation that equihash as implemented in the daemon produces on average 2.8 solutions per run, do the 2/time formula is a little bit off.

@daira
Contributor
daira commented Sep 20, 2016 edited

-1 on making any code changes for this (except comments). -1 for changing "Equihash". +1 for changing "hash rate" to "solution rate" in any documentation. Actually, the protocol spec already refers only to "valid Equihash solutions", it never refers to these as "hashes", which would be very ambiguous.

@tromp
tromp commented Sep 20, 2016

Ok, "solution rate" is it. I'll point people still using the ambiguous "hashrate" to this discussion
and hope to get them onboard....

@tromp tromp closed this Sep 20, 2016
@daira
Contributor
daira commented Sep 21, 2016 edited

BTW, I'd like "solution rate" to refer only to the actual number of solutions checked against difficulty, not to a guessed rate based on the expected number of solutions. The latter introduces systematic errors. If people are guessing rates based on that then I'd prefer them not to use "solution rate" for the time being.

@str4d str4d reopened this Sep 21, 2016
@str4d str4d changed the title from Avoid ambiguous hashing terminology to Update documentation to refer to a "solution rate" for mining Sep 21, 2016
@str4d
Collaborator
str4d commented Sep 21, 2016

Reopened this issue to track any documentation changes.

@zawy12
zawy12 commented Sep 22, 2016 edited

Can someone correct, support, or clarify @artlav 's statement for me? Daira has said it is a little less, not 40% higher. I'm thinking it's wrong, either because of how the "0 solution" comes into play, or because the avg(time/run) is simply > avg(time/solve x solves/run) because the time for say a 5-solution run is more than 5 x the time for a 1-solve run.

@daira
Contributor
daira commented Sep 22, 2016 edited

I should clarify that I haven't measured it. The theoretical expected number of solutions per run can be calculated as follows:

#!/usr/bin/python

# Return product{i = x+1..y}(i/y)
def thingamajig(x, y):
    r = 1.0
    yd = float(y)
    for i in xrange(x+1, y+1):
        r *= i/yd
    return r

def solutions(n, k):
    N = 1<<(n/(k+1)+1)
    return 2 * thingamajig(N - (1<<k), N)

print solutions(200, 9)

which gives 1.879.

@daira
Contributor
daira commented Sep 22, 2016 edited

And yes, it's not correct to calculate the expected rate as just (expected solutions / mean full solution run time); that would only be correct if the full solution run time were independent of the number of solutions, which it absolutely is not.

@tromp
tromp commented Sep 22, 2016

which gives 1.879

That closely matches my 18841 total solutions found over 10000 runs of a solver.

@artlav
artlav commented Sep 22, 2016

Correction - my 2.8 number is likely biased, since i made the test suite out of already-mined block found on the testnet, which, by definition, are all with one or more solutions.

However, further observations of the actual solver running on the actual network reveals the existence of some amount of runs with ZERO solutions, which would, i suspect, drive the average down.

@zawy12
zawy12 commented Sep 22, 2016

The 15 to 20 second solves seen on CPUs are the zero solutions. That's why no solves from CPUs on the testnet are less than 30 seconds.

@str4d
Collaborator
str4d commented Oct 5, 2016

The devs in the mining channels on the community Slack are now using units of Sol/s, so that is what we should use in any documentation changes.

@str4d str4d added a commit to str4d/zcash that referenced this issue Oct 5, 2016
@str4d str4d Use solutions per second (Sol/s)
Part of #1422
90b9f99
@arcalinea arcalinea was assigned by bitcartel Oct 6, 2016
@arcalinea
Collaborator

Documented in the Mining Guide wiki page: https://github.com/zcash/zcash/wiki/Mining-Guide

@arcalinea
Collaborator

Closing this issue since our documentation in the Zcash repo now directs to the wiki for build and mining guides

@arcalinea arcalinea closed this Oct 11, 2016
@daira daira added a commit to str4d/zcash that referenced this issue Oct 22, 2016
@str4d @daira str4d + daira Use solutions per second (Sol/s)
Part of #1422
5c60ee7
@str4d str4d added a commit to str4d/zcash that referenced this issue Oct 22, 2016
@str4d str4d Use solutions per second (Sol/s)
Part of #1422
199b3aa
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment