New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
6 participants
@tromp

tromp commented Sep 20, 2016

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

This comment has been minimized.

Show comment
Hide comment
@str4d

str4d Sep 20, 2016

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@str4d

str4d Sep 20, 2016

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@artlav

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

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

This comment has been minimized.

Show comment
Hide comment
@daira

daira Sep 20, 2016

Contributor

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

Contributor

daira commented Sep 20, 2016

-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

This comment has been minimized.

Show comment
Hide comment
@tromp

tromp 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 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

This comment has been minimized.

Show comment
Hide comment
@daira

daira Sep 21, 2016

Contributor

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.

Contributor

daira commented Sep 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@str4d

str4d Sep 21, 2016

Contributor

Reopened this issue to track any documentation changes.

Contributor

str4d commented Sep 21, 2016

Reopened this issue to track any documentation changes.

@zawy12

This comment has been minimized.

Show comment
Hide comment
@zawy12

zawy12 Sep 22, 2016

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.

zawy12 commented Sep 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@daira

daira Sep 22, 2016

Contributor

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.

Contributor

daira commented Sep 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@daira

daira Sep 22, 2016

Contributor

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.

Contributor

daira commented Sep 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tromp

tromp Sep 22, 2016

which gives 1.879

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

tromp commented Sep 22, 2016

which gives 1.879

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

@artlav

This comment has been minimized.

Show comment
Hide comment
@artlav

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

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

This comment has been minimized.

Show comment
Hide comment
@zawy12

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

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

This comment has been minimized.

Show comment
Hide comment
@str4d

str4d Oct 5, 2016

Contributor

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.

Contributor

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 added a commit to str4d/zcash that referenced this issue Oct 5, 2016

@arcalinea

This comment has been minimized.

Show comment
Hide comment
@arcalinea

arcalinea Oct 7, 2016

Contributor

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

Contributor

arcalinea commented Oct 7, 2016

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

@arcalinea

This comment has been minimized.

Show comment
Hide comment
@arcalinea

arcalinea Oct 11, 2016

Contributor

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

Contributor

arcalinea commented Oct 11, 2016

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 added a commit to str4d/zcash that referenced this issue Oct 22, 2016

str4d added a commit to str4d/zcash that referenced this issue Oct 22, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment