From 23469cb6f5d24dc26c607de5c5ce3b4227efe6ab Mon Sep 17 00:00:00 2001 From: JayDDee Date: Sun, 1 Mar 2020 23:54:22 -0500 Subject: [PATCH] Created Console Logs (markdown) --- Console-Logs.md | 268 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 268 insertions(+) create mode 100644 Console-Logs.md diff --git a/Console-Logs.md b/Console-Logs.md new file mode 100644 index 0000000..7915727 --- /dev/null +++ b/Console-Logs.md @@ -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.