From 52b77fc9a817dbe0af5cddedc4834e574df7df23 Mon Sep 17 00:00:00 2001 From: JayDDee Date: Thu, 20 Feb 2020 02:02:46 -0500 Subject: [PATCH] Updated Home (markdown) --- Home.md | 72 ++++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 48 insertions(+), 24 deletions(-) diff --git a/Home.md b/Home.md index 94ceffd..b5e8353 100644 --- a/Home.md +++ b/Home.md @@ -243,7 +243,7 @@ sudo apt-get install mingw-w64 version available in the repositories. Download the following source code packages from their respective and -respected download locations, copy them to ~/usr/lib/ and uncompress them. +respected download locations, copy them to $HOME/usr/lib/ and uncompress them. openssl curl @@ -253,7 +253,7 @@ In most cases the latest vesrion is ok but it's safest to download the same major and minor version as included in your distribution. Run the following commands or follow the supplied instructions. -Do not run "make install" unless you are using ~/usr/lib, which isn't +Do not run "make install" unless you are using /usr/lib, which isn't recommended. Some instructions insist on running "make check". If make check fails @@ -474,8 +474,9 @@ Line 2 shows the current algo and pool URL. Line 3: -* Network difficulty -* Stratum difficulty, provide by the server +* Network difficulty, provided by the server, the minimum difficulty hash required to solve a block. +* Stratum difficulty, provide by the server, determines the value of a share and, combined with a target +factor (hard coded for each algo) determines the minimum share difficulty. * Target difficulty, the minimum acceptible share difficulty, calculated from data received from the stratum server. @@ -483,7 +484,7 @@ 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. -* Block TTF estimate calculated from miner's reference hashrate 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. Line 5, only displayed in single coin pools @@ -506,7 +507,7 @@ match up with a share result counter. * CPU thread that submitted the share, FYI Only. -* Lane of the CPU thread that submitted theshare, only displayed when hashing multiple data streams in +* Lane of the CPU thread that submitted the share, only displayed when hashing multiple data streams in parallel (N way). FYI only. * job id is displayed to help diagnose stale shares caused by latency. @@ -524,24 +525,34 @@ 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 the sum of accepted, stale and rejected shares, collectivley known as replied or acknowledged shares. -* "Accepted", "Stale", "Rejected", "BLOCK SOLVED" counters. The currently incremented counter is coloured green -if accepted, yellow if stale, red if rejected, magenta if it solved a block. The other counters will be + +* (green)"Accepted", (yellow)"Stale", (red)"Rejected", (magenta)"BLOCK SOLVED" counters. The currently +incremented counter is coloured appropriately and displayed in long form. The other counters will be displayed in their short form with no colouring. Solved blocks also count as accepted therefore the accepted -count with also be incremented and displayed in green in abbreviated form. The block count will be displayed -in mmagenta in long form. -* The time in seconds since the last share -* (Latency ms) Time from submission to reply including transmission time and processing at either end. +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. + +* (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 pool server based on the stratum difficulty. + * (share ratio %) the percentage of the difficulty required to find a block, 100% or greater solves a block. -* The current block height, coloured magenta when the block is found by the miner. -* The id of the job used to submit the share, coloured yellow if the job was stale. +Also FYI only. + +* The current block height (block number), coloured magenta when the block is found by the miner. + +* 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 and deoends on proper synchronization (submit count == reply count) for +correctness. ### Periodic summary report @@ -560,21 +571,34 @@ It is produced when it is convenient in order to miminize the impact on mining. The report contains data for the 5 minute interval in the left column, and session statistics in the right. * Line 1: Sample time for current period and session -* Line 2: Number of shares submitted per minute -* Line 3: Hash rate calculated from share rate and stratum difficulty +Actual interval usually between 5 & 6 minutes. + +* Line 2: Number of shares submitted per minute. +Determines effective hash rate, also used by the pool to report hash rate. + +* Line 3: Effective hash rate calculated from share rate and stratum difficulty. + +Effective hash rate discounts rejected shares which are reported as lost hash rate. +The effective hash rate is the real performance of the miner once luck is factored in. It is also most +closely correlated with the pool's reported hash rate. The effective hash rate will fluctuate above and +below the miner reference hash rate according to luck (ie share rate). A low share rate will increase +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. + * Lines 5+: 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. +frequently at higher temperatures and colour coded to draw attention. -* temp > 80: 30 seconds, red -* 70 <= temp <= 80: 1 minute, yellow -* t < 70: 2 minutes, no colour +* temp >= 80: 30+ seconds, red +* 70 <= temp < 80: 60+ seconds, yellow +* temp < 70: 120+ seconds, no colour -In addition the report will in a shorter interval if the new temperature exceeds the previous maximum. +In addition the report interval will be shorter interval if the new temperature exceeds the previous maximum. -The sampling is approximately every 30 seconds. The reported maximum it the previous maximum temperature -prirt to the current sample and does not represent the actual instantaneous maximum temperature. \ No newline at end of file +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.