FPGA-README 4.0 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273
  1. This README contains extended details about FPGA mining with cgminer
  2. Bitforce
  3. --bfl-range Use nonce range on bitforce devices if supported
  4. This option is only for bitforce devices. Earlier devices such as the single
  5. did not have any way of doing small amounts of work which meant that a lot of
  6. work could be lost across block changes. Some of the "minirigs" have support
  7. for doing this, so less work is lost across a longpoll. However, it comes at
  8. a cost of 1% in overall hashrate so this feature is disabled by default. It
  9. is only recommended you enable this if you are mining with a minirig on
  10. p2pool.
  11. BFGMiner also bundles a bitforce-firmware-flash utility on Linux. Using this,
  12. you can change the bitstream firmware on BitFORCE Singles. It is untested with
  13. other devices. Use at your own risk! Windows users may use Butterfly Labs
  14. EasyMiner to change firmware.
  15. Icarus
  16. There is a hidden option in cgminer when Icarus support is compiled in:
  17. --icarus-timing <arg> Set how the Icarus timing is calculated - one setting/value for all or comma separated
  18. default[=N] Use the default Icarus hash time (2.6316ns)
  19. short Calculate the hash time and stop adjusting it at ~315 difficulty 1 shares (~1hr)
  20. long Re-calculate the hash time continuously
  21. value[=N] Specify the hash time in nanoseconds (e.g. 2.6316) and abort time (e.g. 2.6316=80)
  22. Icarus timing is required for devices that do not exactly match a default Icarus Rev3 in
  23. processing speed
  24. If you have an Icarus Rev3 you should not normally need to use --icarus-timing since the
  25. default values will maximise the MH/s and display it correctly
  26. Icarus timing is used to determine the number of hashes that have been checked when it aborts
  27. a nonce range (including on a LongPoll)
  28. It is also used to determine the elapsed time when it should abort a nonce range to avoid
  29. letting the Icarus go idle, but also to safely maximise that time
  30. 'short' or 'long' mode should only be used on a computer that has enough CPU available to run
  31. cgminer without any CPU delays (an active desktop or swapping computer would not be stable enough)
  32. Any CPU delays while calculating the hash time will affect the result
  33. 'short' mode only requires the computer to be stable until it has completed ~315 difficulty 1 shares
  34. 'long' mode requires it to always be stable to ensure accuracy, however, over time it continually
  35. corrects itself
  36. When in 'short' or 'long' mode, it will report the hash time value each time it is re-calculated
  37. In 'short' or 'long' mode, the scan abort time starts at 5 seconds and uses the default 2.6316ns
  38. scan hash time, for the first 5 nonce's or one minute (whichever is longer)
  39. In 'default' or 'value' mode the 'constants' are calculated once at the start, based on the default
  40. value or the value specified
  41. The optional additional =N specifies to set the default abort at N 1/10ths of a second, not the
  42. calculated value, which is 112 for 2.6316ns
  43. To determine the hash time value for a non Icarus Rev3 device or an Icarus Rev3 with a different
  44. bitstream to the default one, use 'long' mode and give it at least a few hundred shares, or use
  45. 'short' mode and take note of the final hash time value (Hs) calculated
  46. You can also use the RPC API 'stats' command to see the current hash time (Hs) at any time
  47. The Icarus code currently only works with a dual FPGA device that supports the same commands as
  48. Icarus Rev3 requires and also is less than ~840MH/s and greater than 2MH/s
  49. If a dual FPGA device does hash faster than ~840MH/s it should work correctly if you supply the
  50. correct hash time nanoseconds value
  51. The timing code itself will affect the Icarus performance since it increases the delay after
  52. work is completed or aborted until it starts again
  53. The increase is, however, extremely small and the actual increase is reported with the
  54. RPC API 'stats' command (a very slow CPU will make it more noticeable)
  55. Using the 'short' mode will remove this delay after 'short' mode completes
  56. The delay doesn't affect the calculation of the correct hash time