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
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.
If the report is also for a new block or a changed stratum difficulty the report
@@ -505,7 +508,9 @@ server.
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.
* 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.
* 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.
* 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
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,
no job id, and no share related estimates. All present fields have the same meaning as the stratum log.
Unlike t stratum version the network hashrate is provided by the wallet and the block TTF is calculated
by the miner.
The getwork new block report is similar to the stratum new block log with a few differences. There is no
stratum difficulty and no job id. "New job" is replaced with "New work". All present fields have the same
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
and is not an estimate. The block TTF is calculated from network hashrate and network difficulty and is
therefore considered correct.
### 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
`
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
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.
@@ -557,7 +567,7 @@ This report is generated when the pool's reply has been received acknowledging t
Line 1:
* 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.
* (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
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
stratum difficulty determines the effective hash rate. This is how pools calculate hash rate.
Stale shares can't be completely avoided. There is always a window beetween a job expiring and the miner
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
at either end.
Line 2:
* Share difficulty. The share difficulty does ot 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
* Share difficulty. The share difficulty does not matter most of the time so is FYI. As long as the share
difficulty is higher than or equal to the target difficulty all shares are considered equal by the
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.
Mostly FYI.
* (share ratio) the fraction of the difficulty required to solve a block, 1.0 or greater solves a block.
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.
* Stratum only, the id of the job associated with the acknowleged share, coloured yellow if the job was stale.
This is obtained from data collected at submit time.
* Job id, stratum only, the id of the job associated with the acknowleged share, coloured yellow if the
job was stale. This is obtained from data collected at submit time.
### Periodic summary report
@@ -593,8 +614,10 @@ This is obtained from data collected at submit time.
Periodic Report 3m45s 14m58s
Share rate 9.84/min 9.68/min
Hash rate 27.03h/s 29.17h/s (22.83h/s)
Lost hash rate 0h/s .17h/s
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.
@@ -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
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
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
* 70 <= temp < 80: 60+ seconds, yellow
* 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 tyemperature at that time. it does not in any way
account for fluctuations or spikes during the 5 minute period. The reported maximum is the previous highest sampled temperature.
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
during the 5 minute period. The reported maximum is the previous highest sampled temperature.