-
Notifications
You must be signed in to change notification settings - Fork 542
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
Improve hash rate reporting #190
Comments
Some updates. This will only work for stratum pools at first. Will consider something similar for GBT and getwork It is my intent to provide API access to the share stats and summary stats. I still haven't found a magic constant to make it work for all algos. At this time it will be Some stats can't be averaged because they could include stats for different coins that use the The summary report will be seperated from the share report and changed to a 5 minute window The summary report will include share submission rate, average share hash rate and Block time (TTF) will be removed from the share report. It is mostly a curiosity, is very volatile Using the block height to determine coin id in a multipool has some promise for automation It is unlikely that 2 coins using the same algo will have the same block height. Well maybe not Users can use the block height to match up with a coin in the multipool with the same block height. Creative mining manager program developpers may find other uses. Findng a way to determine net hash rate seems futil for a miner |
The magic constant was an illusion. I didn't wait long enough for the hash rate to converge and The format is firming up. A new 5 minute summary report has been created providing [2019-06-24` 11:14:01] Summary: 27 shares submitted in 5 mins 18 secs. The share submission report is divided into 2 parts. Only the accepted/rejected line is output when default: [2019-06-24 11:20:43] Share 2 submitted by thread 9, lane 1. -q: [2019-06-24 11:10:08] Accepted, diff 0.0121, 3.467 secs, A/R/S: 11/0/0. |
Included in this issue is a change to supress the per-thread hash rates reports by default. A new |
The final report formats apppears to be set and will be included in the next release. [2019-06-24 14:28:03] Share 26 submitted by thread 7, lane 6. Line 1: Displayed when a share is submitted to the pool. Not displayed with -q option. Line 2: Displayed when response is received from the pool. [BLOCK SOLVED,Accepted,Rejected]: the result of the share. diff; the share's difficulty. [secs]: number of seconds to find the share. [A/R/S]: the number share that were accepted, rejected and that solved blocks. Lines 2 & 3 are displayed with more info about the accepted share. This info is Miner: the hashrate calculated by the miner by counting hash iterations over time. Share: the hashrate calculated using the share diffficulty. This is more representative latency: the round trip time from submitting the share to receiving the response. Block height: The block number of the coin the share contributed to. In a multipool the block Block share: a percentage of the block credited to the user for that share. [2019-06-24 14:28:07] Summary: 26 shares submitted in 5 mins 20 secs. The summary report in displayed approximately every 5 minutes. Line 1: the number of shares submitted during the time and the precise time interval. Line2: Avg hashrate: the average share hashrate (see definition above) of the submitted shares. avg latency: the average network latency. temp: the CPU temperature measured at the time of the report. This is displayed on Linux only. |
Colour coding has been added to the diff field of the accept message and the block share Magenta: grade A+, solved a block, "BLOCK SOLVED" replaces "Accept", |
Final format of the new share submission report and 5 minute summary report. For each share submitted: [2019-06-26 10:07:04] Share 1 submitted by thread 12. Line 1 is displayed when a share is submitted unless -q option is set. Thread and lane: Parallel multiway hashing. Lines 2 is displayed when a response to a share submission has been received. Result: (green) "Acccepted" a valid share was accepted by the pool. diff: the difficulty of the submitted share. Colour coded, see previous comment for details. time: The time since the last share was submitted. A/R/B: A running total of shares accepted, rejected and blocks solved. Note a solved block Lines 3 & 4 are displayed for accepted shares unless -q option is set. Miner: the hashrate calculated by the miner by counting hash iterations over the share time. Share: the hashrate calculated using the share diffficulty and time. This is more representative latency: the round trip time from submitting the share to receiving the response. Block height: The block number of the coin the share contributed to. In a multipool the block Block share: The percentage of a block the accepted share represents if the share hashrate [2019-06-26 10:17:48] Summary: 13 submits in 5m15s, block share 0.09825%. The summary report in displayed approximately every 5 minutes. Line 1: the number of shares submitted during the time and the precise time interval. Block share: The percentage share of a block the shares accepted during the period represent Line2: Share hashrate: the average share hashrate (see definition above) of the submitted shares. latency: the average time it takes to receive a response to a submitted share. temp: the CPU temperature measured at the time of the report. This is displayed on Linux only. |
Very well done . Everything else works good.. tested with SSE2 , AES / AVX / AVX2 |
Thanks for the input. I don't think that's a good workaround. It's easier just to ignore it and it will go away. I'm making few changes to the share report and summary. I'm reversing the colours white and Something not so visible is a problem if a new share is submitted before the previous share's |
cpuminer-opt-3.9.5.1 has some aditional changes. The biggest change is the use of the colour yellow. from now on yellow will only be used to Normal protocol messages will be blue. Stratum difficulty changes and share submissions will Job id has been added to many existing messages as well as one new message. This is to The colour grade thresholds have been tweaked to better reflect the exponential nature There is also a fix to handle rapid share submissions and slow acknowledgments. Share |
A note about the API bind error, that usually means another miner, usuallly ccminer, is running I could look at making some changes such as choosing a different default port to avoid clashing |
Another refoinement is necessary to manage the stats circular buffer in case it overflows (too many If an ack is never received the buffer pointers will be out of sync with a permanent pending share. If the pool just stops responding all bets are off, the buffer will overflow and never get emptied. |
This issue has run its course. V3.9.5.3 includes some tweaks, specifically an 8 slot circular |
The hash rate reported reported by miners is calculated by counting the number of hash
iterations over a period of time. This represents how fast the miner is. This hash rate tends
to be consistent and not affected by luck or factors other than the performance of the miner.
The pool calculates hash rate based on the share frequency and difficulty. This hash rate
represents the actual success of the miner in finding and submitting valid has, which
includes a lot of luck.
The questions to be ansered are:
Can the miner replicate the way pools calculate hash rate?
What other useful information does the miner have to give users a bigger picture of
the mining environment.
The answer to the first question is yes and the answer to the second question is quite a lot.
Without delay here is a sample of the kind of information available. Everything will be
explained below.
`[2019-06-23 01:46:41] Share submitted.
[2019-06-23 01:46:41] Accepted 72/72 (100%), diff 3.01e-05, 1013.17 H/s, 60C
[2019-06-23 01:46:41] Share hash rate: 596.612 H/s, time: 27.068 secs.
[2019-06-23 01:46:41] Share of block: 0.00262, Block time 2.868 hours.
[2019-06-23 01:46:41] Block height 417421, net hash rate 2.28e+05
[2019-06-23 01:46:41] Averages: hash rate 942.3420 H/s, share 0.238 %
[2019-06-23 01:46:41] Average block time 2.283 hours.
[2019-06-23 01:46:58] Share submitted.
[2019-06-23 01:46:59] Accepted 73/73 (100%), diff 9.19e-06, 1013.81 H/s, 60C
[2019-06-23 01:46:59] Share hash rate: 279.633 H/s, time: 17.638 secs.
[2019-06-23 01:46:59] Share of block: 0.000801, Block time 6.118 hours.
[2019-06-23 01:46:59] Block height 417421, net hash rate 3.49e+05
[2019-06-23 01:46:59] Averages: hash rate 934.1547 H/s, share 0.236 %
[2019-06-23 01:46:59] Average block time 2.301 hours.
[2019-06-23 01:47:42] Share submitted.
[2019-06-23 01:47:42] Accepted 74/74 (100%), diff 1.51e-05, 1015.35 H/s, 60C
[2019-06-23 01:47:42] Share hash rate: 186.654 H/s, time: 43.415 secs.
[2019-06-23 01:47:42] Share of block: 0.00132, Block time 9.166 hours.
[2019-06-23 01:47:42] Block height 417421, net hash rate 1.42e+05
[2019-06-23 01:47:42] Averages: hash rate 912.0947 H/s, share 0.235 %
[2019-06-23 01:47:42] Average block time 2.353 hours.
[2019-06-23 01:47:52] Share submitted.
[2019-06-23 01:47:52] Accepted 75/75 (100%), diff 8.38e-06, 1009.21 H/s, 60C
[2019-06-23 01:47:52] Share hash rate: 440.825 H/s, time: 10.207 secs.
[2019-06-23 01:47:52] Share of block: 0.000731, Block time 3.881 hours.
[2019-06-23 01:47:52] Block height 417421, net hash rate 6.03e+05
[2019-06-23 01:47:52] Averages: hash rate 908.8474 H/s, share 0.233 %
[2019-06-23 01:47:52] Average block time 2.359 hours.
`
Share submitted: This message is displayed when a hash is found and submitted to the
pool.
Accepted: the response from the pool, inclusing the share difficulty and the iterative hash rate.
Share hash rate: based on share diffficulty and time.
Time: time since last submit.
Share of block: How much of a block does the share represent.
Block time: The estimated time to find a block at reported share hash rate.
Block height: Can be used to identify which coin received the share in a multipool.
net hash rate: garbage ignore it.
Averages are for entire session. It usually takes around 100 shares for convergence.
Average hash rate tends to track the pool's reported hashrate much better than
the iterative hash rate.
Block time is a function of the coin being mined so average block time doesn't make sense
in a multipool.
Block time means nothing to the pool or it's TTF, it is an estimate of solo mining expectations.
Network hash rate would be nice but I don't think I have the required variables to
calculate it. Another would be nice is % share of a block but that would require knowing
when a block is found.
This is a very rough first cut but is very encouraging. I can make it work for 2 algos
bt it requires some hard coding, which leads to what's next.
I need to find the magic recipe that works for every algo, hard coded values for each algo
is a show stopper.
Verify accuracy of derived data. Share hash rate looks very good, block time is difficult
to prove.
Change the cummulative averages to 5 minute windowed averages like the pools do.
Report averages at 5 minute intervals insteasd of with each share.
Include other information in 5 minute report: number of shares submitted, accumulated
share difficulty...
Any thoughts? suggestions? additions? deletions? concerns? questions? comments?
The text was updated successfully, but these errors were encountered: