GOSTSec
/
sgminer
mirror of https://github.com/GOSTSec/sgminer
1
0
Fork 0
Code Issues Releases Wiki Activity
Browse Source

Update READMEs.

nfactor-troky
Noel Maersk 11 years ago
parent
d0070c0424
commit
593080d972
5 changed files with 567 additions and 1403 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 297
      ASIC-README
  2. 178
      FAQ
  3. 271
      FPGA-README
  4. 835
      README
  5. 389
      README.md

297
ASIC-README
Unescape View File

@ -1,297 +0,0 @@ @@ -1,297 +0,0 @@
SUPPORTED DEVICES
Currently supported devices include the Avalon (including BitBurner and
Klondike), the Butterfly Labs SC range of devices, the ASICMINER block
erupters, the BF1 (bitfury) USB (red and blue) devices, KnCminer Mercury,
Saturn and Jupiter devices, and upcoming Hashfast devices.
No COM ports on windows or TTY devices will be used by cgminer as it
communicates directly with them via USB so it is normal for them to not exist or
be disconnected when cgminer is running.
The BFL devices should come up as one of the following:
BAJ: BFL ASIC Jalapeño
BAL: BFL ASIC Little Single
BAS: BFL ASIC Single
BAM: BFL ASIC Minirig
BFL devices need the --enable-bflsc option when compiling cgminer yourself.
Avalon will come up as AVA.
Avalon devices need the --enable-avalon option when compiling cgminer.
Klondike will come up as KLN.
Klondike devices need the --enable-klondike option when compiling cgminer.
ASICMINER block erupters will come up as AMU.
ASICMINER devices need the --enable-icarus option when compiling cgminer.
Also note that the AMU is managed by the Icarus driver which is detailed
in the FPGA-README. Configuring them uses the same mechanism as outlined
below for getting started with butterfly labs ASICs.
BITFURY devices
Bitfury devices need the --enable-bitfury option when compiling cgminer.
Currently only the BPMC BF1 devices AKA redfury/bluefury are supported and
come up as BF1. There are no options available for them. Bitfury device are
also set up as per the butterfly labs ASICs below.
GETTING STARTED WITH BUTTERFLY LABS ASICS
Unlike other software, cgminer uses direct USB communication instead of the
ancient serial USB communication to be much faster, more reliable and use a
lot less CPU. For this reason, setting up for mining with cgminer on these
devices requires different drivers.
WINDOWS:
On windows, the direct USB support requires the installation of a WinUSB
driver (NOT the ftdi_sio driver), and attach it to the Butterfly labs device.
The easiest way to do this is to use the zadig utility which will install the
drivers for you and then once you plug in your device you can choose the
"list all devices" from the "option" menu and you should be able to see the
device as something like: "BitFORCE SHA256 SC". Choose the install or replace
driver option and select WinUSB. You can either google for zadig or download
it from the cgminer directory in the DOWNLOADS link above.
When you first switch a device over to WinUSB with zadig and it shows that
correctly on the left of the zadig window, but it still gives permission
errors, you may need to unplug the USB miner and then plug it back in. Some
users may need to reboot at this point.
LINUX:
On linux, the direct USB support requires no drivers at all. However due to
permissions issues, you may not be able to mine directly on the devices as a
regular user without giving the user access to the device or by mining as
root (administrator). In order to give your regular user access, you can make
him a member of the plugdev group with the following commands:
sudo usermod -G plugdev -a `whoami`
If your distribution does not have the plugdev group you can create it with:
sudo groupadd plugdev
In order for the BFL devices to instantly be owned by the plugdev group and
accessible by anyone from the plugdev group you can copy the file
"01-cgminer.rules" from the cgminer archive into the /etc/udev/rules.d
directory with the following command:
sudo cp 01-cgminer.rules /etc/udev/rules.d/
After this you can either manually restart udev and re-login, or more easily
just reboot.
ASIC SPECIFIC COMMANDS
--avalon-auto Adjust avalon overclock frequency dynamically for best hashrate
--avalon-cutoff <arg> Set avalon overheat cut off temperature (default: 60)
--avalon-fan <arg> Set fanspeed percentage for avalon, single value or range (default: 20-100)
--avalon-freq <arg> Set frequency range for avalon-auto, single value or range
--avalon-options <arg> Set avalon options baud:miners:asic:timeout:freq
--avalon-temp <arg> Set avalon target temperature (default: 50)
--bflsc-overheat <arg> Set overheat temperature where BFLSC devices throttle, 0 to disable (default: 90)
--bitburner-fury-options <arg> Override avalon-options for BitBurner Fury boards baud:miners:asic:timeout:freq
--bitburner-fury-voltage <arg> Set BitBurner Fury core voltage, in millivolts
--bitburner-voltage <arg> Set BitBurner (Avalon) core voltage, in millivolts
--klondike-options <arg> Set klondike options clock:temptarget
AVALON AND BITBURNER DEVICES
Currently all known Avalon devices come with their own operating system and
a preinstalled version of cgminer as part of the flash firmware, based on the
most current cgminer version so no configuration should be necessary. It is
possible to plug a USB cable from a PC into the Avalon device and mine using
cgminer as per any other device. It will autodetect and hotplug using default
options. You can customise the avalon behaviour by using the avalon-options
command, and adjust its fan control-temperature relationship with avalon-temp.
By default the avalon will also cut off when its temperature reaches 60
degrees.
All current BitBurner devices (BitBurner X, BitBurner XX and BitBurner Fury)
emulate Avalon devices, whether or not they use Avalon chips.
Avalon commands:
--avalon-auto Adjust avalon overclock frequency dynamically for best hashrate
--avalon-cutoff <arg> Set avalon overheat cut off temperature (default: 60)
--avalon-fan <arg> Set fanspeed percentage for avalon, single value or range (default: 20-100)
--avalon-freq <arg> Set frequency range for avalon-auto, single value or range
--avalon-options <arg> Set avalon options baud:miners:asic:timeout:freq
--avalon-temp <arg> Set avalon target temperature (default: 50)
--bitburner-fury-options <arg> Override avalon-options for BitBurner Fury boards baud:miners:asic:timeout:freq
--bitburner-fury-voltage <arg> Set BitBurner Fury core voltage, in millivolts
--bitburner-voltage <arg> Set BitBurner (Avalon) core voltage, in millivolts
Avalon auto will enable dynamic overclocking gradually increasing and
decreasing the frequency till the highest hashrate that keeps hardware errors
under 2% is achieved. This WILL run your avalon beyond its normal specification
so the usual warnings apply. When avalon-auto is enabled, the avalon-options
for frequency and timeout are used as the starting point only.
eg:
--avalon-fan 50
--avalon-fan 40-80
By default the avalon fans will be adjusted to maintain a target temperature
over a range from 20 to 100% fanspeed. avalon-fan allows you to limit the
range of fanspeeds to a single value or a range of values.
eg:
--avalon-freq 300-350
In combination with the avalon-auto command, the avalon-freq command allows you
to limit the range of frequencies which auto will adjust to.
eg:
--avalon-temp 55
This will adjust fanspeed to keep the temperature at or slightly below 55.
If you wish the fans to run at maximum speed, setting the target temperature
very low such as 0 will achieve this. This option can be added to the "More
options" entry in the web interface if you do not have a direct way of setting
it.
eg:
--avalon-cutoff 65
This will cut off the avalon should it get up to 65 degrees and will then
re-enable it when it gets to the target temperature as specified by avalon-temp.
eg:
--avalon-options 115200:24:10:45:282
The values are baud : miners : asic count : timeout : frequency.
Baud:
The device is pretty much hard coded to emulate 115200 baud so you shouldn't
change this.
Miners:
Most Avalons are 3 module devices, which come to 24 miners. 4 module devices
would use 32 here.
For BitBurner X and BitBurner XX devices you should use twice the number of
boards in the stack. e.g. for a two-board stack you would use 4. For
BitBurner Fury devices you should use the total number of BitFury chips in the
stack (i.e. 16 times the number of boards). e.g. for a two-board stack you
would use 32.
Asic count:
Virtually all have 10, so don't change this. BitBurner devices use 10 here
even if the boards have some other number of ASICs.
Timeout:
This is how long the device will work on a work item before accepting new work
to replace it. It should be changed according to the frequency (last setting).
It is possible to set this a little lower if you are trying to tune for short
block mining (eg p2pool) but much lower and the device will start creating
duplicate shares.
A value of 'd' means cgminer will calculate it for you based on the frequency
Sample settings for valid different frequencies (last 2 values):
34:375 *
36:350 *
39:325 *
43:300
45:282 (default)
47:270
50:256
Frequency:
This is the clock speed of the devices. For Avalon devices, only specific
values work, 256, 270, 282 (default), 300, 325, 350 and 375. For BitBurner
devices, other values can be used.
Note that setting a value with an asterisk next to it will be using your
avalon outside its spec and you do so at your own risk.
The default frequency for BitBurner X and BitBurner XX boards is 282. The
default frequency for BitBurner Fury boards is 256. Overclocking is
possible - please consult the product documentation and/or manufacturer for
information on safe values. Values outside this range are used at your own
risk. Underclocking is also possible, at least with the X and XX boards.
eg:
--bitburner-fury-options <arg> Override avalon-options for BitBurner Fury boards baud:miners:asic:timeout:freq
This option takes the same format as --avalon-options. When specified, it
will be used for BitBurner Fury boards in preference to the values specified
in --avalon-options. (If not specified, BitBurner Fury boards will be
controlled by the values used in --avalon options.) See --avalon-options for
a detailed description of the fields.
This option is particularly useful when using a mixture of different BitBurner
devices as BitBurner Fury devices generally require significantly different
clock frequencies from Avalon-based devices. This option is only available
for boards with recent firmware that are recognized by cgminer as BBF.
eg:
--bitburner-fury-voltage <arg> Set BitBurner Fury core voltage, in millivolts
Sets the core voltage for the BitBurner Fury boards. The default value is
900. Overvolting is possible - please consult the product documentation
and/or manufaturer about the safe range of values. Values outside this range
are used at your own risk.
This option is only available for boards with recent firmware that are
recognized by cgminer as BBF. For boards recognized as BTB, see
--bitburner-voltage
eg:
--bitburner-voltage <arg> Set BitBurner (Avalon) core voltage, in millivolts
Sets the core voltage for the Avalon-based BitBurner X and BitBurner XX
boards. The default value is 1200. Overvolting and undervolting is
possible - please consult the product documentation and/or the manufacturer
for information about the safe range. Values outside this range are used at
your own risk.
Older BitBurner Fury firmware emulates a BitBurner XX board and is identified
by cgminer as BTB. On these devices, --bitburner-voltage is used to control
the voltage of the BitBurner Fury board. The actual core voltage will be
300mV less than the requested voltage, so to run a BitBurner Fury board at
950mV use --bitburner-voltage 1250. The default value of 1200 therefore
corresponds to the default core voltage of 900mV.
If you use the full curses based interface with Avalons you will get this
information:
AVA 0: 22/ 46C 2400R
The values are:
ambient temp / highest device temp lowest detected ASIC cooling fan RPM.
Use the API for more detailed information than this.
BFLSC Devices
--bflsc-overheat <arg> Set overheat temperature where BFLSC devices throttle, 0 to disable (default: 90)
This will allow you to change or disable the default temperature where cgminer
throttles BFLSC devices by allowing them to temporarily go idle.
---
This code is provided entirely free of charge by the programmer in his spare
time so donations would be greatly appreciated. Please consider donating to the
address below.
Con Kolivas <kernel@kolivas.org>
15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ

