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

Created Console Logs (markdown)

JayDDee
2020-03-01 23:54:22 -05:00
parent fe49f8786d
commit 23469cb6f5
1 changed files with 268 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

268
Console-Logs.md Normal file

@@ -0,0 +1,268 @@
# Logs
### Colours
Somes logs and fields are colour coded based on their purpose or to highlight important information
* Blue is used to report networking events, primarilly new jobs.
* Green is used to identify when a share has been accepted.
* Yellow is used when a share is stale or to warn of a minor error that ay affect perforance.
* Red is a more serious error and is used when a share is rejected or when performance is affected or
may cause the miner to stop mining and exit.
The log reports contain a wealth of data that can be used to report actual miner perforance
and provide estimates.
## Start up
The startup messages are very important to ensure best performmance. In particular
the features lists ensure the software is built for the CPU architecture and can
take advantage of all the algo optimizations.
`CPU: AMD Ryzen 7 1700 Eight-Core Processor`
`SW built on Feb 8 2020 with GCC 7.4.0`
`CPU features: AVX2 AES SHA`
`SW features: AVX2 AES SHA`
`Algo features: AVX512 VAES`
`Starting miner with AVX2 AES...`
Line 1: CPU brand and model
Line 2: CPU hardware extensions available
Line 3: Hardware extensions supported by the software build.
Line 4: Extensions supported, to varying degrees, by the mining algorithm
Line 5: Extensions to be used in the current session
Hardware extensions are divided into 3 classes, SIMD, AES and SHA. There are multiple levels in each clash.
Each provides additional CPU instructions and more complex operations. Only the highest ranked feature in
each class is displayed although lower ranking features may also exist and be avaiable. Not all features
have significant improvements and not all combinations are avalable in binary format for Windows.
### SIMD vector support
SSE2: minimum for 128 bit integer vector support, first available on Intel Core2.
SSSE3: Some additional instructions for 128 bit integer vectors, not very significant.
SSE4.2: More 128 bit vector instructions, also not very significant.
AVX: Initial support for 256 bit vectors but no integer support.
AVX2: minimum level for 256 bit integer vector support, first available on Intel Haswell amd AMD Ryzen.
AVX512: a suite of seperate extensions that provide 512 bit integer vector support, first available on
Intel Cascade Lake X HEDT CPUs.
### AES encryption and decryption, aka AES_NI
AES: basic hardware AES support performs AES operations with a single instruction, also requires SSE2,
first available on Intel Westmere.
VAES: Vectored AES, supports 4 parallel AES operations with a single instruction, first available on Intel
Icelake. Also requires AVX512F.
### SHA encryption and decryption, aka SHA_NI
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.
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
will include new estimates for the new block or stratum difficulty.
Using external data the coin can be identifed from its block number.
`[2020-02-07 23:38:22] New block 1293839, job 1d9f, ntime 5e5c2e79`
` lyra2rev3: lyra2v3.mine.zergpool.com:4550`
` Diff: Net 50648, Stratum 26, Target 0.10156`
` TTF @ 2758.00 kh/s: block 2y2d, share 2m38s`
` Net TTF @ 1040.82 Gh/s: 3m29s`
There are 3 forms of this report. New job is a one line report, new block and new stratum diff are up to
4 lines. A new stratum diff also includes a new block and a new block includes a new job.
Line 1 (blue) shows what new information was received from the stratum server.
Line 2 shows the current algo and pool URL.
Line 3:
* 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.
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, this is the traditional hash rate displayed by most miners. It is
calculated by counting the nonces hashed 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.
Line 5, only displayed in single coin pools
* network hashrate estimate is calculated from network difficulty and the number of blocks found during
the mining session.
* observed network block TTF calculated from the number of blocks found during the session.
### 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 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
`[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. 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, 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, also known as height.
* The job id, stratum only, useful to troubleshoot stale shares.
## Share result report
This report is generated when the pool's reply has been received acknowledging the submitted share.
`[2020-02-07 23:59:03] 5 Accepted 5 S0 R0 B0, 400.092 sec (159ms)`
` Diff 0.11393 (0.0853), Block 1044635, Job 1dd6`
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 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
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 will also be incremented and displayed in green but in abbreviated form.
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 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 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.
* 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
` [2020-03-01 16:49:10] scrypt: scryptn2.mine.zergpool.com:3435`
` 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 144`
` Stale 0 1`
Generated aproximately every 5 minutes. The timing is not precise because it is an opportunistic report.
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: (blue) the current algorithm and URL
* Line 2: Sample time for current period and session Actual interval usually between 5 & 6 minutes.
* Line 2: Number of shares submitted per minute. Determines effective hash rate, the same way pool's
calculate hash rate.
* Line 3: Effective hash rate calculated from share rate and stratum difficulty. Should closely follow the
pool's reported hash rate.
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: 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 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 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
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.