From 6ca6488320ec7a25891f7ba0d4d2f228a4fed91b Mon Sep 17 00:00:00 2001 From: JayDDee Date: Sun, 1 Mar 2020 20:09:53 -0500 Subject: [PATCH] Updated Home (markdown) --- Home.md | 79 +++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 52 insertions(+), 27 deletions(-) diff --git a/Home.md b/Home.md index 5a9c942..c5eda9b 100644 --- a/Home.md +++ b/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. + +* Line 5: Numner of shares submitted. -* Lines 5+: Optional number of stale or rejected shares or solved blocks, only displayed if not zero. +* 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.