178
FAQ
Unescape View File

@ -0,0 +1,178 @@ @@ -0,0 +1,178 @@
FAQ
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 configure cgminer to mine with different login credentials or pools
for each separate device?
A: No.
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: 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: 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. They seem to be flagging even source code now from cgminer
as viruses, even though text source files can't do anything by themself.
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: 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 for GPUs.
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. No binary builds
supporting CPU mining will be released. Virtually all remaining users of CPU
mining are as back ends for illegal botnets. The main reason cgminer is being
inappopriately tagged as a virus by antivirus software is due to the trojans
packaging a CPU mining capable version of it. There is no longer ANY CPU mining
code in cgminer. If you are mining bitcoin with CPU today, you are spending
1000x more in electricity costs than you are earning in bitcoin.
Q: GUI version?
A: No. The RPC interface makes it possible for someone else to write one
though.
Q: I'm having an issue. What debugging information should I provide?
A: Start cgminer with your regular commands and add -D -T --verbose and provide
the full startup output and a summary of your hardware, operating system, ATI
driver version and ATI stream version.
Q: Why don't you provide win64 builds?
A: Win32 builds work everywhere and there is precisely zero advantage to a
64 bit build on windows.
Q: Is it faster to mine on windows or linux?
A: It makes no difference. It comes down to choice of operating system for
their various features. Linux offers much better long term stability and
remote monitoring and security, while windows offers you overclocking tools
that can achieve much more than cgminer can do on linux.
Q: Can I mine with cgminer on a MAC?
A: cgminer will compile on OSX, but the performance of GPU mining is
compromised due to the opencl implementation on OSX, there is no temperature
or fanspeed monitoring, and the cooling design of most MACs, despite having
powerful GPUs, will usually not cope with constant usage leading to a high
risk of thermal damage. It is highly recommended not to mine on a MAC unless
it is to a USB device.
Q: I'm trying to mine litecoin but cgminer shows MH values instead of kH and
submits no shares?
A: Add the --scrypt parameter.
Q: I switch users on windows and my mining stops working?
A: That's correct, it does. It's a permissions issue that there is no known
fix for due to monitoring of GPU fanspeeds and temperatures. If you disable
the monitoring with --no-adl it should switch okay.
Q: My network gets slower and slower and then dies for a minute?
A; Try the --net-delay option.
Q: How do I tune for p2pool?
A: p2pool has very rapid expiration of work and new blocks, it is suggested you
decrease intensity by 1 from your optimal value, and decrease GPU threads to 1
with -g 1. It is also recommended to use --failover-only since the work is
effectively like a different block chain. If mining with a minirig, it is worth
adding the --bfl-range option.
Q: Are OpenCL kernels from other mining software useable in cgminer?
A: No, the APIs are slightly different between the different software and they
will not work.
Q: I run PHP on windows to access the API with the example miner.php. Why does
it fail when php is installed properly but I only get errors about Sockets not
working in the logs?
A: http://us.php.net/manual/en/sockets.installation.php
Q: What is a PGA?
A: At the moment, cgminer supports 3 FPGAs: BitForce, Icarus and ModMiner.
They are Field-Programmable Gate Arrays that have been programmed to do Bitcoin
mining. Since the acronym needs to be only 3 characters, the "Field-" part has
been skipped.
Q: What is an ASIC?
A: Cgminer currently supports 2 ASICs: Avalon and BitForce SC devices. They
are Application Specify Integrated Circuit devices and provide the highest
performance per unit power due to being dedicated to only one purpose.
Q: Can I mine scrypt with FPGAs or ASICs?
A: No.
Q: What is stratum and how do I use it?
A: Stratum is a protocol designed for pooled mining in such a way as to
minimise the amount of network communications, yet scale to hardware of any
speed. With versions of cgminer 2.8.0+, if a pool has stratum support, cgminer
will automatically detect it and switch to the support as advertised if it can.
If you input the stratum port directly into your configuration, or use the
special prefix "stratum+tcp://" instead of "http://", cgminer will ONLY try to
use stratum protocol mining. The advantages of stratum to the miner are no
delays in getting more work for the miner, less rejects across block changes,
and far less network communications for the same amount of mining hashrate. If
you do NOT wish cgminer to automatically switch to stratum protocol even if it
is detected, add the --fix-protocol option.
Q: Why don't the statistics add up: Accepted, Rejected, Stale, Hardware Errors,
Diff1 Work, etc. when mining greater than 1 difficulty shares?
A: As an example, if you look at 'Difficulty Accepted' in the RPC API, the number
of difficulty shares accepted does not usually exactly equal the amount of work
done to find them. If you are mining at 8 difficulty, then you would expect on
average to find one 8 difficulty share, per 8 single difficulty shares found.
However, the number is actually random and converges over time, it is an average,
not an exact value, thus you may find more or less than the expected average.
Q: Why do the scrypt diffs not match with the current difficulty target?
A: The current scrypt block difficulty is expressed in terms of how many
multiples of the BTC difficulty it currently is (eg 28) whereas the shares of
"difficulty 1" are actually 65536 times smaller than the BTC ones. The diff
expressed by cgminer is as multiples of difficulty 1 shares.
Q: Can I make a donation in litecoin?
A: Yes, see SCRYPT-README for the address, but the author prefers bitcoin if
possible.
Q: My keyboard input momentarily pauses or repeats keys every so often on
windows while mining?
A: The USB implementation on windows can be very flaky on some hardware and
every time cgminer looks for new hardware to hotplug it it can cause these
sorts of problems. You can disable hotplug with:
--hotplug 0
Q: What should my Work Utility (WU) be?
A: Work utility is the product of hashrate * luck and only stabilises over a
very long period of time. Assuming all your work is valid work, bitcoin mining
should produce a work utility of approximately 1 per 71.6MH. This means at
5GH you should have a WU of 5000 / 71.6 or ~ 69. You cannot make your machine
do "better WU" than this - it is luck related. However you can make it much
worse if your machine produces a lot of hardware errors producing invalid work.

