-
Notifications
You must be signed in to change notification settings - Fork 552
Home
Welcome to the cpuminer-opt wiki!
A work in progress
A x86_64 architecture CPU with a minimum of SSE2 support. This includes Intel Core2 and newer and AMD equivalents. In order to take advantage of AES_NI optimizations a CPU with AES_NI is required. This includes Intel Westmere and newer and AMD equivalents. Further optimizations are available on some algoritms for CPUs with AVX and AVX2, Sandybridge and Haswell respectively, as well as AVX512, SHA, and VAES avaible on Icelake.
Older CPUs are supported by cpuminer-multi by TPruvot but at reduced performance.
ARM CPUs are not supported.
64 bit Linux OS. Ubuntu and Fedora based distributions, including Mint and Centos, are known to work and have all dependencies in their repositories. Others may work but may require more effort. Older versions such as Centos 6 don't work due to missing features. 64 bit Windows OS is supported with mingw_w64 and msys or pre-built binaries.
MacOS, OSx and Android are not supported.
Some algorithms may work wallet mining using getwork or GBT, YMMV.
allium Garlicoin
anime Animecoin
argon2 Argon2 coin (AR2)
argon2d250 argon2d-crds, Credits (CRDS)
argon2d500 argon2d-dyn, Dynamic (DYN)
argon2d4096 argon2d-uis, Unitus, (UIS)
axiom Shabal-256 MemoHash
blake Blake-256 (SFR)
blake2b Blake2b 256
blake2s Blake-2 S
blakecoin blake256r8
bmw BMW 256
bmw512 BMW 512
c11 Chaincoin
decred
deep Deepcoin (DCN)
dmd-gr Diamond-Groestl
groestl Groestl coin
hex x16r-hex
hmq1725 Espers
hodl Hodlcoin
jha Jackpotcoin
keccak Maxcoin
keccakc Creative coin
lbry LBC, LBRY Credits
luffa Luffa
lyra2h Hppcoin
lyra2re lyra2
lyra2rev2 lyra2v2
lyra2rev3 lyrav2v3, Vertcoin
lyra2z
lyra2z330 Lyra2 330 rows, Zoin (ZOI)
m7m Magi (XMG)
myr-gr Myriad-Groestl
neoscrypt NeoScrypt(128, 2, 1)
nist5 Nist5
pentablake Pentablake
phi1612 phi
phi2 Luxcoin (LUX)
phi2-lux identical to phi2
pluck Pluck:128 (Supcoin)
polytimos Ninja
power2b MicroBitcoin (MBC)
quark Quark
qubit Qubit
scrypt scrypt(1024, 1, 1) (default)
scrypt:N scrypt(N, 1, 1)
sha256d Double SHA-256
sha256q Quad SHA-256, Pyrite (PYE)
sha256t Triple SHA-256, Onecoin (OC)
sha3d Double keccak256 (BSHA3)
shavite3 Shavite3
skein Skein+Sha (Skeincoin)
skein2 Double Skein (Woodcoin)
skunk Signatum (SIGT)
sonoa Sono
timetravel Machinecoin (MAC)
timetravel10 Bitcore
tribus Denarius (DNR)
vanilla blake256r8vnl (VCash)
veltor (VLT)
whirlpool
whirlpoolx
x11 Dash
x11evo Revolvercoin
x11gost sib (SibCoin)
x12 Galaxie Cash (GCH)
x13 X13
x13bcd bcd
x13sm3 hsr (Hshare)
x14 X14
x15 X15
x16r
x16rv2 Ravencoin (RVN)
x16rt Gincoin (GIN)
x16rt-veil Veil (VEIL)
x16s Pigeoncoin (PGN)
x17
x21s
x22i
x25x
xevan Bitsend (BSD)
yescrypt Globalboost-Y (BSTY)
yescryptr8 BitZeny (ZNY)
yescryptr8g Koto (KOTO)
yescryptr16 Eli
yescryptr32 WAVI
yespower Cryply
yespowerr16 Yenten (YTN)
yespower-b2b generic yespower + blake2b
zr5 Ziftr
Many variations of scrypt based algos can be mine by specifying their parameters:
-
scryptn2: --algo scrypt --param-n 1048576
-
cpupower: --algo yespower --param-key "CPUpower: The number of CPU working or available for proof-of-work mining"
-
power2b: --algo yespower-b2b --param-n 2048 --param-r 32 --param-key "Now I am become Death, the destroyer of worlds"
-
sugarchain: --algo yespower --param-n 2048 -param-r 32 --param-key "Satoshi Nakamoto 31/Oct/2008 Proof-of-work is essentially one-CPU-one-vote"
-
yespoweriots: --algo yespower --param-n 2048 --param-key "Iots is committed to the development of IOT"
-
yespowerlitb: --algo yespower --param-n 2048 --param-r 32 --param-key "LITBpower: The number of LITB working or available for proof-of-work mini"
-
yespoweric: --algo yespower --param-n 2048 --param-r 32 --param-key "IsotopeC"
-
yespowerurx: --algo yespower --param-n 2048 --param-r 32 --param-key "UraniumX"
-
yespowerltncg: --algo yespower --param-n 2048 --param-r 32 --param-key "LTNCGYES"
It is assumed users know how to install packages on their system and be able to compile standard source packages. This is basic Linux and beyond the scope of cpuminer-opt. Regardless compiling is trivial if you follow the instructions.
Make sure you have the basic development packages installed. Here is a good start:
http://askubuntu.com/questions/457526/how-to-install-cpuminer-in-ubuntu
Install any additional dependencies needed by cpuminer-opt. The list below are some of the ones that may not be in the default install and need to be installed manually. There may be others, read the compiler error messages, they will give a clue as to the missing package.
The following command should install everything you need on Debian based distributions such as Ubuntu. Fedora and other distributions may have similar but different package names.
$ sudo apt-get install build-essential automake libssl-dev libcurl4-openssl-dev libjansson-dev libgmp-dev zlib1g-dev git
SHA support on AMD Ryzen CPUs requires gcc version 5 or higher and openssl 1.1.0e or higher. Add one of the following to CFLAGS for SHA support depending on your CPU and compiler version:
"-march=native" is usually the best choice and is used by build.sh
"-march=znver1" for Ryzen 1000 & 2000 series, znver2 for 3000.
"-msha" Add SHA to other tuning options
Additional instructions for static compilalation can be found here: https://lxadm.com/Static_compilation_of_cpuminer Static builds should only considered in a homogeneous HW and SW environment. Local builds will always have the best performance and compatibility.
Download the source code for the latest release from the official repository.
https://github.com/JayDDee/cpuminer-opt/releases
Extract the source code.
$ tar xvzf cpuminer-opt-x.y.z.tar.gz
Alternatively it can be cloned from git.
$ git clone https://github.com/JayDDee/cpuminer-opt.git
It is recomended to Build with default options, this will usuallly produce the best results.
$ ./build.sh
or
$ ./autogen.sh
$ CFLAGS="-O3 -march=native -Wall" ./configure --with-curl
$ make -j n
n is the number of threads.
$ ./cpuminer -a algo -o url -u username -p password
Windows compilation using Visual Studio is not supported. Mingw64 is used on a Linux system (bare metal or virtual machine) to cross-compile cpuminer-opt executable binaries for Windows.
These instructions were written for Debian and Ubuntu compatible distributions but should work on other major distributions as well. However some of the package names or file paths may be different.
It is assumed a Linux system is already available and running. And the user has enough Linux knowledge to find and install packages and follow these instructions.
First it is a good idea to create new user specifically for cross compiling. It keeps all mingw stuff contained and isolated from the rest of the system.
Step by step...
Install necessary packages from the distribution's repositories.
Refer to Linux compile instructions and install required packages.
Additionally, install mingw-w64.
sudo apt-get install mingw-w64
Create a directory for libraries that that need to be compiled in the next stept step. The Suggested location is $HOME/usr/lib/
$ mkdir $HOME/usr/lib
- Download and build other packages for mingw that don't have a mingw64 version available in the repositories.
Download the following source code packages from their respective and respected download locations, copy them to $HOME/usr/lib/ and uncompress them.
openssl curl gmp
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 recommended.
Some instructions insist on running "make check". If make check fails it may still work, YMMV.
You can speed up "make" by using all CPU cores available with "-j n" where n is the number of CPU threads you want to use.
openssl:
./Configure mingw64 shared --cross-compile-prefix=x86_64-w64-mingw32 make
curl:
./configure --with-winssl --with-winidn --host=x86_64-w64-mingw32 make
gmp:
./configure --host=x86_64-w64-mingw32 make
This step is required everytime you login or the commands can be added to .bashrc.
Define some local variables to point to local library.
$ export LOCAL_LIB="$HOME/usr/lib"
'$ export LDFLAGS="-L$LOCAL_LIB/curl/lib/.libs -L$LOCAL_LIB/gmp/.libs -L$LOCAL_LIB/openssl"'
'$ export CONFIGURE_ARGS="--with-curl=$LOCAL_LIB/curl --with-crypto=$LOCAL_LIB/openssl --host=x86_64-w64-mingw32"'
Create a release directory and copy some dll files previously built. This can be done outside of cpuminer-opt and only needs to be done once. If the release directory is in cpuminer-opt directory it needs to be recreated every a source package is decompressed.
$ mkdir release
$ cp /usr/x86_64-w64-mingw32/lib/zlib1.dll release/
$ cp /usr/x86_64-w64-mingw32/lib/libwinpthread-1.dll release/
$ cp /usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/libstdc++-6.dll release/
$ cp /usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/libgcc_s_seh-1.dll release/
$ cp $LOCAL_LIB/openssl/libcrypto-1_1-x64.dll release/
$ cp $LOCAL_LIB/curl/lib/.libs/libcurl-4.dll release/
The following steps need to be done every time a new source package is opened.
Download the latest source code package of cpumuner-opt to your desired location. .zip or .tar.gz, your choice.
https://github.com/JayDDee/cpuminer-opt/releases
Decompress and change to the cpuminer-opt directory.
Create a link to the locally compiled version of gmp.h
ln -s $LOCAL_LIB/gmp-version/gmp.h ./gmp.h
You can use the default compile if you intend to use cpuminer-opt on the same CPU and the virtual machine supports that architecture.
$ ./build.sh
Otherwise you can compile manually while setting options in CFLAGS.
Some common options:
To compile for a specific CPU architecture:
CFLAGS="-O3 -march=znver1 -Wall" ./configure --with-curl
This will compile for AMD Ryzen.
You can compile more generically for a set of specific CPU features if you know what features you want:
CFLAGS="-O3 -maes -msse4.2 -Wall" ./configure --with-curl
This will compile for an older CPU that does not have AVX.
You can find several examples in build-allarch.sh
If you have a CPU with more than 64 threads and Windows 7 or higher you can enable the CPU Groups feature:
-D_WIN32_WINNT==0x0601
Once you have run configure successfully run make with n CPU threads:
make -j n
Copy cpuminer.exe to the release directory, compress and copy the release directory to a Windows system and run cpuminer.exe from the command line.
Run cpuminer
In a command windows change directories to the unzipped release folder. to get a list of all options:
cpuminer.exe --help
Command options are specific to where you mine. Refer to the pool's instructions on how to set them.
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.
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.
-
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.
-
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.
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 number of hashes 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.
[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.
[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.
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.
[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.
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.