|
|
|
|
|
|
|
This is a multi-threaded multi-pool CPU, GPU, and FPGA miner with ATI GPU
|
|
|
|
monitoring, (over)clocking and fanspeed support for bitcoin and derivative
|
|
|
|
coins. Do not use on multiple block chains at the same time!
|
|
|
|
|
|
|
|
This code is provided entirely free of charge by the programmer in his spare
|
|
|
|
time so donations would be greatly appreciated. Please consider using the
|
|
|
|
--donation feature or donate directly to the address below.
|
|
|
|
|
|
|
|
Con Kolivas <kernel@kolivas.org>
|
|
|
|
15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ
|
|
|
|
|
|
|
|
DOWNLOADS:
|
|
|
|
|
|
|
|
http://ck.kolivas.org/apps/cgminer
|
|
|
|
|
|
|
|
GIT TREE:
|
|
|
|
|
|
|
|
https://github.com/ckolivas/cgminer
|
|
|
|
|
|
|
|
Support thread:
|
|
|
|
|
|
|
|
http://bitcointalk.org/index.php?topic=28402.0
|
|
|
|
|
|
|
|
IRC Channel:
|
|
|
|
|
|
|
|
irc://irc.freenode.net/cgminer
|
|
|
|
|
|
|
|
License: GPLv2. See COPYING for details.
|
|
|
|
|
|
|
|
READ EXECUTIVE SUMMARY BELOW FOR FIRST TIME USERS!
|
|
|
|
|
|
|
|
Dependencies:
|
|
|
|
curl dev library http://curl.haxx.se/libcurl/
|
|
|
|
(libcurl4-openssl-dev)
|
|
|
|
curses dev library
|
|
|
|
(libncurses5-dev or libpdcurses on WIN32)
|
|
|
|
pkg-config http://www.freedesktop.org/wiki/Software/pkg-config
|
|
|
|
jansson http://www.digip.org/jansson/
|
|
|
|
(jansson is included in-tree and not necessary)
|
|
|
|
yasm 1.0.1+ http://yasm.tortall.net/
|
|
|
|
(yasm is optional, gives assembly routines for CPU mining)
|
|
|
|
AMD APP SDK http://developer.amd.com/sdks/AMDAPPSDK
|
|
|
|
(This sdk is optional and gives support for GPU mining)
|
|
|
|
AMD ADL SDK http://developer.amd.com/sdks/ADLSDK
|
|
|
|
(This sdk is optional and gives support for ATI GPU monitoring & clocking)
|
|
|
|
|
|
|
|
CGMiner specific configuration options:
|
|
|
|
--enable-cpumining Build with cpu mining support(default disabled)
|
|
|
|
--disable-opencl Override detection and disable building with opencl
|
|
|
|
--disable-adl Override detection and disable building with adl
|
|
|
|
|
|
|
|
Basic *nix build instructions:
|
|
|
|
To build with GPU mining support:
|
|
|
|
Install AMD APP sdk, latest version - there is no official place to
|
|
|
|
install it so just keep track of where it is if you're not installing
|
|
|
|
the include files and library files into the system directory.
|
|
|
|
(Do NOT install the ati amd sdk if you are on nvidia.)
|
|
|
|
To build with GPU monitoring & clocking support:
|
|
|
|
Extract the AMD ADL SDK, latest version - there is also no official
|
|
|
|
place for these files. Copy all the *.h files in the "include"
|
|
|
|
directory into cgminer's ADL_SDK directory.
|
|
|
|
|
|
|
|
The easiest way to install the ATI AMD SPP sdk on linux is to actually put it
|
|
|
|
into a system location. Then building will be simpler. Download the correct
|
|
|
|
version for either 32 bit or 64 bit from here:
|
|
|
|
http://developer.amd.com/sdks/AMDAPPSDK/downloads/Pages/default.aspx
|
|
|
|
|
|
|
|
This will give you a file with a name like AMD-APP-SDK-v2.4-lnx64.tgz
|
|
|
|
|
|
|
|
Then:
|
|
|
|
|
|
|
|
sudo su
|
|
|
|
cd /opt
|
|
|
|
tar xf /path/to/AMD-APP-SDK-v2.4-lnx64.tgz
|
|
|
|
cd /
|
|
|
|
tar xf /opt/AMD-APP-SDK-v2.4-lnx64/icd-registration.tgz
|
|
|
|
ln -s /opt/AMD-APP-SDK-v2.4-lnx64/include/CL /usr/include
|
|
|
|
ln -s /opt/AMD-APP-SDK-v2.4-lnx64/lib/x86_64/* /usr/lib/
|
|
|
|
ldconfig
|
|
|
|
|
|
|
|
If you are on 32 bit, x86_64 in the 2nd last line should be x86
|
|
|
|
|
|
|
|
To actually build:
|
|
|
|
|
|
|
|
./autogen.sh # only needed if building from git repo
|
|
|
|
CFLAGS="-O2 -Wall -march=native" ./configure
|
|
|
|
or if you haven't installed the ati files in system locations:
|
|
|
|
CFLAGS="-O2 -Wall -march=native -I<path to AMD APP include>" LDFLAGS="-L<path to AMD APP lib/x86_64> ./configure
|
|
|
|
make
|
|
|
|
|
|
|
|
If it finds the opencl files it will inform you with
|
|
|
|
"OpenCL: FOUND. GPU mining support enabled."
|
|
|
|
|
|
|
|
Basic WIN32 build instructions (LIKELY OUTDATED INFO. requires mingw32):
|
|
|
|
./autogen.sh # only needed if building from git repo
|
|
|
|
rm -f mingw32-config.cache
|
|
|
|
MINGW32_CFLAGS="-O2 -Wall -msse2" mingw32-configure
|
|
|
|
make
|
|
|
|
./mknsis.sh
|
|
|
|
|
|
|
|
Native WIN32 build instructions (on mingw32, on windows):
|
|
|
|
Install the Microsoft platform SDK
|
|
|
|
Install AMD APP sdk, latest version (only if you want GPU mining)
|
|
|
|
Install AMD ADL sdk, latest version (only if you want GPU monitoring)
|
|
|
|
(Do NOT install the ati amd sdk if you are on nvidia)
|
|
|
|
Install mingw32
|
|
|
|
Install libcurl, copy libcurl.m4 into /mingw/share/aclocal
|
|
|
|
Install pkg-config, copy pkg.m4 into /mingw/share/aclocal
|
|
|
|
Run:
|
|
|
|
autoreconf -fvi
|
|
|
|
CFLAGS="-O2 -msse2" ./configure
|
|
|
|
make
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
Usage instructions: Run "cgminer --help" to see options:
|
|
|
|
|
|
|
|
Usage: . [-atDdGCgIKklmpPQqrRsTouvwOchnV]
|
|
|
|
Options for both config file and command line:
|
|
|
|
--api-description Description placed in the API status header (default: cgminer version)
|
|
|
|
--api-listen Listen for API requests (default: disabled)
|
|
|
|
--api-network Allow API (if enabled) to listen on/for any address (default: only 127.0.0.1)
|
|
|
|
--api-port Port number of miner API (default: 4028)
|
|
|
|
--auto-fan Automatically adjust all GPU fan speeds to maintain a target temperature
|
|
|
|
--auto-gpu Automatically adjust all GPU engine clock speeds to maintain a target temperature
|
|
|
|
--debug|-D Enable debug output
|
|
|
|
--donation <arg> Set donation percentage to cgminer author (0.0 - 99.9) (default: 0.0)
|
|
|
|
--expiry|-E <arg> Upper bound on how many seconds after getting work we consider a share from it stale (default: 120)
|
|
|
|
--failover-only Don't leak work to backup pools when primary pool is lagging
|
|
|
|
--load-balance Change multipool strategy from failover to even load balance
|
|
|
|
--log|-l <arg> Interval in seconds between log output (default: 5)
|
|
|
|
--monitor|-m <arg> Use custom pipe cmd for output messages
|
|
|
|
--net-delay Impose small delays in networking to not overload slow routers
|
|
|
|
--no-longpoll Disable X-Long-Polling support
|
|
|
|
--pass|-p <arg> Password for bitcoin JSON-RPC server
|
|
|
|
--per-device-stats Force verbose mode and output per-device statistics
|
|
|
|
--protocol-dump|-P Verbose dump of protocol-level activities
|
|
|
|
--queue|-Q <arg> Minimum number of work items to have queued (0 - 10) (default: 1)
|
|
|
|
--quiet|-q Disable logging output, display status and errors
|
|
|
|
--real-quiet Disable all output
|
|
|
|
--remove-disabled Remove disabled devices entirely, as if they didn't exist
|
|
|
|
--retries|-r <arg> Number of times to retry before giving up, if JSON-RPC call fails (-1 means never) (default: -1)
|
|
|
|
--retry-pause|-R <arg> Number of seconds to pause, between retries (default: 5)
|
|
|
|
--rotate <arg> Change multipool strategy from failover to regularly rotate at N minutes (default: 0)
|
|
|
|
--round-robin Change multipool strategy from failover to round robin on failure
|
|
|
|
--scan-time|-s <arg> Upper bound on time spent scanning current work, in seconds (default: 60)
|
|
|
|
--sched-start <arg> Set a time of day in HH:MM to start mining (a once off without a stop time)
|
|
|
|
--sched-stop <arg> Set a time of day in HH:MM to stop mining (will quit without a start time)
|
|
|
|
--shares <arg> Quit after mining N shares (default: unlimited)
|
|
|
|
--submit-stale Submit shares even if they would normally be considered stale
|
|
|
|
--syslog Use system log for output messages (default: standard error)
|
|
|
|
--text-only|-T Disable ncurses formatted screen output
|
|
|
|
--url|-o <arg> URL for bitcoin JSON-RPC server
|
|
|
|
--user|-u <arg> Username for bitcoin JSON-RPC server
|
|
|
|
--verbose Log verbose output to stderr as well as status output
|
|
|
|
--userpass|-O <arg> Username:Password pair for bitcoin JSON-RPC server
|
|
|
|
Options for command line only:
|
|
|
|
--config|-c <arg> Load a JSON-format configuration file
|
|
|
|
See example.conf for an example configuration.
|
|
|
|
--help|-h Print this message
|
|
|
|
--version|-V Display version and exit
|
|
|
|
|
|
|
|
|
|
|
|
GPU only options:
|
|
|
|
|
|
|
|
--auto-fan Automatically adjust all GPU fan speeds to maintain a target temperature
|
|
|
|
--auto-gpu Automatically adjust all GPU engine clock speeds to maintain a target temperature
|
|
|
|
--device|-d <arg> Select device to use, (Use repeat -d for multiple devices, default: all)
|
|
|
|
--disable-gpu|-G Disable GPU mining even if suitable devices exist
|
|
|
|
--gpu-threads|-g <arg> Number of threads per GPU (1 - 10) (default: 2)
|
|
|
|
--gpu-engine <arg> GPU engine (over)clock range in Mhz - one value, range and/or comma separated list (e.g. 850-900,900,750-850)
|
|
|
|
--gpu-fan <arg> GPU fan percentage range - one value, range and/or comma separated list (e.g. 25-85,85,65)
|
|
|
|
--gpu-memclock <arg> Set the GPU memory (over)clock in Mhz - one value for all or separate by commas for per card.
|
|
|
|
--gpu-memdiff <arg> Set a fixed difference in clock speed between the GPU and memory in auto-gpu mode
|
|
|
|
--gpu-powertune <arg> Set the GPU powertune percentage - one value for all or separate by commas for per card.
|
|
|
|
--gpu-vddc <arg> Set the GPU voltage in Volts - one value for all or separate by commas for per card.
|
|
|
|
--intensity|-I <arg> Intensity of GPU scanning (d or -10 -> 10, default: d to maintain desktop interactivity)
|
|
|
|
--kernel-path|-K <arg> Specify a path to where the kernel .cl files are (default: "/usr/local/bin")
|
|
|
|
--kernel|-k <arg> Select kernel to use (poclbm or phatk - default: auto)
|
|
|
|
--no-restart Do not attempt to restart GPUs that hang
|
|
|
|
--temp-cutoff <arg> Temperature where a GPU device will be automatically disabled, one value or comma separated list (default: 95)
|
|
|
|
--temp-hysteresis <arg> Set how much the temperature can fluctuate outside limits when automanaging speeds (default: 3)
|
|
|
|
--temp-overheat <arg> Overheat temperature when automatically managing fan and GPU speeds (default: 85)
|
|
|
|
--temp-target <arg> Target temperature when automatically managing fan and GPU speeds (default: 75)
|
|
|
|
--vectors|-v <arg> Override detected optimal vector width (1, 2 or 4)
|
|
|
|
--worksize|-w <arg> Override detected optimal worksize (default: 0)
|
|
|
|
--ndevs|-n Enumerate number of detected GPUs and exit
|
|
|
|
|
|
|
|
|
|
|
|
BitForce only options:
|
|
|
|
|
|
|
|
--scan-serial|-S <arg> Serial port to probe for BitForce device
|
|
|
|
|
|
|
|
|
|
|
|
CPU only options:
|
|
|
|
|
|
|
|
--algo|-a <arg> Specify sha256 implementation for CPU mining:
|
|
|
|
auto Benchmark at startup and pick fastest algorithm
|
|
|
|
c Linux kernel sha256, implemented in C
|
|
|
|
4way tcatm's 4-way SSE2 implementation
|
|
|
|
via VIA padlock implementation
|
|
|
|
cryptopp Crypto++ C/C++ implementation
|
|
|
|
sse2_64 SSE2 64 bit implementation for x86_64 machines
|
|
|
|
sse4_64 SSE4.1 64 bit implementation for x86_64 machines (default: sse2_64)
|
|
|
|
--cpu-threads|-t <arg> Number of miner CPU threads (default: 4)
|
|
|
|
--enable-cpu|-C Enable CPU mining with other mining (default: no CPU mining if other devices exist)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
EXECUTIVE SUMMARY ON USAGE:
|
|
|
|
|
|
|
|
After saving configuration from the menu, you do not need to give cgminer any
|
|
|
|
arguments and it will load your configuration.
|
|
|
|
|
|
|
|
|
|
|
|
Single pool, regular desktop:
|
|
|
|
|
|
|
|
cgminer -o http://pool:port -u username -p password
|
|
|
|
|
|
|
|
Single pool, dedicated miner:
|
|
|
|
|
|
|
|
cgminer -o http://pool:port -u username -p password -I 9
|
|
|
|
|
|
|
|
Single pool, first card regular desktop, 3 other dedicated cards:
|
|
|
|
|
|
|
|
cgminer -o http://pool:port -u username -p password -I d,9,9,9
|
|
|
|
|
|
|
|
Multiple pool, dedicated miner:
|
|
|
|
|
|
|
|
cgminer -o http://pool1:port -u pool1username -p pool1password -o http://pool2:port -u pool2usernmae -p pool2password -I 9
|
|
|
|
|
|
|
|
Add overclocking settings, GPU and fan control for all cards:
|
|
|
|
|
|
|
|
cgminer -o http://pool:port -u username -p password -I 9 --auto-fan --auto-gpu --gpu-engine 750-950 --gpu-memclock 300
|
|
|
|
|
|
|
|
Add overclocking settings, GPU and fan control with different engine settings for 4 cards:
|
|
|
|
|
|
|
|
cgminer -o http://pool:port -u username -p password -I 9 --auto-fan --auto-gpu --gpu-engine 750-950,945,700-930,960 --gpu-memclock 300
|
|
|
|
|
|
|
|
READ WARNINGS AND DOCUMENTATION BELOW ABOUT OVERCLOCKING
|
|
|
|
|
|
|
|
On Linux you virtually always need to export your display settings before
|
|
|
|
starting to get all the cards recognised and/or temperature+clocking working:
|
|
|
|
|
|
|
|
export DISPLAY=:0
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
WHILE RUNNING:
|
|
|
|
|
|
|
|
The following options are available while running with a single keypress:
|
|
|
|
|
|
|
|
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
|
|
|
|
|
|
|
|
P gives you:
|
|
|
|
|
|
|
|
Current pool management strategy: Failover
|
|
|
|
[A]dd pool [R]emove pool [D]isable pool [E]nable pool
|
|
|
|
[C]hange management strategy [S]witch pool [I]nformation
|
|
|
|
|
|
|
|
|
|
|
|
S gives you:
|
|
|
|
|
|
|
|
[L]ongpoll: On
|
|
|
|
[Q]ueue: 1
|
|
|
|
[S]cantime: 60
|
|
|
|
[E]xpiry: 120
|
|
|
|
[R]etries: -1
|
|
|
|
[P]ause: 5
|
|
|
|
[W]rite config file
|
|
|
|
|
|
|
|
|
|
|
|
D gives you:
|
|
|
|
|
|
|
|
Toggle: [D]ebug [N]ormal [S]ilent [V]erbose [R]PC debug
|
|
|
|
[L]og interval [C]lear
|
|
|
|
|
|
|
|
|
|
|
|
Q quits the application.
|
|
|
|
|
|
|
|
|
|
|
|
G gives you something like:
|
|
|
|
|
|
|
|
GPU 0: [124.2 / 191.3 Mh/s] [Q:212 A:77 R:33 HW:0 E:36% U:1.73/m]
|
|
|
|
Temp: 67.0 C
|
|
|
|
Fan Speed: 35% (2500 RPM)
|
|
|
|
Engine Clock: 960 MHz
|
|
|
|
Memory Clock: 480 Mhz
|
|
|
|
Vddc: 1.200 V
|
|
|
|
Activity: 93%
|
|
|
|
Powertune: 0%
|
|
|
|
Last initialised: [2011-09-06 12:03:56]
|
|
|
|
Thread 0: 62.4 Mh/s Enabled ALIVE
|
|
|
|
Thread 1: 60.2 Mh/s Enabled ALIVE
|
|
|
|
|
|
|
|
[E]nable [D]isable [R]estart GPU [C]hange settings
|
|
|
|
Or press any other key to continue
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
Also many issues and FAQs are covered in the forum thread
|
|
|
|
dedicated to this program,
|
|
|
|
http://forum.bitcoin.org/index.php?topic=28402.0
|
|
|
|
|
|
|
|
The output line shows the following:
|
|
|
|
(5s):1713.6 (avg):1707.8 Mh/s | Q:301 A:729 R:8 HW:0 E:242% U:22.53/m
|
|
|
|
|
|
|
|
Each column is as follows:
|
|
|
|
A 5 second exponentially decaying average hash rate
|
|
|
|
An all time average hash rate
|
|
|
|
The number of requested (Queued) work items from the pools
|
|
|
|
The number of Accepted shares
|
|
|
|
The number of Rejected shares
|
|
|
|
The number of HardWare errors
|
|
|
|
The Efficiency defined as number of shares returned / work item
|
|
|
|
The Utility defined as the number of shares / minute
|
|
|
|
|
|
|
|
GPU 1: 73.5C 2551RPM | 427.3/443.0Mh/s | A:8 R:0 HW:0 U:4.39/m
|
|
|
|
|
|
|
|
Each column is as follows:
|
|
|
|
Temperature (if supported)
|
|
|
|
Fanspeed (if supported)
|
|
|
|
A 5 second exponentially decaying average hash rate
|
|
|
|
An all time average hash rate
|
|
|
|
The number of accepted shares
|
|
|
|
The number of rejected shares
|
|
|
|
The number of hardware erorrs
|
|
|
|
The utility defines as the number of shares / minute
|
|
|
|
|
|
|
|
The cgminer status line shows:
|
|
|
|
TQ: 1 ST: 1 SS: 0 DW: 0 NB: 1 LW: 8 GF: 1 RF: 1
|
|
|
|
|
|
|
|
TQ is Total Queued work items.
|
|
|
|
ST is STaged work items (ready to use).
|
|
|
|
SS is Stale Shares discarded (detected and not submitted so don't count as rejects)
|
|
|
|
DW is Discarded Work items (work from block no longer valid to work on)
|
|
|
|
NB is New Blocks detected on the network
|
|
|
|
LW is Locally generated Work items
|
|
|
|
GF is Getwork Fail Occasions (server slow to provide work)
|
|
|
|
RF is Remote Fail occasions (server slow to accept work)
|
|
|
|
|
|
|
|
NOTE: Running intensities above 9 with current hardware is likely to only
|
|
|
|
diminish return performance even if the hash rate might appear better. A good
|
|
|
|
starting baseline intensity to try on dedicated miners is 9. Higher values are
|
|
|
|
there to cope with future improvements in hardware.
|
|
|
|
|
|
|
|
---
|
|
|
|
MULTIPOOL
|
|
|
|
|
|
|
|
FAILOVER STRATEGIES WITH MULTIPOOL:
|
|
|
|
A number of different strategies for dealing with multipool setups are
|
|
|
|
available. Each has their advantages and disadvantages so multiple strategies
|
|
|
|
are available by user choice, as per the following list:
|
|
|
|
|
|
|
|
FAILOVER:
|
|
|
|
The default strategy is failover. This means that if you input a number of
|
|
|
|
pools, it will try to use them as a priority list, moving away from the 1st
|
|
|
|
to the 2nd, 2nd to 3rd and so on. If any of the earlier pools recover, it will
|
|
|
|
move back to the higher priority ones.
|
|
|
|
|
|
|
|
ROUND ROBIN:
|
|
|
|
This strategy only moves from one pool to the next when the current one falls
|
|
|
|
idle and makes no attempt to move otherwise.
|
|
|
|
|
|
|
|
ROTATE:
|
|
|
|
This strategy moves at user-defined intervals from one active pool to the next,
|
|
|
|
skipping pools that are idle.
|
|
|
|
|
|
|
|
LOAD BALANCE:
|
|
|
|
This strategy sends work in equal amounts to all the pools specified. If any
|
|
|
|
pool falls idle, the rest will take up the slack keeping the miner busy.
|
|
|
|
|
|
|
|
---
|
|
|
|
LOGGING
|
|
|
|
|
|
|
|
cgminer will log to stderr if it detects stderr is being redirected to a file.
|
|
|
|
To enable logging simply add 2>logfile.txt to your command line and logfile.txt
|
|
|
|
will contain the logged output at the log level you specify (normal, verbose,
|
|
|
|
debug etc.)
|
|
|
|
|
|
|
|
In other words if you would normally use:
|
|
|
|
./cgminer -o xxx -u yyy -p zzz
|
|
|
|
if you use
|
|
|
|
./cgminer -o xxx -u yyy -p zzz 2>logfile.txt
|
|
|
|
it will log to a file called logfile.txt and otherwise work the same.
|
|
|
|
|
|
|
|
|
|
|
|
There is also the -m option on linux which will spawn a command of your choice
|
|
|
|
and pipe the output directly to that command.
|
|
|
|
|
|
|
|
---
|
|
|
|
OVERCLOCKING WARNING AND INFORMATION
|
|
|
|
|
|
|
|
AS WITH ALL OVERCLOCKING TOOLS YOU ARE ENTIRELY RESPONSIBLE FOR ANY HARM YOU
|
|
|
|
MAY CAUSE TO YOUR HARDWARE. OVERCLOCKING CAN INVALIDATE WARRANTIES, DAMAGE
|
|
|
|
HARDWARE AND EVEN CAUSE FIRES. THE AUTHOR ASSUMES NO RESPONSIBILITY FOR ANY
|
|
|
|
DAMAGE YOU MAY CAUSE OR UNPLANNED CHILDREN THAT MAY OCCUR AS A RESULT.
|
|
|
|
|
|
|
|
The GPU monitoring, clocking and fanspeed control incorporated into cgminer
|
|
|
|
comes through use of the ATI Display Library. As such, it only supports ATI
|
|
|
|
GPUs. Even if ADL support is successfully built into cgminer, unless the card
|
|
|
|
and driver supports it, no GPU monitoring/settings will be available.
|
|
|
|
|
|
|
|
Cgminer supports initial setting of GPU engine clock speed, memory clock
|
|
|
|
speed, voltage, fanspeed, and the undocumented powertune feature of 69x0+ GPUs.
|
|
|
|
The setting passed to cgminer is used by all GPUs unless separate values are
|
|
|
|
specified. All settings can all be changed within the menu on the fly on a
|
|
|
|
per-GPU basis.
|
|
|
|
|
|
|
|
For example:
|
|
|
|
--gpu-engine 950 --gpu-memclock 825
|
|
|
|
|
|
|
|
will try to set all GPU engine clocks to 950 and all memory clocks to 825,
|
|
|
|
while:
|
|
|
|
--gpu-engine 950,945,930,960 --gpu-memclock 300
|
|
|
|
|
|
|
|
will try to set the engine clock of card 0 to 950, 1 to 945, 2 to 930, 3 to
|
|
|
|
960 and all memory clocks to 300.
|
|
|
|
|
|
|
|
AUTO MODES:
|
|
|
|
There are two "auto" modes in cgminer, --auto-fan and --auto-gpu. These can
|
|
|
|
be used independently of each other and are complementary. Both auto modes
|
|
|
|
are designed to safely change settings while trying to maintain a target
|
|
|
|
temperature. By default this is set to 75 degrees C but can be changed with:
|
|
|
|
|
|
|
|
--temp-target
|
|
|
|
e.g.
|
|
|
|
--temp-target 80
|
|
|
|
Sets all cards' target temperature to 80 degrees.
|
|
|
|
|
|
|
|
--temp-target 75,85
|
|
|
|
Sets card 0 target temperature to 75, and card 1 to 85 degrees.
|
|
|
|
|
|
|
|
AUTO FAN:
|
|
|
|
e.g.
|
|
|
|
--auto-fan (implies 85% upper limit)
|
|
|
|
--gpu-fan 25-85,65 --auto-fan
|
|
|
|
|
|
|
|
Fan control in auto fan works off the theory that the minimum possible fan
|
|
|
|
required to maintain an optimal temperature will use less power, make less
|
|
|
|
noise, and prolong the life of the fan. In auto-fan mode, the fan speed is
|
|
|
|
limited to 85% if the temperature is below "overheat" intentionally, as
|
|
|
|
higher fanspeeds on GPUs do not produce signficantly more cooling, yet
|
|
|
|
significanly shorten the lifespan of the fans. If temperature reaches the
|
|
|
|
overheat value, fanspeed will still be increased to 100%. The overheat value
|
|
|
|
is set to 85 degrees by default and can be changed with:
|
|
|
|
|
|
|
|
--temp-overheat
|
|
|
|
e.g.
|
|
|
|
--temp-overheat 75,85
|
|
|
|
Sets card 0 overheat threshold to 75 degrees and card 1 to 85.
|
|
|
|
|
|
|
|
AUTO GPU:
|
|
|
|
e.g.
|
|
|
|
--auto-gpu --gpu-engine 750-950
|
|
|
|
--auto-gpu --gpu-engine 750-950,945,700-930,960
|
|
|
|
|
|
|
|
GPU control in auto gpu tries to maintain as high a clock speed as possible
|
|
|
|
while not reaching overheat temperatures. As a lower clock speed limit,
|
|
|
|
the auto-gpu mode checks the GPU card's "normal" clock speed and will not go
|
|
|
|
below this unless you have manually set a lower speed in the range. Also,
|
|
|
|
unless a higher clock speed was specified at startup, it will not raise the
|
|
|
|
clockspeed. If the temperature climbs, fanspeed is adjusted and optimised
|
|
|
|
before GPU engine clockspeed is adjusted. If fan speed control is not available
|
|
|
|
or already optimal, then GPU clock speed is only decreased if it goes over
|
|
|
|
the target temperature by the hysteresis amount, which is set to 3 by default
|
|
|
|
and can be changed with:
|
|
|
|
--temp-hysteresis
|
|
|
|
If the temperature drops below the target temperature, and engine clock speed
|
|
|
|
is not at the highest level set at startup, cgminer will raise the clock speed.
|
|
|
|
If at any time you manually set an even higher clock speed successfully in
|
|
|
|
cgminer, it will record this value and use it as its new upper limit (and the
|
|
|
|
same for low clock speeds and lower limits). If the temperature goes over the
|
|
|
|
cutoff limit (95 degrees by default), cgminer will completely disable the GPU
|
|
|
|
from mining and it will not be re-enabled unless manually done so. The cutoff
|
|
|
|
temperature can be changed with:
|
|
|
|
|
|
|
|
--temp-cutoff
|
|
|
|
e.g.
|
|
|
|
--temp-cutoff 95,105
|
|
|
|
Sets card 0 cutoff temperature to 95 and card 1 to 105.
|
|
|
|
|
|
|
|
--gpu-memdiff -125
|
|
|
|
This setting will modify the memory speed whenever the GPU clock speed is
|
|
|
|
modified by --auto-gpu. In this example, it will set the memory speed to
|
|
|
|
be 125 Mhz lower than the GPU speed. This is useful for some cards like the
|
|
|
|
6970 which normally don't allow a bigger clock speed difference.
|
|
|
|
|
|
|
|
|
|
|
|
CHANGING SETTINGS:
|
|
|
|
When setting values, it is important to realise that even though the driver
|
|
|
|
may report the value was changed successfully, and the new card power profile
|
|
|
|
information contains the values you set it to, that the card itself may
|
|
|
|
refuse to use those settings. As the performance profile changes dynamically,
|
|
|
|
querying the "current" value on the card can be wrong as well. So when changing
|
|
|
|
values in cgminer, after a pause of 1 second, it will report to you the current
|
|
|
|
values where you should check that your change has taken. An example is that
|
|
|
|
6970 reference cards will accept low memory values but refuse to actually run
|
|
|
|
those lower memory values unless they're within 125 of the engine clock speed.
|
|
|
|
In that scenario, they usually set their real speed back to their default.
|
|
|
|
|
|
|
|
Cgminer reports the so-called "safe" range of whatever it is you are modifying
|
|
|
|
when you ask to modify it on the fly. However, you can change settings to values
|
|
|
|
outside this range. Despite this, the card can easily refuse to accept your
|
|
|
|
changes, or worse, to accept your changes and then silently ignore them. So
|
|
|
|
there is absolutely to know how far to/from where/to it can set things safely or
|
|
|
|
otherwise, and there is nothing stopping you from at least trying to set them
|
|
|
|
outside this range. Being very conscious of these possible failures is why
|
|
|
|
cgminer will report back the current values for you to examine how exactly the
|
|
|
|
card has responded. Even within the reported range of accepted values by the
|
|
|
|
card, it is very easy to crash just about any card, so it cannot use those
|
|
|
|
values to determine what range to set. You have to provide something meaningful
|
|
|
|
manually for cgminer to work with through experimentation.
|
|
|
|
|
|
|
|
STARTUP / SHUTDOWN:
|
|
|
|
When cgminer starts up, it tries to read off the current profile information
|
|
|
|
for clock and fan speeds and stores these values. When quitting cgminer, it
|
|
|
|
will then try to restore the original values. Changing settings outside of
|
|
|
|
cgminer while it's running may be reset to the startup cgminer values when
|
|
|
|
cgminer shuts down because of this.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
API
|
|
|
|
|
|
|
|
If you start cgminer with the "--api-listen" option, it will listen on a
|
|
|
|
simple TCP/IP socket for single string API requests from the same machine
|
|
|
|
running cgminer and reply with a string and then close the socket each time
|
|
|
|
Also, if you add the "--api-network" option, it will accept API requests
|
|
|
|
from any network attached computer.
|
|
|
|
|
|
|
|
The request can be either simple text or JSON.
|
|
|
|
|
|
|
|
If the request is JSON (starts with '{'), it will reply with a JSON formatted
|
|
|
|
response, otherwise it replies with text formatted as described further below.
|
|
|
|
|
|
|
|
The JSON request format required is '{"command":"CMD","parameter":"PARAM"}'
|
|
|
|
(though of course parameter is not required for all requests)
|
|
|
|
where "CMD" is from the "Request" column below and "PARAM" would be e.g.
|
|
|
|
the CPU/GPU number if required.
|
|
|
|
|
|
|
|
The format of each reply (unless stated otherwise) is a STATUS section
|
|
|
|
followed by an optional detail section
|
|
|
|
|
|
|
|
The STATUS section is:
|
|
|
|
|
|
|
|
STATUS=X,Code=N,Msg=string,Description=string|
|
|
|
|
|
|
|
|
STATUS=X Where X is one of:
|
|
|
|
W - Warning
|
|
|
|
I - Informational
|
|
|
|
S - Success
|
|
|
|
E - Error
|
|
|
|
F - Fatal (code bug)
|
|
|
|
|
|
|
|
Code=N
|
|
|
|
Each unique reply has a unigue Code (See api.c - #define MSG_NNNNNN)
|
|
|
|
|
|
|
|
Msg=string
|
|
|
|
Message matching the Code value N
|
|
|
|
|
|
|
|
Description=string
|
|
|
|
This defaults to the cgminer version but is the value of --api-description
|
|
|
|
if it was specified at runtime.
|
|
|
|
|
|
|
|
The list of requests and replies are:
|
|
|
|
|
|
|
|
Request Reply Section Details
|
|
|
|
------- ------------- -------
|
|
|
|
version VERSION CGMiner=cgminer version
|
|
|
|
API=API version
|
|
|
|
|
|
|
|
summary SUMMARY The status summary of the miner
|
|
|
|
e.g. Elapsed=NNN,Found Blocks=N,Getworks=N,...|
|
|
|
|
|
|
|
|
pools POOLS The status of each pool
|
|
|
|
e.g. Pool=0,URL=http://pool.com:6311,Status=Alive,...|
|
|
|
|
|
|
|
|
devs DEVS Each available CPU and GPU with their details
|
|
|
|
e.g. GPU=0,Accepted=NN,MHS av=NNN,...,Intensity=D|
|
|
|
|
|
|
|
|
gpu|N GPU The details of a single GPU number N in the same
|
|
|
|
format and details as for DEVS
|
|
|
|
|
|
|
|
cpu|N CPU The details of a single CPU number N in the same
|
|
|
|
format and details as for DEVS
|
|
|
|
|
|
|
|
gpucount GPUS Count=N| <- the number of GPUs
|
|
|
|
|
|
|
|
cpucount CPUS Count=N| <- the number of CPUs
|
|
|
|
|
|
|
|
gpuenable|N none There is no reply section just the STATUS section
|
|
|
|
stating the results of the enable request
|
|
|
|
|
|
|
|
gpudisable|N none There is no reply section just the STATUS section
|
|
|
|
stating the results of the disable request
|
|
|
|
|
|
|
|
gpurestart|N none There is no reply section just the STATUS section
|
|
|
|
stating the results of the restart request
|
|
|
|
|
|
|
|
quit none There is no status section but just a single "BYE|"
|
|
|
|
reply before cgminer quits
|
|
|
|
|
|
|
|
When you enable, disable or restart a GPU, you will also get Thread messages in
|
|
|
|
the cgminer status window
|
|
|
|
|
|
|
|
Obviously, the JSON format is simply just the names as given before the '='
|
|
|
|
with the values after the '='
|
|
|
|
|
|
|
|
If you enable cgminer debug (-D or --debug) you will also get messages showing
|
|
|
|
details of the requests received and the replies
|
|
|
|
|
|
|
|
There are included 4 program examples for accessing the API:
|
|
|
|
|
|
|
|
api-example.php - a php script to access the API
|
|
|
|
usAge: php api-example.php command
|
|
|
|
by default it sends a 'summary' request to the miner at 127.0.0.1:4028
|
|
|
|
If you specify a command it will send that request instead
|
|
|
|
You must modify the line "$socket = getsock('127.0.0.1', 4028);" at the
|
|
|
|
beginning of "function request($cmd)" to change where it looks for cgminer
|
|
|
|
|
|
|
|
API.java/API.class
|
|
|
|
a java program to access the API (with source code)
|
|
|
|
usAge is: java API command address port
|
|
|
|
Any missing or blank parameters are replaced as if you entered:
|
|
|
|
java API summary 127.0.0.1 4028
|
|
|
|
|
|
|
|
api-example.c - a 'C' program to access the API (with source code)
|
|
|
|
usAge: api-example [command [ip/host [port]]]
|
|
|
|
again, as above, missing or blank parameters are replaced as if you entered:
|
|
|
|
api-example summary 127.0.0.1 4028
|
|
|
|
|
|
|
|
miner.php - an example web page to access the API
|
|
|
|
This includes buttons to enable, disable and restart the GPUs and also to
|
|
|
|
quit cgminer
|
|
|
|
You must modify the 2 lines near the top to change where it looks for cgminer
|
|
|
|
$miner = '127.0.0.1'; # hostname or IP address
|
|
|
|
$port = 4028;
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
FAQ
|
|
|
|
|
|
|
|
Q: cgminer segfaults when I change my shell window size.
|
|
|
|
A: Older versions of libncurses have a bug to do with refreshing a window
|
|
|
|
after a size change. Upgrading to a new version of curses will fix it.
|
|
|
|
|
|
|
|
Q: Can I mine on servers from different networks (eg smartcoin and bitcoin) at
|
|
|
|
the same time?
|
|
|
|
A: No, cgminer keeps a database of the block it's working on to ensure it does
|
|
|
|
not work on stale blocks, and having different blocks from two networks would
|
|
|
|
make it invalidate the work from each other.
|
|
|
|
|
|
|
|
Q: Can I change the intensity settings individually for each GPU?
|
|
|
|
A: Yes, pass a list separated by commas such as -I d,4,9,9
|
|
|
|
|
|
|
|
Q: Can I put multiple pools in the config file?
|
|
|
|
A: Yes, check the example.conf file. Alternatively, set up everything either on
|
|
|
|
the command line or via the menu after startup and choose settings->write
|
|
|
|
config file and the file will be loaded one each startup.
|
|
|
|
|
|
|
|
Q: The build fails with gcc is unable to build a binary.
|
|
|
|
A: Remove the "-march=native" component of your CFLAGS as your version of gcc
|
|
|
|
does not support it.
|
|
|
|
|
|
|
|
Q: The CPU usage is high.
|
|
|
|
A: The ATI drivers after 11.6 have a bug that makes them consume 100% of one
|
|
|
|
CPU core unnecessarily so downgrade to 11.6. Binding cgminer to one CPU core on
|
|
|
|
windows can minimise it to 100% (instead of more than one core). Driver version
|
|
|
|
11.11 on linux and 11.12 on windows appear to have fixed this issue.
|
|
|
|
|
|
|
|
Q: Can you implement feature X?
|
|
|
|
A: I can, but time is limited, and people who donate are more likely to get
|
|
|
|
their feature requests implemented.
|
|
|
|
|
|
|
|
Q: My GPU hangs and I have to reboot it to get it going again?
|
|
|
|
A: The more aggressively the mining software uses your GPU, the less overclock
|
|
|
|
you will be able to run. You are more likely to hit your limits with cgminer
|
|
|
|
and you will find you may need to overclock your GPU less aggressively. The
|
|
|
|
software cannot be responsible and make your GPU hang directly. If you simply
|
|
|
|
cannot get it to ever stop hanging, try decreasing the intensity, and if even
|
|
|
|
that fails, try changing to the poclbm kernel with -k poclbm, though you will
|
|
|
|
sacrifice performance. cgminer is designed to try and safely restart GPUs as
|
|
|
|
much as possible, but NOT if that restart might actually crash the rest of the
|
|
|
|
GPUs mining, or even the machine. It tries to restart them with a separate
|
|
|
|
thread and if that separate thread dies, it gives up trying to restart any more
|
|
|
|
GPUs.
|
|
|
|
|
|
|
|
Q: Work keeps going to my backup pool even though my primary pool hasn't
|
|
|
|
failed?
|
|
|
|
A: Cgminer checks for conditions where the primary pool is lagging and will
|
|
|
|
pass some work to the backup servers under those conditions. The reason for
|
|
|
|
doing this is to try its absolute best to keep the GPUs working on something
|
|
|
|
useful and not risk idle periods. You can disable this behaviour with the
|
|
|
|
option --failover-only.
|
|
|
|
|
|
|
|
Q: Is this a virus?
|
|
|
|
A: Cgminer is being packaged with other trojan scripts and some antivirus
|
|
|
|
software is falsely accusing cgminer.exe as being the actual virus, rather
|
|
|
|
than whatever it is being packaged with. If you installed cgminer yourself,
|
|
|
|
then you do not have a virus on your computer. Complain to your antivirus
|
|
|
|
software company.
|
|
|
|
|
|
|
|
Q: How does the donation feature work and how does it affect my shares?
|
|
|
|
A: The donation feature is disabled by default and only does anything once
|
|
|
|
enabled. It queries the author's website for login credentials and contributes
|
|
|
|
up to a proportion of work to the author's account. While the overall
|
|
|
|
accepted/rejected rates will include this work, none of these will appear in
|
|
|
|
your own accounts. On exiting, the summary will tell you how many shares were
|
|
|
|
contributed to the author.
|
|
|
|
|
|
|
|
Q: Can you modify the display to include more of one thing in the output and
|
|
|
|
less of another, or can you change the quiet mode or can you add yet another
|
|
|
|
output mode?
|
|
|
|
A: Everyone will always have their own view of what's important to monitor.
|
|
|
|
The defaults are very sane and I have very little interest in changing this
|
|
|
|
any further.
|
|
|
|
|
|
|
|
Q: Can you change the autofan/autogpu to change speeds in a different manner?
|
|
|
|
A: The defaults are sane and safe. I'm not interested in changing them
|
|
|
|
further. The starting fan speed is set to 85% in auto-fan mode as a safety
|
|
|
|
precaution, but if a specific fan speed has been set, it will use that first
|
|
|
|
before adjusting automatically.
|
|
|
|
|
|
|
|
Q: The fanspeed starts at 85% with --auto-fan. Can I set it lower?
|
|
|
|
A: The initial fanspeed will always start at 85% unless you choose your own
|
|
|
|
value with --gpu-fan. In this case it will use the value you give it with
|
|
|
|
--gpu-fan as the first fanspeed.
|
|
|
|
|
|
|
|
Q: Why is my efficiency above/below 100%?
|
|
|
|
A: Efficiency simply means how many shares you return for the amount of work
|
|
|
|
you request. It does not correlate with efficient use of your hardware, and is
|
|
|
|
a measure of a combination of hardware speed, block luck, pool design and other
|
|
|
|
factors.
|
|
|
|
|
|
|
|
Q: What are the best parameters to pass for X pool/hardware/device.
|
|
|
|
A: Virtually always, the DEFAULT parameters give the best results. Most user
|
|
|
|
defined settings lead to worse performance. The ONLY thing most users should
|
|
|
|
need to set is the Intensity.
|
|
|
|
|
|
|
|
Q: What happened to CPU mining?
|
|
|
|
A: Being increasingly irrelevant for most users, and a maintenance issue, it is
|
|
|
|
no longer under active development and will not be supported unless someone
|
|
|
|
steps up to help maintain it. No binary builds supporting CPU mining will be
|
|
|
|
released but CPU mining can be built into cgminer when it is compiled.
|
|
|
|
|
|
|
|
Q: I upgraded my ATI driver/SDK/cgminer and my hashrate suddenly dropped!
|
|
|
|
A: The hashrate performance in cgminer is tied to the version of the ATI SDK
|
|
|
|
that is installed only for the very first time cgminer is run. This generates
|
|
|
|
binaries that are used by the GPU every time after that. Any upgrades to the
|
|
|
|
SDK after that time will have no effect on the binaries. However, if you
|
|
|
|
install a fresh version of cgminer, and have since upgraded your SDK, new
|
|
|
|
binaries will be built. It is known that the 2.6 ATI SDK has a huge hashrate
|
|
|
|
penalty on generating new binaries. It is recommended to not use this SDK at
|
|
|
|
this time.
|
|
|
|
|
|
|
|
Q: Which ATI SDK is the best for cgminer?
|
|
|
|
A: At the moment, versions 2.4 and 2.5 work the best. If you are forced to use
|
|
|
|
the 2.6 SDK, -v 1 -w 64 might help, along with not decreasing your memroy clock
|
|
|
|
speed.
|
|
|
|
|
|
|
|
Q: ATI 79XX support?
|
|
|
|
A: Pending.
|
|
|
|
|
|
|
|
Q: GUI version?
|
|
|
|
A: No. The RPC interface makes it possible for someone else to write one
|
|
|
|
though.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
This code is provided entirely free of charge by the programmer in his spare
|
|
|
|
time so donations would be greatly appreciated. Please consider using the
|
|
|
|
--donation feature or donate directly to the address below.
|
|
|
|
|
|
|
|
Con Kolivas <kernel@kolivas.org>
|
|
|
|
15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ
|