271
FPGA-README
Unescape View File

@ -1,271 +0,0 @@ @@ -1,271 +0,0 @@
This README contains extended details about FPGA mining with cgminer
For ModMinerQuad (MMQ) BitForce (BFL) and Icarus (ICA, BLT, LLT, AMU, CMR)
--------------------------------------------------------------------------
When mining on windows, the driver being used will determine if mining will work.
If the driver doesn't allow mining, you will get a "USB init," error message
i.e. one of:
open device failed, err %d, you need to install a WinUSB driver for the device
or
claim interface %d failed, err %d
The best solution for this is to use a tool called Zadig to set the driver:
http://sourceforge.net/projects/libwdi/files/zadig/
This allows you set the driver for the device to be WinUSB which is usually
required to make it work if you're having problems
With Zadig, you may need to run it as administrator and if your device is
plugged in but you cannot see it, use the Menu: Options -> List All Devices
You must also make sure you are using the latest libusb-1.0.dll supplied
with cgminer (not the libusbx version)
When you first switch a device over to WinUSB with Zadig and it shows that
correctly on the left of the Zadig window, but it still gives permission
errors, you may need to unplug the USB miner and then plug it back in
-
When mining on linux, but not using 'sudo' and not logged into 'root' you
may get a USB priviledge error (-3), so you may also need to do the following:
sudo cp 01-cgminer.rules /etc/udev/rules.d/
And also:
sudo usermod -G plugdev -a `whoami`
If your linux distro doesn't have the 'plugdev' group, you can create it like:
sudo groupadd plugdev
Then reboot ...
-
There is a hidden option in cgminer to dump out a lot of information
about USB that will help the developers to assist you if you are having
problems:
--usb-dump 0
It will only help if you have a working FPGA device listed above
ModMinerQuad (MMQ)
------------------
The mining bitstream does not survive a power cycle, so cgminer will upload
it, if it needs to, before it starts mining (approx 7min 40sec)
The red LED also flashes while it is uploading the bitstream
-
If the MMQ doesn't respond to cgminer at all, or the red LED isn't flashing
then you will need to reset the MMQ
The red LED should always be flashing when it is mining or ready to mine
To reset the MMQ, you are best to press the left "RESET" button on the
backplane, then unplug and replug the USB cable
If your MMQ doesn't have a button on the "RESET" pad, you need to join
the two left pads of the "RESET" pad with conductive wire to reset it.
Cutting a small (metal) paper-clip in half works well for this
Then unplug the USB cable, wait for 5 seconds, then plug it back in
After you press reset, the red LED near the USB port should blink continuously
If it still wont work, power off, wait for 5 seconds, then power on the MMQ
This of course means it will upload the bitstream again when you start cgminer
-
Device 0 is on the power end of the board
-
You must make sure you have an approriate firmware in your MMQ
Read here for official details of changing the firmware:
http://wiki.btcfpga.com/index.php?title=Firmware
The basics of changing the firmware are:
You need two short pieces of conductive wire if your MMQ doesn't have
buttons on the "RESET" and "ISP" pads on the backplane board
Cutting a small (metal) paper-clip in half works well for this
Join the 2 left pads of the "RESET" pad with wire and the led will dim
Without disconnecting the "RESET", join the 2 left pads of the "ISP" pad
with a wire and it will stay dim
Release "RESET" then release "ISP" and is should still be dim
Unplug the USB and when you plug it back in it will show up as a mass
storage device
Linux: (as one single line):
mcopy -i /dev/disk/by-id/usb-NXP_LPC134X_IFLASH_ISP000000000-0:0
modminer091012.bin ::/firmware.bin
Windows: delete the MSD device file firmware.bin and copy in the new one
rename the new file and put it under the same name 'firmware.bin'
Disconnect the USB correctly (so writes are flushed first)
Join and then disconnect "RESET" and then plug the USB back in and it's done
Best to update to one of the latest 2 listed below if you don't already
have one of them in your MMQ
The current latest different firmware are:
Latest for support of normal or TLM bitstream:
http://btcfpga.com/files/firmware/modminer092612-TLM.bin
Latest with only normal bitstream support (Temps/HW Fix):
http://btcfpga.com/files/firmware/modminer091012.bin
The code is currently tested on the modminer091012.bin firmware.
This comment will be updated when others have been tested
-
On many linux distributions there is an app called modem-manager that
may cause problems when it is enabled, due to opening the MMQ device
and writing to it
The problem will typically present itself by the flashing led on the
backplane going out (no longer flashing) and it takes a power cycle to
re-enable the MMQ firmware - which then can lead to the problem happening
again
You can either disable/uninstall modem-manager if you don't need it or:
a (hack) solution to this is to blacklist the MMQ USB device in
/lib/udev/rules.d/77-mm-usb-device-blacklist.rules
Adding 2 lines like this (just above APC) should help
# MMQ
ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0003", ENV{ID_MM_DEVICE_IGNORE}="1"
The change will be lost and need to be re-done, next time you update the
modem-manager software
TODO: check that all MMQ's have the same product ID
BitForce (BFL)
--------------
--bfl-range Use nonce range on bitforce devices if supported
This option is only for bitforce devices. Earlier devices such as the single
did not have any way of doing small amounts of work which meant that a lot of
work could be lost across block changes. Some of the "minirigs" have support
for doing this, so less work is lost across a longpoll. However, it comes at
a cost of 1% in overall hashrate so this feature is disabled by default. It
is only recommended you enable this if you are mining with a minirig on
p2pool.
C source is included for a bitforce firmware flash utility on Linux only:
bitforce-firmware-flash.c
Using this, you can change the bitstream firmware on bitforce singles.
It is untested with other devices. Use at your own risk!
To compile:
make bitforce-firmware-flash
To flash your BFL, specify the BFL port and the flash file e.g.:
sudo ./bitforce-firmware-flash /dev/ttyUSB0 alphaminer_832.bfl
It takes a bit under 3 minutes to flash a BFL and shows a progress % counter
Once it completes, you may also need to wait about 15 seconds,
then power the BFL off and on again
If you get an error at the end of the BFL flash process stating:
"Error reading response from ZBX"
it may have worked successfully anyway.
Test mining on it to be sure if it worked or not.
You need to give cgminer about 10 minutes mining with the BFL to be sure of
the MH/s value reported with the changed firmware - and the MH/s reported
will be less than the firmware speed since you lose work on every block change.
Icarus (ICA, BLT, LLT, AMU, CMR)
--------------------------------
There are two hidden options in cgminer when Icarus support is compiled in:
--icarus-options <arg> Set specific FPGA board configurations - one set of values for all or comma separated
baud:work_division:fpga_count
baud The Serial/USB baud rate - 115200 or 57600 only - default 115200
work_division The fraction of work divided up for each FPGA chip - 1, 2, 4 or 8
e.g. 2 means each FPGA does half the nonce range - default 2
fpga_count The actual number of FPGA working - this would normally be the same
as work_division - range is from 1 up to 'work_division'
It defaults to the value of work_division - or 2 if you don't specify
work_division
If you define fewer comma seperated values than Icarus devices, the last values will be used
for all extra devices
An example would be: --icarus-options 57600:2:1
This would mean: use 57600 baud, the FPGA board divides the work in half however
only 1 FPGA actually runs on the board (e.g. like an early CM1 Icarus copy bitstream)
--icarus-timing <arg> Set how the Icarus timing is calculated - one setting/value for all or comma separated
default[=N] Use the default Icarus hash time (2.6316ns)
short=[N] Calculate the hash time and stop adjusting it at ~315 difficulty 1 shares (~1hr)
long=[N] Re-calculate the hash time continuously
value[=N] Specify the hash time in nanoseconds (e.g. 2.6316) and abort time (e.g. 2.6316=80)
If you define fewer comma seperated values than Icarus devices, the last values will be used
for all extra devices
Icarus timing is required for devices that do not exactly match a default Icarus Rev3 in
processing speed
If you have an Icarus Rev3 you should not normally need to use --icarus-timing since the
default values will maximise the MH/s and display it correctly
Icarus timing is used to determine the number of hashes that have been checked when it aborts
a nonce range (including on a LongPoll)
It is also used to determine the elapsed time when it should abort a nonce range to avoid
letting the Icarus go idle, but also to safely maximise that time
'short' or 'long' mode should only be used on a computer that has enough CPU available to run
cgminer without any CPU delays (an active desktop or swapping computer would not be stable enough)
Any CPU delays while calculating the hash time will affect the result
'short' mode only requires the computer to be stable until it has completed ~315 difficulty 1 shares
'long' mode requires it to always be stable to ensure accuracy, however, over time it continually
corrects itself
The optional additional =N for 'short' or 'long' specifies the limit to set the timeout to in N * 100ms
thus if the timing code calculation is higher while running, it will instead use N * 100ms
This can be set to the appropriate value to ensure the device never goes idle even if the
calculation is negatively affected by system performance
When in 'short' or 'long' mode, it will report the hash time value each time it is re-calculated
In 'short' or 'long' mode, the scan abort time starts at 5 seconds and uses the default 2.6316ns
scan hash time, for the first 5 nonce's or one minute (whichever is longer)
In 'default' or 'value' mode the 'constants' are calculated once at the start, based on the default
value or the value specified
The optional additional =N specifies to set the default abort at N * 100ms, not the calculated
value, which is ~112 for 2.6316ns
To determine the hash time value for a non Icarus Rev3 device or an Icarus Rev3 with a different
bitstream to the default one, use 'long' mode and give it at least a few hundred shares, or use
'short' mode and take note of the final hash time value (Hs) calculated
You can also use the RPC API 'stats' command to see the current hash time (Hs) at any time
The Icarus code currently only works with an FPGA device that supports the same commands as
Icarus Rev3 requires and also is less than ~840MH/s and greater than 2MH/s
If an FPGA device does hash faster than ~840MH/s it should work correctly if you supply the
correct hash time nanoseconds value
The Icarus code will automatically detect Icarus, Lancelot, AsicminerUSB and Cairnsmore1
FPGA devices and set default settings to match those devices if you don't specify them
The timing code itself will affect the Icarus performance since it increases the delay after
work is completed or aborted until it starts again
The increase is, however, extremely small and the actual increase is reported with the
RPC API 'stats' command (a very slow CPU will make it more noticeable)
Using the 'short' mode will remove this delay after 'short' mode completes
The delay doesn't affect the calculation of the correct hash time

