popov/cpuminer-opt-gpu
1
0
Fork 0
mirror of https://github.com/JayDDee/cpuminer-opt.git synced 2025-09-17 23:44:27 +00:00
Code Issues Packages Projects Releases Wiki Activity

Updated Home (markdown)

JayDDee
2020-03-01 20:09:53 -05:00
parent e2c257adea
commit 6ca6488320
1 changed files with 52 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

79
Home.md

@@ -471,7 +471,10 @@ Each provides additional CPU instructions and more complex operations.
SHA supports basic SHA-256 operations with a single instruction, also requires SSE2. First available SHA supports basic SHA-256 operations with a single instruction, also requires SSE2. First available
on Intel Goldmont but not widely avaiable until AMD Ryzen and Intel Icelake. on Intel Goldmont but not widely avaiable until AMD Ryzen and Intel Icelake.
### New stratum, block job report Some other messages are displayed based on options such as stratum connection, API enabled, CPU affinity etc.
### New stratum, block, job report
This report is issued when a new job is received from the stratum server. This report is issued when a new job is received from the stratum server.
If the report is also for a new block or a changed stratum difficulty the report If the report is also for a new block or a changed stratum difficulty the report
@@ -505,7 +508,9 @@ server.
Line 4: Line 4:
* TTF, an abbeviation for Time To Find, an estimate of the average time required to find either a block or a share for a given hash rate. * TTF, an abbeviation for Time To Find, an estimate of the average time required to find either a block or a share for a given hash rate.
* Reference hash rate of the miner, calculated by counting the number of hashes over time. * Reference hash rate of the miner, this is the traditional hash rate displayed by most miners. It is
calculated by counting the number of hashes over time. It should be statistically equal to the sum of the
effective hash rate and lost hash rate.
* Block TTF estimate calculated from miner's reference hash rate and network difficulty. * Block TTF estimate calculated from miner's reference hash rate and network difficulty.
* Share TTF estimate calculated from miner's reference hash rate and target difficulty. * Share TTF estimate calculated from miner's reference hash rate and target difficulty.
@@ -515,17 +520,19 @@ Line 5, only displayed in single coin pools
the mining session. the mining session.
* observed network block TTF calculated from the number of blocks found during the session. * observed network block TTF calculated from the number of blocks found during the session.
### Getwork new block report ### Getwork new block, work report
` `
[2020-02-28 10:54:02] New block 6273226, diff 118.48, ntime 5e5c2e79 [2020-02-28 10:54:02] New block 6273226, diff 118.48, ntime 5e5c2e79
Miner TTF @ 3938.69 kh/s 6m11s, net TTF @ 68.24 Mh/s 2h04m Miner TTF @ 3938.69 kh/s 6m11s, net TTF @ 68.24 Mh/s 2h04m
` `
The getwork new block report is similar to the stratum version escept getwork has no stratum difficulty, The getwork new block report is similar to the stratum new block log with a few differences. There is no
no job id, and no share related estimates. All present fields have the same meaning as the stratum log. stratum difficulty and no job id. "New job" is replaced with "New work". All present fields have the same
Unlike t stratum version the network hashrate is provided by the wallet and the block TTF is calculated meaning as the stratum log but some are calculated differently. New work is detected by a change of the ntime field of the block header data. Unlike the stratum version the network hashrate is provided by the wallet
by the miner. and is not an estimate. The block TTF is calculated from network hashrate and network difficulty and is
therefore considered correct.
### Share submitted report ### Share submitted report
@@ -533,14 +540,17 @@ by the miner.
[2020-03-01 16:52:18] 168 Submit diff 2.4496e-07, block 440815, job 3f4a [2020-03-01 16:52:18] 168 Submit diff 2.4496e-07, block 440815, job 3f4a
` `
The main purpose of the share submitted report is to timestamp the event to measure latency. The main purpose of the share submitted report is to timestamp the event to measure latency. It also contains
info to help tracking.
* submit count is a simple counter that is incremented every time a share is submitted. It should always * submit count is a simple counter that is incremented every time a share is submitted. It should always
match up with a share result counter. match up with a share result counter.
* The difficulty of the submitted share. * The difficulty of the submitted share, should be <= target diff to be accepted, otherwise it will be rejected
as a low difficulty share. Low difficulty shares are caused by the wtrong algorithm or wrong pamameters,
A pool misconfiguration or a bug in cpuminer-opt. A bug is more liky wih new code.
* The current block. * The current block, also known as height.
* The job id, stratum only, useful to troubleshoot stale shares. * The job id, stratum only, useful to troubleshoot stale shares.
@@ -557,7 +567,7 @@ This report is generated when the pool's reply has been received acknowledging t
Line 1: Line 1:
* Share result count, simple counter independant of submit counter but they should match. a mismatch indicates * Share result count, simple counter independant of submit counter but they should match. a mismatch indicates
submitted shares without replies. The result count should also equal the sum of accepted, stale and rejected submitted shares without replies. The result count should also equal to the sum of accepted, stale and rejected
shares, collectivley known as replied or acknowledged shares. shares, collectivley known as replied or acknowledged shares.
* (green)"Accepted", (yellow)"Stale", (red)"Rejected", (magenta)"BLOCK SOLVED" counters. The currently * (green)"Accepted", (yellow)"Stale", (red)"Rejected", (magenta)"BLOCK SOLVED" counters. The currently
@@ -565,25 +575,36 @@ incremented counter is coloured appropriately and displayed in long form. The ot
displayed in their short form with no colouring. Solved blocks also count as accepted therefore the accepted displayed in their short form with no colouring. Solved blocks also count as accepted therefore the accepted
count will also be incremented and displayed in green but in abbreviated form. count will also be incremented and displayed in green but in abbreviated form.
* The time in seconds since the last share. Determines share rate (shares/minute) which combined with the Stale shares can't be completely avoided. There is always a window beetween a job expiring and the miner
stratum difficulty determines the effective hash rate. This is how pools calculate hash rate. getting the new data. Id a share is submitted in this window it will be rejected as stale. Stale shares are
included in lost hash rate.
Rejected shares should never happen. They are either wrong algorithm, wrong parameters or a software bug.
Most common reject reasons are invalid job id which are reported as stale, low difficulty share and invalid
share. Invalid shares are caused by incorrect algorithm, wrong algorithm paramaters or a software bug.
Low diffiulty shares can be due to incorrect algorithm parameters, particularly for algos like yespower,
or a stratum mismatch due to a pool misconfiguration or software bug. When troubleshooting low difficulty
shares the share difficulty and the target difficulty from the new block log are useful information.
* The submit time in seconds since the last share. Determines share rate (shares/minute) which combined with
the stratum difficulty determines the effective hash rate. This is how pools calculate hash rate.
* (Latency ms) Time in milliseconds from share submission to reply, including transmission time and processing * (Latency ms) Time in milliseconds from share submission to reply, including transmission time and processing
at either end. at either end.
Line 2: Line 2:
* Share difficulty. The share difficulty does ot matter most of the time so is FYI. As long as the share * Share difficulty. The share difficulty does not matter most of the time so is FYI. As long as the share
difficulty it is higher than or equal to the target difficulty all shares are considered equal by the difficulty is higher than or equal to the target difficulty all shares are considered equal by the
pool server based on the stratum difficulty. pool server based on the stratum difficulty.
* (share ratio) the fraction of the difficulty required to find a block, 1.0 or greater solves a block. * (share ratio) the fraction of the difficulty required to solve a block, 1.0 or greater solves a block.
Mostly FYI. Mostly FYI except when solo mining. It is the ratio of share difficulty over network difficulty.
* The current block height (block number), coloured magenta when the block is found by the miner. * The current block height (block number), coloured magenta when the block is found by the miner.
* Stratum only, the id of the job associated with the acknowleged share, coloured yellow if the job was stale. * Job id, stratum only, the id of the job associated with the acknowleged share, coloured yellow if the
This is obtained from data collected at submit time. job was stale. This is obtained from data collected at submit time.
### Periodic summary report ### Periodic summary report
@@ -593,8 +614,10 @@ This is obtained from data collected at submit time.
Periodic Report 3m45s 14m58s Periodic Report 3m45s 14m58s
Share rate 9.84/min 9.68/min Share rate 9.84/min 9.68/min
Hash rate 27.03h/s 29.17h/s (22.83h/s) Hash rate 27.03h/s 29.17h/s (22.83h/s)
Lost hash rate 0h/s .17h/s
Submitted 37 145 Submitted 37 145
Accepted 37 145 Accepted 37 144
Stale 0 1
` `
Generated aproximately every 5 minutes. The timing is not precise because it is an opportunistic report. Generated aproximately every 5 minutes. The timing is not precise because it is an opportunistic report.
@@ -620,20 +643,22 @@ below the miner reference hash rate according to luck (ie share rate). A low sha
volatility. Over time the mean effective hash rate should converge to the miner's reference hash rate volatility. Over time the mean effective hash rate should converge to the miner's reference hash rate
if everything is normal. if everything is normal.
* Line 4: Numner of shares submitted. * line 4: Optional lost hashrate, the sum of the effective hashrate of stale and rejected shares. Only
displayed if not zero. Add this to effective hash rate for performance comparison with reference hash rate.
* Lines 5+: Optional number of stale or rejected shares or solved blocks, only displayed if not zero. * Line 5: Numner of shares submitted.
* Lines 6+: Optional number of stale or rejected shares or solved blocks, only displayed if not zero.
### CPU temperature and frequency report ### CPU temperature and frequency report
Another opportunistic report to avoid interrupting mining operation. Temperature reports are dsplayed more Another opportunistic report to avoid interrupting mining operation. Temperature reports are dsplayed more
frequently at higher temperatures and colour coded to draw attention. frequently at higher or rising temperatures and colour coded to draw attention.
* temp >= 80: 30+ seconds, red * temp >= 80: 30+ seconds, red
* 70 <= temp < 80: 60+ seconds, yellow * 70 <= temp < 80: 60+ seconds, yellow
* temp < 70: 120+ seconds, no colour * temp < 70: 120+ seconds, no colour
In addition the report interval will be shorter interval if the new temperature exceeds the previous maximum. The sampling is approximately every 30 seconds and is the temperature of core 0 at that time. It is not an
average or absolute maximum, just a single sample. It does not in any way account for fluctuations or spikes
The sampling is approximately every 30 seconds and is the tyemperature at that time. it does not in any way during the 5 minute period. The reported maximum is the previous highest sampled temperature.
account for fluctuations or spikes during the 5 minute period. The reported maximum is the previous highest sampled temperature.