Yes, you need to pass in -S erupter:all in order to have them detected as a Block Erupter Must I do it or may I leave them being recognised as Icarus? Does it change anything from practical point of view? Using the erupter driver gives you: correct hashrate, timings, and identify function. With icarus timings, you might lose some hashing time until it calibrates, but I've tried to minimise that. |
|
|
|
Does anyone know if BFGminer can send out an email alert on miner failure? ( minepeon does this from the rPi) I would like to set up something similar from my remote PC location.
--cmd-idle --cmd-dead etc can be used to execute any command when some events occur. |
|
|
|
If anyone wants to elaborate on the README FAQ covering un-Zadig'ing, I bet that would be well-appreciated by many.  What is the Com driver used for the Drillbit devices? Standard USB CDC ACM. |
|
|
|
If anyone wants to elaborate on the README FAQ covering un-Zadig'ing, I bet that would be well-appreciated by many. |
|
|
|
sadly bfgminer does not see my boards
driver is libusbx from windows That's what happens when you have the wrong driver... |
|
|
|
yay... but I literally just compiled 3.9.0 like 2 hours before you posted it and have my drillbits running on bfgminer that way, any new additions in the last 2hrs from git? lol 3.9.0 does not support drillbit... |
|
|
|
This should actually be 265 or higher:
drillbit: Expand allowed external clock range to 0-255
I run my thumbs at 265 all day.
I didn't find any information on how to run with drillbit devices? Did I miss it in the documentation? When I run with no arguments no devices are detected.
Be sure you have the original drivers, no Zadig/WinUSB/libusb nonsense. I'll increase the clock limits in the next version I guess... Don't stop at 265 either... I run my thumbs (with active cooling in winter weather) at 270.  I just made it 65535 in git. Hopefully that's enough. |
|
|
|
This should actually be 265 or higher:
drillbit: Expand allowed external clock range to 0-255
I run my thumbs at 265 all day.
I didn't find any information on how to run with drillbit devices? Did I miss it in the documentation? When I run with no arguments no devices are detected.
Be sure you have the original drivers, no Zadig/WinUSB/libusb nonsense. I'll increase the clock limits in the next version I guess... |
|
|
|
NEW VERSION 3.10.0, JANUARY 15 2014Human readable changelog:- Support for AntMiner U1, Drillbit, and HashFast devices.
- Option --weighed-stats to display share-count columns (A/R) weighed to difficulty 1.
- x6500: maxclock setting (use with --set-device) to limit dynamic clocking range.
- opencl/adl: Fixed crash on exit with R9 series GPUs.
Full changelog:- Downgrade official Windows build compiler to GCC 4.7.3.
- Bugfix: Stratum: Accept JSON Number type for port number
- Bugfix: proxy: Set start timer when creating new virtual devices
- antminer: Add support for the Identify function - flashes LED 10 times
- drillbit: Expand allowed external clock range to 0-255
- drillbit: Forbid setting external clock usage if not supported by device
- Check for DBC_TEMP capability before trying to read temperature
- Bugfix: drillbit: Reduce work message to correct size
- README: Update documentation for new udev rules and "video" group
- Bugfix: opencl/adl: Set iSpeedType for get-fanspeed requests, and ensure we don't change do something weird with the fan when initially setting user-defined speed flag.
- Bugfix: drillbit: Initialise rv variable
- Bugfix: Simplify adding "http://" prefix to avoid strncat overflow (length excludes null byte)
- hashfast: Debuglog work flushing
- hashfast: Implement OP_NONCE search flag
- hashfast: Log seq numbers for nonces found
- hashfast: Count hashes done by nonces found, rather than no-pending-work (which could be triggered by flushes)
- hashfast: Just keep a queue of the 32 most recent work items per core
- hashfast: Convert to minerloop_queue driver model
- hashfast: Gracefully complain if we are given an unknown chip or core address
- udev rule for hashfast devices
- hashfast: New driver using UMS protocol
- CRC-8-CCITT implementation
- AUTHORS: Add Lingchao Xu and move nwoolls up to antminer driver (and mention TwinFury driver for Andreas)
- knc: Workaround false compiler warning about "uninitialised" vars
- Bugfix: drillbit: Access fd after potentially reopening
- Remove Christmas colouring
- drillbit: Add udev rule
- drillbit: Correct configure logic to check for generic bitfury code (needed to decode nonces)
- drillbit: Implement some basic problem recovery
- drillbit: Support identify command
- drillbit: Read/write access to clock and voltage configuration from RPC and ManageTUI
- drillbit: Store board configuration
- drillbit: Read temperature sensor
- drillbit: Check nonces against prev work
- drillbit: Implement mining
- drillbit: Only detection code
- antminer: Initial support for the Bitmain AntMiner U1 ASIC Includes support for identifying the U1 separately from Icarus and Block Erupter Also includes overclocking via --set-device antminer:clock=xHEX
- Extend horizontal lines to full screen width
- Log devid for USB string request failures
- Bugfix: segmentation fault if the terminal window is too narrow for the Help and Quit items
- Accept "address" spelled out in --coinbase-addr option
- Bugfix: document the need to package zlib1.dll in the Windows build instructions
- Bugfix: Stratum: Re-read pool sock var after suspend+restart
- Silence false uninitialised var use warning and calculate dev_runtime only once
- Bugfix: HID API not properly detected on Mac OS X
- Adjust device list size as necessary when accessing options
- Avoid erasing the screen when statusy is not changing
- Abstract common set_statusy code out of change_logwinsize and check_winsizes
- TUI: Support pgup/pgdown for scrolling device list by page
- Bugfix: icarus: quirk_reopen is an int
- Bugfix: Do not allocate spi_port on the Stack, even to initialize - EXC_BAD_ACCESS on OS X
- get_statline3: Simplify statistics gathering
- Bugfix: twinfury: Use serial number formatted over USB, so it works with --scan
- twinfury: Only debuglog temperature debugging data when --device-protocol-dump is enabled
- Bugfix: twinfury: Populate temperature info on both processors
- Option --weighed-stats to display A and R values weighed by difficulty
- README.GPU: Document always-disabled-by-default for OpenCL driver
- AUTHORS: Add Nate Woolls
- Extend menu to full width of window
- Abstract out spaces-to-eol to bfg_wspctoeol function
- Elaborate on spi_port+stack problem in comments
- Bugfix: Do not allocate spi_port on the Stack - EXC_BAD_ACCESS on OS X
- Bugfix: don't attempt to probe Bluetooth devices when scanning hardware
- x6500: Allow overriding the maximum frequency used by the dynclock logic Can now use e.g. --set-device x6500:maxclock=210 Prevents spending time on frequencies that only produce HW errors
- HACKING: Clearly document that dname must be lowercase and alphabetic
- bifury: Tolerate corruption in submit message, remapping shares to the first processor if chip id is unrecognised
- bifury: Tolerate corruption in hwerror message
- bifury: Tolerate corruption in job message, and only count hashes done when completing a known job
- Use a lowercase driver name to fix --scan pattern matching Otherwise the following doesn't work: -S noauto -S twinfury:auto
|
|
|
|
Any idea when you might support HEX16A2 avalon gen 2 boards? Unfortunately, the Technobit boards don't seem to play nicely (ie, work at all) with Linux's CDC driver, so progress on them is slow. |
|
|
|
BTW, in case it wasn't obvious, I'm more than glad to add any GUIs (within reason - must be open source and have some reviews, etc) anyone has to the README under "Q: Is there a GUI version?" Just ping me with info/link. |
|
|
|
Still no Drillbit support...it's only been about 2 months now...
The code is in git, it'll be in 3.10. Hi Luke, thanks for the driver, just tried the latest code with my Drillbits, I have 2 issues: 1. Stats is unavailable for thumbs, so bfgminer causes lots of "Short read in response to 'T'" error. Just adding a "if (dev->procs == 1) return false;" in drillbit_get_stats fixes this for me; 2. The range for external clock should be wider, many people overclock Thumbs to higher than 230. Currently cgminer driver do not limit it, just prints a warning when lower than 80 or higher than 230. Angus of Drillbit Systems had suggested to try 250 for up to 3GH/s with active cooling and enough power (1000mA). I believe I have addressed both of these issues in the latest git code, please test. Thanks |
|
|
|
Hi Luke-Jr, just curious - will long poll support be added to your next version for asicminer blades/cubes?
Not 3.10, no. |
|
|
|
I am trying to understand how exactly the OP_RETURN help us to store sporadic data in the chain, can somebody explain it with some good example. It's not supposed to. Don't store data in the chain. OP_RETURN is like saying "please don't rape me! but if you do, please be gentle". It doesn't justify or make the rape (abuse of the blockchain, in this case) easier. |
|
|
|
Still no Drillbit support...it's only been about 2 months now...
The code is in git, it'll be in 3.10. |
|
|
|
Yes, but if a pool tends to use alternate address in mining, it proves itself malicious. Not at all. Pools are supposed to use a new address for every transaction, just like everyone else. |
|
|
|
who pays the expenses of a zero fee pool, and why? Nothing is free, where is the money coming from?  True dat, what is the reason given for a zero fee pool? What is the owner getting out of it? A fee-free pool to mine on themselves. So, the only benefit to the pool owner (vs. solo mining) of having tons of people to answer to (or ignore as the case may be) and opening yourself up to potential DDoS, is reducing your variability? Does not seem like enough of an incentive to me. That's the whole purpose of pools in general. |
|
|
|
who pays the expenses of a zero fee pool, and why? Nothing is free, where is the money coming from? True dat, what is the reason given for a zero fee pool? What is the owner getting out of it? A fee-free pool to mine on themselves. |
|
|
|
I think the most rational fee system is to have all the bitcoins go to a pot, and the manager of the pool subtracts .1 bitcoins per day and takes 0.5%.
Eligius had something like that originally. Except it was like 0.000864 BTC per day and 0.00005%... |
|
|
|
|
Show Posts