835
README
Unescape View File

@ -1,835 +0,0 @@ @@ -1,835 +0,0 @@
This is a multi-threaded multi-pool GPU, FPGA and ASIC 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 donating 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: GPLv3. See COPYING for details.
SEE ALSO API-README, ASIC-README, FGPA-README, GPU-README AND SCRYPT-README FOR
MORE INFORMATION ON EACH.
---
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.
Any configuration file may also contain a single
"include" : "filename"
to recursively include another configuration file.
Writing the configuration will save all settings from all files in the output.
Single pool:
cgminer -o http://pool:port -u username -p password
Multiple pools:
cgminer -o http://pool1:port -u pool1username -p pool1password -o http://pool2:port -u pool2usernmae -p pool2password
Single pool with a standard http proxy, regular desktop:
cgminer -o "http:proxy:port|http://pool:port" -u username -p password
Single pool with a socks5 proxy, regular desktop:
cgminer -o "socks5:proxy:port|http://pool:port" -u username -p password
Single pool with stratum protocol support:
cgminer -o stratum+tcp://pool:port -u username -p password
The list of proxy types are:
http: standard http 1.1 proxy
http0: http 1.0 proxy
socks4: socks4 proxy
socks5: socks5 proxy
socks4a: socks4a proxy
socks5h: socks5 proxy using a hostname
If you compile cgminer with a version of CURL before 7.19.4 then some of the above will
not be available. All are available since CURL version 7.19.4
If you specify the --socks-proxy option to cgminer, it will only be applied to all pools
that don't specify their own proxy setting like above
---
BUILDING CGMINER FOR YOURSELF
DEPENDENCIES:
Mandatory:
curl dev library http://curl.haxx.se/libcurl/
(libcurl4-openssl-dev)
pkg-config http://www.freedesktop.org/wiki/Software/pkg-config
libtool http://www.gnu.org/software/libtool/
Optional:
curses dev library
(libncurses5-dev or libpdcurses on WIN32 for text user interface)
AMD APP SDK http://developer.amd.com/sdks/AMDAPPSDK
(This sdk is mandatory for GPU mining)
AMD ADL SDK http://developer.amd.com/sdks/ADLSDK
(This sdk is mandatory for ATI GPU monitoring & clocking)
libudev dev library (libudev-dev)
(This is only required for ASIC+FPGA support and is linux only)
If building from git:
autoconf
automake
CGMiner specific configuration options:
--enable-opencl Enable support for GPU mining with opencl
--disable-adl Override detection and disable building with adl
--enable-scrypt Compile support for scrypt litecoin mining (default
disabled)
--enable-avalon Compile support for Avalon (default disabled)
--enable-bflsc Compile support for BFL ASICs (default disabled)
--enable-bitforce Compile support for BitForce FPGAs (default
disabled)
--enable-bitfury Compile support for BitFury ASICs (default disabled)
--enable-hashfast Compile support for Hashfast (default disabled)
--enable-icarus Compile support for Icarus (default disabled)
--enable-knc Compile support for KnC miners (default disabled)
--enable-klondike Compile support for Klondike (default disabled)
--enable-modminer Compile support for ModMiner FPGAs(default disabled)
--without-curses Compile support for curses TUI (default enabled)
--with-system-libusb Compile against dynamic system libusb (default use
included static libusb)
Basic *nix build instructions:
To actually build:
./autogen.sh # only needed if building from git repo
CFLAGS="-O2 -Wall -march=native" ./configure <options>
No installation is necessary. You may run cgminer from the build
directory directly, but you may do make install if you wish to install
cgminer to a system location or location you specified.
Native WIN32 build instructions: see windows-build.txt
---
Usage instructions: Run "cgminer --help" to see options:
Usage: . [-atDdGCgIKklmpPQqrRsTouvwOchnV]
Options for both config file and command line:
--api-allow Allow API access (if enabled) only to the given list of [W:]IP[/Prefix] address[/subnets]
This overrides --api-network and you must specify 127.0.0.1 if it is required
W: in front of the IP address gives that address privileged access to all api commands
--api-description Description placed in the API status header (default: cgminer version)
--api-groups API one letter groups G:cmd:cmd[,P:cmd:*...]
See API-README for usage
--api-listen Listen for API requests (default: disabled)
By default any command that does not just display data returns access denied
See --api-allow to overcome this
--api-network Allow API (if enabled) to listen on/for any address (default: only 127.0.0.1)
--api-mcast Enable API Multicast listener, (default: disabled)
The listener will only run if the API is also enabled
--api-mcast-addr <arg> API Multicast listen address, (default: 224.0.0.75)
--api-mcast-code <arg> Code expected in the API Multicast message, don't use '-' (default: "FTW")
--api-mcast-port <arg> API Multicast listen port, (default: 4028)
--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
--balance Change multipool strategy from failover to even share balance
--benchmark Run cgminer in benchmark mode - produces no shares
--compact Use compact display without per device statistics
--debug|-D Enable debug output
--device|-d <arg> Select device to use, one value, range and/or comma separated (e.g. 0-2,4) default: all
--disable-rejecting Automatically disable pools that continually reject shares
--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
--fix-protocol Do not redirect to a different getwork protocol (eg. stratum)
--hotplug <arg> Set hotplug check time to <arg> seconds (0=never default: 5) - only with libusb
--kernel-path|-K <arg> Specify a path to where bitstream and kernel files are (default: "/usr/local/bin")
--load-balance Change multipool strategy from failover to quota based balance
--log|-l <arg> Interval in seconds between log output (default: 5)
--lowmem Minimise caching of shares for low memory applications
--monitor|-m <arg> Use custom pipe cmd for output messages
--net-delay Impose small delays in networking to not overload slow routers
--no-submit-stale Don't submit shares if they are detected as stale
--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
--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)
--scrypt Use the scrypt algorithm for mining (litecoin only)
--sharelog <arg> Append share log to file
--shares <arg> Quit after mining N shares (default: unlimited)
--socks-proxy <arg> Set socks4 proxy (host:port) for all pools without a proxy specified
--syslog Use system log for output messages (default: standard error)
--temp-cutoff <arg> Temperature where a device will be automatically disabled, one value or comma separated list (default: 95)
--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
USB device (ASIC and FPGA) options:
--icarus-options <arg> Set specific FPGA board configurations - one set of values for all or comma separated
--icarus-timing <arg> Set how the Icarus timing is calculated - one setting/value for all or comma separated
--usb <arg> USB device selection (See below)
--usb-dump (See FPGA-README)
See FGPA-README or ASIC-README for more information regarding these.
ASIC only options:
--avalon-auto Adjust avalon overclock frequency dynamically for best hashrate
--avalon-fan <arg> Set fanspeed percentage for avalon, single value or range (default: 20-100)
--avalon-freq <arg> Set frequency range for avalon-auto, single value or range
--avalon-cutoff <arg> Set avalon overheat cut off temperature (default: 60)
--avalon-options <arg> Set avalon options baud:miners:asic:timeout:freq
--avalon-temp <arg> Set avalon target temperature (default: 50)
--bflsc-overheat <arg> Set overheat temperature where BFLSC devices throttle, 0 to disable (default: 90)
--bitburner-fury-options <arg> Override avalon-options for BitBurner Fury boards baud:miners:asic:timeout:freq
--bitburner-fury-voltage <arg> Set BitBurner Fury core voltage, in millivolts
--bitburner-voltage <arg> Set BitBurner (Avalon) core voltage, in millivolts
--klondike-options <arg> Set klondike options clock:temptarget
See ASIC-README for more information regarding these.
FPGA only options:
--bfl-range Use nonce range on bitforce devices if supported
See FGPA-README for more information regarding this.
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
--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-dyninterval <arg> Set the refresh interval in ms for GPUs using dynamic intensity (default: 7)
--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-map <arg> Map OpenCL to ADL device order manually, paired CSV (e.g. 1:0,2:1 maps OpenCL 1 to ADL 0, 2 to 1)
--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-reorder Attempt to reorder GPU devices according to PCI Bus ID
--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|-k <arg> Override kernel to use (diablo, poclbm, phatk or diakgcn) - one value or comma separated
--ndevs|-n Enumerate number of detected GPUs and exit
--no-restart Do not attempt to restart GPUs that hang
--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 (1, 2 or 4) - one value or comma separated list
--worksize|-w <arg> Override detected optimal worksize - one value or comma separated list
See GPU-README for more information regarding GPU mining.
SCRYPT only options:
--lookup-gap <arg> Set GPU lookup gap for scrypt mining, comma separated
--shaders <arg> GPU shaders per card for tuning scrypt, comma separated
--thread-concurrency <arg> Set GPU thread concurrency for scrypt mining, comma separated
See SCRYPT-README for more information regarding litecoin mining.
Cgminer should automatically find all of your Avalon ASIC, BFL ASIC, BitForce
FPGAs, Icarus bitstream FPGAs, Klondike ASIC, ASICMINER usb block erupters,
KnC ASICs, Hashfast ASICs and ModMiner FPGAs.
---
SETTING UP USB DEVICES
WINDOWS:
On windows, the direct USB support requires the installation of a WinUSB
driver (NOT the ftdi_sio driver), and attach it to your devices.
The easiest way to do this is to use the zadig utility which will install the
drivers for you and then once you plug in your device you can choose the
"list all devices" from the "option" menu and you should be able to see the
device as something like: "BitFORCE SHA256 SC". Choose the install or replace
driver option and select WinUSB. You can either google for zadig or download
it from the cgminer directoy in the DOWNLOADS link above.
LINUX:
On linux, the direct USB support requires no drivers at all. However due to
permissions issues, you may not be able to mine directly on the devices as a
regular user without giving the user access to the device or by mining as
root (administrator). In order to give your regular user access, you can make
him a member of the plugdev group with the following commands:
sudo usermod -G plugdev -a `whoami`
If your distribution does not have the plugdev group you can create it with:
sudo groupadd plugdev
In order for the BFL devices to instantly be owned by the plugdev group and
accessible by anyone from the plugdev group you can copy the file
"01-cgminer.rules" from the cgminer archive into the /etc/udev/rules.d
directory with the following command:
sudo cp 01-cgminer.rules /etc/udev/rules.d/
After this you can either manually restart udev and re-login, or more easily
just reboot.
Advanced USB options:
The --usb option can restrict how many Avalon, BFL ASIC, BitForce FPGAs,
Klondike ASIC, ModMiner FPGAs or Icarus bitstream FPGAs it finds:
--usb 1:2,1:3,1:4,1:*
or
--usb BAS:1,BFL:1,MMQ:0,ICA:0,KLN:0
or
--usb :10
You can only use one of the above 3
The first version
--usb 1:2,1:3,1:4,1:*
allows you to select which devices to mine on with a list of USB
bus_number:device_address
All other USB devices will be ignored
Hotplug will also only look at the devices matching the list specified and
find nothing new if they are all in use
You can specify just the USB bus_number to find all devices like 1:*
which means any devices on USB bus_number 1
This is useful if you unplug a device then plug it back in the same port,
it usually reappears with the same bus_number but a different device_address
You can see the list of all USB devices on linux with 'sudo lsusb'
Cgminer will list the recognised USB devices with the '-n' option or the
'--usb-dump 0' option
The '--usb-dump N' option with a value of N greater than 0 will dump a lot
of details about each recognised USB device
If you wish to see all USB devices, include the --usb-list-all option
The second version
--usb BAS:1,BFL:1,MMQ:0,ICA:0,KLN:0
allows you to specify how many devices to choose based on each device
driver cgminer has - there are currently 5 USB drivers: BAS, BFL, MMQ.
ICA & KLN
N.B. you can only specify which device driver to limit, not the type of
each device, e.g. with BAS:n you can limit how many BFL ASIC devices will
be checked, but you cannot limit the number of each type of BFL ASIC
Also note that the MMQ count is the number of MMQ backplanes you have
not the number of MMQ FPGAs
The third version
--usb :10
means only use a maximum of 10 devices of any supported USB devices
Once cgminer has 10 devices it will not configure any more and hotplug will
not scan for any more
If one of the 10 devices stops working, hotplug - if enabled, as is default
- will scan normally again until it has 10 devices
--usb :0 will disable all USB I/O other than to initialise libusb
NOTE: The --device option will limit which devices are in use based on their
numbering order of the total devices, so if you hotplug USB devices regularly,
it will not reliably be the same devices.
---
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
[F]ailover only disabled
[A]dd pool [R]emove pool [D]isable pool [E]nable pool
[C]hange management strategy [S]witch pool [I]nformation
S gives you:
[Q]ueue: 1
[S]cantime: 60
[E]xpiry: 120
[W]rite config file
[C]gminer restart
D gives you:
[N]ormal [C]lear [S]ilent mode (disable all output)
[D]ebug:off
[P]er-device:off
[Q]uiet:off
[V]erbose:off
[R]PC debug:off
[W]orkTime details:off
co[M]pact: off
[L]og interval:5
Q quits the application.
G gives you something like:
GPU 0: [124.2 / 191.3 Mh/s] [A:77 R:33 HW:0 U:1.73/m WU 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
The running log shows output like this:
[2012-10-12 18:02:20] Accepted f0c05469 Diff 1/1 GPU 0 pool 1
[2012-10-12 18:02:22] Accepted 218ac982 Diff 7/1 GPU 1 pool 1
[2012-10-12 18:02:23] Accepted d8300795 Diff 1/1 GPU 3 pool 1
[2012-10-12 18:02:24] Accepted 122c1ff1 Diff 14/1 GPU 1 pool 1
The 8 byte hex value are the 2nd 8 bytes of the share being submitted to the
pool. The 2 diff values are the actual difficulty target that share reached
followed by the difficulty target the pool is currently asking for.
---
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 | A:729 R:8 HW:0 WU:22.53/m
Each column is as follows:
5s: A 5 second exponentially decaying average hash rate
avg: An all time average hash rate
A: The total difficulty of Accepted shares
R: The total difficulty of Rejected shares
HW: The number of HardWare errors
WU: The Work Utility defined as the number of diff1 shares work / minute
(accepted or rejected).
GPU 1: 73.5C 2551RPM | 427.3/443.0Mh/s | A:8 R:0 HW:0 WU: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 total difficulty of accepted shares
The total difficulty of rejected shares
The number of hardware erorrs
The work utility defined as the number of diff1 shares work / minute
The cgminer status line shows:
ST: 1 SS: 0 NB: 1 LW: 8 GF: 1 RF: 1
ST is STaged work items (ready to use).
SS is Stale Shares discarded (detected and not submitted so don't count as rejects)
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)
The block display shows:
Block: 0074c5e482e34a506d2a051a... Started: [17:17:22] Best share: 2.71K
This shows a short stretch of the current block, when the new block started,
and the all time best difficulty share you've found since starting cgminer
this time.
---
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 to all the pools on a quota basis. By default, all
pools are allocated equal quotas unless specified with --quota. This
apportioning of work is based on work handed out, not shares returned so is
independent of difficulty targets or rejected shares. While a pool is disabled
or dead, its quota is dropped until it is re-enabled. Quotas are forward
looking, so if the quota is changed on the fly, it only affects future work.
If all pools are set to zero quota or all pools with quota are dead, it will
fall back to a failover mode. See quota below for more information.
The failover-only flag has special meaning in combination with load-balance
mode and it will distribute quota back to priority pool 0 from any pools that
are unable to provide work for any reason so as to maintain quota ratios
between the rest of the pools.
BALANCE:
This strategy monitors the amount of difficulty 1 shares solved for each pool
and uses it to try to end up doing the same amount of work for all pools.
---
QUOTAS
The load-balance multipool strategy works off a quota based scheduler. The
quotas handed out by default are equal, but the user is allowed to specify any
arbitrary ratio of quotas. For example, if all the quota values add up to 100,
each quota value will be a percentage, but if 2 pools are specified and pool0
is given a quota of 1 and pool1 is given a quota of 9, pool0 will get 10% of
the work and pool1 will get 90%. Quotas can be changed on the fly by the API,
and do not act retrospectively. Setting a quota to zero will effectively
disable that pool unless all other pools are disabled or dead. In that
scenario, load-balance falls back to regular failover priority-based strategy.
While a pool is dead, it loses its quota and no attempt is made to catch up
when it comes back to life.
To specify quotas on the command line, pools should be specified with a
semicolon separated --quota(or -U) entry instead of --url. Pools specified with
--url are given a nominal quota value of 1 and entries can be mixed.
For example:
--url poola:porta -u usernamea -p passa --quota "2;poolb:portb" -u usernameb -p passb
Will give poola 1/3 of the work and poolb 2/3 of the work.
Writing configuration files with quotas is likewise supported. To use the above
quotas in a configuration file they would be specified thus:
"pools" : [
{
"url" : "poola:porta",
"user" : "usernamea",
"pass" : "passa"
},
{
"quota" : "2;poolb:portb",
"user" : "usernameb",
"pass" : "passb"
}
]
---
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.
The WorkTime details 'debug' option adds details on the end of each line
displayed for Accepted or Rejected work done. An example would be:
<-00000059.ed4834a3 M:X D:1.0 G:17:02:38:0.405 C:1.855 (2.995) W:3.440 (0.000) S:0.461 R:17:02:47
The first 2 hex codes are the previous block hash, the rest are reported in
seconds unless stated otherwise:
The previous hash is followed by the getwork mode used M:X where X is one of
P:Pool, T:Test Pool, L:LP or B:Benchmark,
then D:d.ddd is the difficulty required to get a share from the work,
then G:hh:mm:ss:n.nnn, which is when the getwork or LP was sent to the pool and
the n.nnn is how long it took to reply,
followed by 'O' on it's own if it is an original getwork, or 'C:n.nnn' if it was
a clone with n.nnn stating how long after the work was recieved that it was cloned,
(m.mmm) is how long from when the original work was received until work started,
W:n.nnn is how long the work took to process until it was ready to submit,
(m.mmm) is how long from ready to submit to actually doing the submit, this is
usually 0.000 unless there was a problem with submitting the work,
S:n.nnn is how long it took to submit the completed work and await the reply,
R:hh:mm:ss is the actual time the work submit reply was received
If you start cgminer with the --sharelog option, you can get detailed
information for each share found. The argument to the option may be "-" for
standard output (not advisable with the ncurses UI), any valid positive number
for that file descriptor, or a filename.
To log share data to a file named "share.log", you can use either:
./cgminer --sharelog 50 -o xxx -u yyy -p zzz 50>share.log
./cgminer --sharelog share.log -o xxx -u yyy -p zzz
For every share found, data will be logged in a CSV (Comma Separated Value)
format:
timestamp,disposition,target,pool,dev,thr,sharehash,sharedata
For example (this is wrapped, but it's all on one line for real):
1335313090,reject,
ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000,
http://localhost:8337,GPU0,0,
6f983c918f3299b58febf95ec4d0c7094ed634bc13754553ec34fc3800000000,
00000001a0980aff4ce4a96d53f4b89a2d5f0e765c978640fe24372a000001c5
000000004a4366808f81d44f26df3d69d7dc4b3473385930462d9ab707b50498
f681634a4f1f63d01a0cd43fb338000000000080000000000000000000000000
0000000000000000000000000000000000000000000000000000000080020000
---
RPC API
For RPC API details see the API-README file
---
FAQ
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 configure cgminer to mine with different login credentials or pools
for each separate device?
A: No.
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: 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: 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. They seem to be flagging even source code now from cgminer
as viruses, even though text source files can't do anything by themself.
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: 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 for GPUs.
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. No binary builds
supporting CPU mining will be released. Virtually all remaining users of CPU
mining are as back ends for illegal botnets. The main reason cgminer is being
inappopriately tagged as a virus by antivirus software is due to the trojans
packaging a CPU mining capable version of it. There is no longer ANY CPU mining
code in cgminer. If you are mining bitcoin with CPU today, you are spending
1000x more in electricity costs than you are earning in bitcoin.
Q: GUI version?
A: No. The RPC interface makes it possible for someone else to write one
though.
Q: I'm having an issue. What debugging information should I provide?
A: Start cgminer with your regular commands and add -D -T --verbose and provide
the full startup output and a summary of your hardware, operating system, ATI
driver version and ATI stream version.
Q: Why don't you provide win64 builds?
A: Win32 builds work everywhere and there is precisely zero advantage to a
64 bit build on windows.
Q: Is it faster to mine on windows or linux?
A: It makes no difference. It comes down to choice of operating system for
their various features. Linux offers much better long term stability and
remote monitoring and security, while windows offers you overclocking tools
that can achieve much more than cgminer can do on linux.
Q: Can I mine with cgminer on a MAC?
A: cgminer will compile on OSX, but the performance of GPU mining is
compromised due to the opencl implementation on OSX, there is no temperature
or fanspeed monitoring, and the cooling design of most MACs, despite having
powerful GPUs, will usually not cope with constant usage leading to a high
risk of thermal damage. It is highly recommended not to mine on a MAC unless
it is to a USB device.
Q: I'm trying to mine litecoin but cgminer shows MH values instead of kH and
submits no shares?
A: Add the --scrypt parameter.
Q: I switch users on windows and my mining stops working?
A: That's correct, it does. It's a permissions issue that there is no known
fix for due to monitoring of GPU fanspeeds and temperatures. If you disable
the monitoring with --no-adl it should switch okay.
Q: My network gets slower and slower and then dies for a minute?
A; Try the --net-delay option.
Q: How do I tune for p2pool?
A: p2pool has very rapid expiration of work and new blocks, it is suggested you
decrease intensity by 1 from your optimal value, and decrease GPU threads to 1
with -g 1. It is also recommended to use --failover-only since the work is
effectively like a different block chain. If mining with a minirig, it is worth
adding the --bfl-range option.
Q: Are OpenCL kernels from other mining software useable in cgminer?
A: No, the APIs are slightly different between the different software and they
will not work.
Q: I run PHP on windows to access the API with the example miner.php. Why does
it fail when php is installed properly but I only get errors about Sockets not
working in the logs?
A: http://us.php.net/manual/en/sockets.installation.php
Q: What is a PGA?
A: At the moment, cgminer supports 3 FPGAs: BitForce, Icarus and ModMiner.
They are Field-Programmable Gate Arrays that have been programmed to do Bitcoin
mining. Since the acronym needs to be only 3 characters, the "Field-" part has
been skipped.
Q: What is an ASIC?
A: Cgminer currently supports 2 ASICs: Avalon and BitForce SC devices. They
are Application Specify Integrated Circuit devices and provide the highest
performance per unit power due to being dedicated to only one purpose.
Q: Can I mine scrypt with FPGAs or ASICs?
A: No.
Q: What is stratum and how do I use it?
A: Stratum is a protocol designed for pooled mining in such a way as to
minimise the amount of network communications, yet scale to hardware of any
speed. With versions of cgminer 2.8.0+, if a pool has stratum support, cgminer
will automatically detect it and switch to the support as advertised if it can.
If you input the stratum port directly into your configuration, or use the
special prefix "stratum+tcp://" instead of "http://", cgminer will ONLY try to
use stratum protocol mining. The advantages of stratum to the miner are no
delays in getting more work for the miner, less rejects across block changes,
and far less network communications for the same amount of mining hashrate. If
you do NOT wish cgminer to automatically switch to stratum protocol even if it
is detected, add the --fix-protocol option.
Q: Why don't the statistics add up: Accepted, Rejected, Stale, Hardware Errors,
Diff1 Work, etc. when mining greater than 1 difficulty shares?
A: As an example, if you look at 'Difficulty Accepted' in the RPC API, the number
of difficulty shares accepted does not usually exactly equal the amount of work
done to find them. If you are mining at 8 difficulty, then you would expect on
average to find one 8 difficulty share, per 8 single difficulty shares found.
However, the number is actually random and converges over time, it is an average,
not an exact value, thus you may find more or less than the expected average.
Q: Why do the scrypt diffs not match with the current difficulty target?
A: The current scrypt block difficulty is expressed in terms of how many
multiples of the BTC difficulty it currently is (eg 28) whereas the shares of
"difficulty 1" are actually 65536 times smaller than the BTC ones. The diff
expressed by cgminer is as multiples of difficulty 1 shares.
Q: Can I make a donation in litecoin?
A: Yes, see SCRYPT-README for the address, but the author prefers bitcoin if
possible.
Q: My keyboard input momentarily pauses or repeats keys every so often on
windows while mining?
A: The USB implementation on windows can be very flaky on some hardware and
every time cgminer looks for new hardware to hotplug it it can cause these
sorts of problems. You can disable hotplug with:
--hotplug 0
Q: What should my Work Utility (WU) be?
A: Work utility is the product of hashrate * luck and only stabilises over a
very long period of time. Assuming all your work is valid work, bitcoin mining
should produce a work utility of approximately 1 per 71.6MH. This means at
5GH you should have a WU of 5000 / 71.6 or ~ 69. You cannot make your machine
do "better WU" than this - it is luck related. However you can make it much
worse if your machine produces a lot of hardware errors producing invalid work.
---
This code is provided entirely free of charge by the programmer in his spare
time so donations would be greatly appreciated. Please consider donating to the
address below.
Con Kolivas <kernel@kolivas.org>
15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ

389
README.md
Unescape View File

@ -0,0 +1,389 @@ @@ -0,0 +1,389 @@
cgminer
=======
WARNING: THIS CODE IS CURRENTLY UNUSABLE!
Introduction
------------
This is a multi-threaded multi-pool GPU miner with ATI GPU monitoring,
(over)clocking and fanspeed support for scrypt-based coins. It is based on
cgminer by Con Kolivas (ckolivas), which is in turn based on cpuminer by
Jeff Garzik.
The code is currently being refactored to remove SHA256d-based
cryptocurrency mining support. Upon completion of this task, the software
will be renamed to scryptminer.
GIT TREE: https://github.com/veox/cgminer
License: GPLv3. See COPYING for details.
SEE ALSO API-README, GPU-README AND SCRYPT-README FOR MORE INFORMATION ON EACH.
Building
--------
DEPENDENCIES:
Mandatory:
curl dev library http://curl.haxx.se/libcurl/
(libcurl4-openssl-dev)
pkg-config http://www.freedesktop.org/wiki/Software/pkg-config
libtool http://www.gnu.org/software/libtool/
Optional:
curses dev library
(libncurses5-dev or libpdcurses on WIN32 for text user interface)
AMD APP SDK http://developer.amd.com/sdks/AMDAPPSDK
(This sdk is mandatory for GPU mining)
AMD ADL SDK http://developer.amd.com/sdks/ADLSDK
(This sdk is mandatory for ATI GPU monitoring & clocking)
If building from git:
autoconf
automake
CGMiner specific configuration options:
--disable-opencl Disable support for GPU mining with opencl
--disable-adl Override detection and disable building with adl
--enable-scrypt Compile support for scrypt litecoin mining (default
disabled)
--without-curses Compile support for curses TUI (default enabled)
Basic *nix build instructions:
To actually build:
./autogen.sh # only needed if building from git repo
CFLAGS="-O2 -Wall -march=native" ./configure <options>
No installation is necessary. You may run cgminer from the build
directory directly, but you may do make install if you wish to install
cgminer to a system location or location you specified.
Native WIN32 build instructions: see windows-build.txt
Basic Usage
-----------
After saving configuration from the menu, you do not need to give cgminer
any arguments and it will load your configuration.
Any configuration file may also contain a single
"include" : "filename"
to recursively include another configuration file.
Writing the configuration will save all settings from all files in the
output.
Single pool:
cgminer -o http://pool:port -u username -p password
Multiple pools:
cgminer -o http://pool1:port -u pool1username -p pool1password -o http://pool2:port -u pool2usernmae -p pool2password
Single pool with a standard http proxy, regular desktop:
cgminer -o "http:proxy:port|http://pool:port" -u username -p password
Single pool with a socks5 proxy, regular desktop:
cgminer -o "socks5:proxy:port|http://pool:port" -u username -p password
Single pool with stratum protocol support:
cgminer -o stratum+tcp://pool:port -u username -p password
The list of proxy types are:
http: standard http 1.1 proxy
http0: http 1.0 proxy
socks4: socks4 proxy
socks5: socks5 proxy
socks4a: socks4a proxy
socks5h: socks5 proxy using a hostname
If you compile cgminer with a version of CURL before 7.19.4 then some of
the above will not be available. All are available since CURL version
7.19.4.
If you specify the --socks-proxy option to cgminer, it will only be
applied to all pools that don't specify their own proxy setting like
above.
For more advanced usage , run `cgminer --help`.
See GPU-README for more information regarding GPU mining and
SCRYPT-README for more information regarding litecoin mining.
Runtime usage
-------------
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
[F]ailover only disabled
[A]dd pool [R]emove pool [D]isable pool [E]nable pool
[C]hange management strategy [S]witch pool [I]nformation
S gives you:
[Q]ueue: 1
[S]cantime: 60
[E]xpiry: 120
[W]rite config file
[C]gminer restart
D gives you:
[N]ormal [C]lear [S]ilent mode (disable all output)
[D]ebug:off
[P]er-device:off
[Q]uiet:off
[V]erbose:off
[R]PC debug:off
[W]orkTime details:off
co[M]pact: off
[L]og interval:5
Q quits the application.
G gives you something like:
GPU 0: [124.2 / 191.3 Mh/s] [A:77 R:33 HW:0 U:1.73/m WU 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
The running log shows output like this:
[2012-10-12 18:02:20] Accepted f0c05469 Diff 1/1 GPU 0 pool 1
[2012-10-12 18:02:22] Accepted 218ac982 Diff 7/1 GPU 1 pool 1
[2012-10-12 18:02:23] Accepted d8300795 Diff 1/1 GPU 3 pool 1
[2012-10-12 18:02:24] Accepted 122c1ff1 Diff 14/1 GPU 1 pool 1
The 8 byte hex value are the 2nd 8 bytes of the share being submitted to the
pool. The 2 diff values are the actual difficulty target that share reached
followed by the difficulty target the pool is currently asking for.
---
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 | A:729 R:8 HW:0 WU:22.53/m
Each column is as follows:
5s: A 5 second exponentially decaying average hash rate
avg: An all time average hash rate
A: The total difficulty of Accepted shares
R: The total difficulty of Rejected shares
HW: The number of HardWare errors
WU: The Work Utility defined as the number of diff1 shares work / minute
(accepted or rejected).
GPU 1: 73.5C 2551RPM | 427.3/443.0Mh/s | A:8 R:0 HW:0 WU: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 total difficulty of accepted shares
The total difficulty of rejected shares
The number of hardware erorrs
The work utility defined as the number of diff1 shares work / minute
The cgminer status line shows:
ST: 1 SS: 0 NB: 1 LW: 8 GF: 1 RF: 1
ST is STaged work items (ready to use).
SS is Stale Shares discarded (detected and not submitted so don't count as rejects)
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)
The block display shows:
Block: 0074c5e482e34a506d2a051a... Started: [17:17:22] Best share: 2.71K
This shows a short stretch of the current block, when the new block started,
and the all time best difficulty share you've found since starting cgminer
this time.
---
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 to all the pools on a quota basis. By default, all
pools are allocated equal quotas unless specified with --quota. This
apportioning of work is based on work handed out, not shares returned so is
independent of difficulty targets or rejected shares. While a pool is disabled
or dead, its quota is dropped until it is re-enabled. Quotas are forward
looking, so if the quota is changed on the fly, it only affects future work.
If all pools are set to zero quota or all pools with quota are dead, it will
fall back to a failover mode. See quota below for more information.
The failover-only flag has special meaning in combination with load-balance
mode and it will distribute quota back to priority pool 0 from any pools that
are unable to provide work for any reason so as to maintain quota ratios
between the rest of the pools.
BALANCE:
This strategy monitors the amount of difficulty 1 shares solved for each pool
and uses it to try to end up doing the same amount of work for all pools.
---
QUOTAS
The load-balance multipool strategy works off a quota based scheduler. The
quotas handed out by default are equal, but the user is allowed to specify any
arbitrary ratio of quotas. For example, if all the quota values add up to 100,
each quota value will be a percentage, but if 2 pools are specified and pool0
is given a quota of 1 and pool1 is given a quota of 9, pool0 will get 10% of
the work and pool1 will get 90%. Quotas can be changed on the fly by the API,
and do not act retrospectively. Setting a quota to zero will effectively
disable that pool unless all other pools are disabled or dead. In that
scenario, load-balance falls back to regular failover priority-based strategy.
While a pool is dead, it loses its quota and no attempt is made to catch up
when it comes back to life.
To specify quotas on the command line, pools should be specified with a
semicolon separated --quota(or -U) entry instead of --url. Pools specified with
--url are given a nominal quota value of 1 and entries can be mixed.
For example:
--url poola:porta -u usernamea -p passa --quota "2;poolb:portb" -u usernameb -p passb
Will give poola 1/3 of the work and poolb 2/3 of the work.
Writing configuration files with quotas is likewise supported. To use the above
quotas in a configuration file they would be specified thus:
"pools" : [
{
"url" : "poola:porta",
"user" : "usernamea",
"pass" : "passa"
},
{
"quota" : "2;poolb:portb",
"user" : "usernameb",
"pass" : "passb"
}
]
---
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.
The WorkTime details 'debug' option adds details on the end of each line
displayed for Accepted or Rejected work done. An example would be:
<-00000059.ed4834a3 M:X D:1.0 G:17:02:38:0.405 C:1.855 (2.995) W:3.440 (0.000) S:0.461 R:17:02:47
The first 2 hex codes are the previous block hash, the rest are reported in
seconds unless stated otherwise:
The previous hash is followed by the getwork mode used M:X where X is one of
P:Pool, T:Test Pool, L:LP or B:Benchmark,
then D:d.ddd is the difficulty required to get a share from the work,
then G:hh:mm:ss:n.nnn, which is when the getwork or LP was sent to the pool and
the n.nnn is how long it took to reply,
followed by 'O' on it's own if it is an original getwork, or 'C:n.nnn' if it was
a clone with n.nnn stating how long after the work was recieved that it was cloned,
(m.mmm) is how long from when the original work was received until work started,
W:n.nnn is how long the work took to process until it was ready to submit,
(m.mmm) is how long from ready to submit to actually doing the submit, this is
usually 0.000 unless there was a problem with submitting the work,
S:n.nnn is how long it took to submit the completed work and await the reply,
R:hh:mm:ss is the actual time the work submit reply was received
If you start cgminer with the --sharelog option, you can get detailed
information for each share found. The argument to the option may be "-" for
standard output (not advisable with the ncurses UI), any valid positive number
for that file descriptor, or a filename.
To log share data to a file named "share.log", you can use either:
./cgminer --sharelog 50 -o xxx -u yyy -p zzz 50>share.log
./cgminer --sharelog share.log -o xxx -u yyy -p zzz
For every share found, data will be logged in a CSV (Comma Separated Value)
format:
timestamp,disposition,target,pool,dev,thr,sharehash,sharedata
For example (this is wrapped, but it's all on one line for real):
1335313090,reject,
ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000,
http://localhost:8337,GPU0,0,
6f983c918f3299b58febf95ec4d0c7094ed634bc13754553ec34fc3800000000,
00000001a0980aff4ce4a96d53f4b89a2d5f0e765c978640fe24372a000001c5
000000004a4366808f81d44f26df3d69d7dc4b3473385930462d9ab707b50498
f681634a4f1f63d01a0cd43fb338000000000080000000000000000000000000
0000000000000000000000000000000000000000000000000000000080020000
---
RPC API
For RPC API details see the API-README file
Write Preview
Loading…
Cancel
Save