Updated Console Logs (markdown)

JayDDee
2020-03-06 19:35:36 -05:00
parent dfdbaaf6b1
commit 3b6bb95530

@@ -1,23 +1,36 @@
# Logs
Appropriate logging can be be viewed as an art. Logs should be concise and clear and be understandable
to newbie users as well as be useful to experienced users. Some of the logs may seem cryptic at first
but an effort was made to make them intuitive.
The application's sensitivity to CPU usage was a fcactor in log design. Perodic logs are not schedule
driven, the are opportunistic in that they look for opportunities to generate log with minimal impact.
Conditinal logs are avoided in high running code where testing the condition every iteration adds CPU ovedrhead.
The information is dense, the logs contain a lot of information in a small report. Every piece of data
has a puspose. Many fields can be correlated with other logs and fields and external data (pools, blochain
explorers, etc) to provide a more complete picture of actual mining performance.
The descriptions below will help understanding the significance of each field and how it can be used
to assess mining performance and help identify problems and aid troubleshooting.
### 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.
* Yellow is used when a share is stale or to warn of a minor error that may 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 performance. In particular
the features lists ensure the software is built for the CPU architecture and can
take advantage of all the algo optimizations.
take advantage of all the optimizations.
`CPU: AMD Ryzen 7 1700 Eight-Core Processor`
@@ -38,7 +51,7 @@ take advantage of all the algo optimizations.
* 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.
Hardware extensions are divided into 3 classes, SIMD, AES and SHA. Each class can have multiple levels.
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.
@@ -191,7 +204,7 @@ Line 2:
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.
* (share ratio) the fraction of the net 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.
@@ -250,6 +263,11 @@ displayed if not zero. Add this to effective hash rate for performance compariso
* Lines 6+: Optional number of stale or rejected shares or solved blocks, only displayed if not zero.
* Last Line: highest and lowest accepted share during the session. The lowest share shoulkd aproach the
target diff over time. If it does not it likely affects performance and shpuld be reported. The highest
share is FYI and provides perspective on solo mining expectations.
## CPU temperature and frequency report
Another opportunistic report to avoid interrupting mining operation. Temperature reports are dsplayed more