diff --git a/FPGA-README b/FPGA-README index 79725141..7b9f004d 100644 --- a/FPGA-README +++ b/FPGA-README @@ -1,6 +1,18 @@ This README contains extended details about FPGA mining with cgminer +Bitforce + +--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. + Icarus @@ -12,45 +24,45 @@ There is a hidden option in cgminer when Icarus support is compiled in: long 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) - 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 - - 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 1/10ths of a second, 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 a dual FPGA device that supports the same commands as - Icarus Rev3 requires and also is less than ~840MH/s and greater than 2MH/s - If a dual FPGA device does hash faster than ~840MH/s it should work correctly if you supply the - correct hash time nanoseconds value - - 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 +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 + +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 1/10ths of a second, 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 a dual FPGA device that supports the same commands as +Icarus Rev3 requires and also is less than ~840MH/s and greater than 2MH/s +If a dual FPGA device does hash faster than ~840MH/s it should work correctly if you supply the +correct hash time nanoseconds value + +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 diff --git a/README b/README index 58e89b93..bc1c59d6 100644 --- a/README +++ b/README @@ -201,23 +201,23 @@ FPGA mining boards(BitForce, Icarus, ModMiner, Ztex) only options: --scan-serial|-S Serial port to probe for FPGA mining device - This option is only for BitForce, Icarus, and/or ModMiner FPGAs +This option is only for BitForce, Icarus, and/or ModMiner FPGAs - By default, cgminer will scan for autodetected FPGAs unless at least one - -S is specified for that driver. If you specify -S and still want cgminer - to scan, you must also use "-S auto". If you want to prevent cgminer from - scanning without specifying a device, you can use "-S noauto". Note that - presently, autodetection only works on Linux, and might only detect one - device depending on the version of udev being used. +By default, cgminer will scan for autodetected FPGAs unless at least one +-S is specified for that driver. If you specify -S and still want cgminer +to scan, you must also use "-S auto". If you want to prevent cgminer from +scanning without specifying a device, you can use "-S noauto". Note that +presently, autodetection only works on Linux, and might only detect one +device depending on the version of udev being used. - On linux is usually of the format /dev/ttyUSBn - On windows is usually of the format \\.\COMn - (where n = the correct device number for the FPGA device) +On linux is usually of the format /dev/ttyUSBn +On windows is usually of the format \\.\COMn +(where n = the correct device number for the FPGA device) - The official supplied binaries are compiled with support for all FPGAs. - To force the code to only attempt detection with a specific driver, - prepend the argument with the driver name followed by a colon. - For example, "icarus:/dev/ttyUSB0" or "bitforce:\\.\COM5" +The official supplied binaries are compiled with support for all FPGAs. +To force the code to only attempt detection with a specific driver, +prepend the argument with the driver name followed by a colon. +For example, "icarus:/dev/ttyUSB0" or "bitforce:\\.\COM5" For other FPGA details see the FPGA-README @@ -795,7 +795,9 @@ 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. +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 kernels from other mining software useable in cgminer? A: No, the APIs are slightly different between the different software and they @@ -812,6 +814,13 @@ 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: How do I get my BFL device to auto-recognise? +A: They are only automatically recognised on linux, and no option needs to be +passed to them. The only thing that needs to be done is to load the driver for +them, which on linux would require: +sudo modprobe ftdi_sio vendor=0x0403 product=0x6014 + + --- This code is provided entirely free of charge by the programmer in his spare