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-02-20 02:02:46 -05:00
parent d18becd5b6
commit 52b77fc9a8
1 changed files with 48 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files

72
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.
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.