Here's some quick documentation I wrote up from the cgminer driver code, in preparation of writing the BFGMiner driver: L Identify* I Get info 0x10 bytes response: uint8: protocol version protocol version 2 has an implicit external clock if chip count is 1 char[8]: product name if "DRILLBIT", fill in "Thumb" or "Eight" appropriately uint32le: serial number uint8: chip count uint16le: capability bitmask 0x0001 Temperature sensor 0x0002 External clock R Reset* C Configure Request followed by 6 bytes: 1 byte: core voltage config 0x01 850mV uint8: clock level uint8: "clock_div2" uint8: use external clock? 0 or 1 uint16le: external clock frequency 1 byte response: 'C' T Get temperature 2 byte response: uint16le: Temperature in decidegrees celcius E Get completed work Response: uint32le: number of works finished (max 1024) For each work, 68 bytes: uint16le: chip id uint8: number of nonces found (max 16) uint8: non-zero if chip idle, otherwise 0 if busy uint32le[16]: nonces W Send work to chip Request followed by 46 bytes: uint16le: chip id uint256le: midstate uint8[12]: data tail 1 byte response: 'W'
|
|
|
There isn't a problem with solo mining nor GBT here. The entity which controls the hardware has control of it period.
|
|
|
Also. What software driver is needed to comm with the Klondike series. Receiving 2 later today
Klondike is a direct USB device, so use Zadig for it.
|
|
|
Just picked up a Bitburner Fury - how is bfg's support for these things?
Also got a Bitburner XX (Avalon chips). Again, I assume bfg supports these things? Not sure why you assume that. Bitburner still hasn't provided and docs, sample units, code, or even communicated.
|
|
|
Cīmon Luke. You can I don't have time for what I'm already working on, let alone taking on something mostly pointless like this.
|
|
|
Are we ever going to get Drillbit support?
Yes, this is on my table. Just busy moving still, so not as much free time as usual
|
|
|
The most obvious way to do this would be to produce a minimal patch that rebrands Bitcoin-Qt based on a xml config file, then generate new ZIP files for it on the fly with a custom xml config
|
|
|
You can't mine via using a GPU in a VM anyway, so you're barking up the wrong tree. You can if you run an AMD CPU or an Intel CPU with VT-d support (note: not VT-x).
|
|
|
When running a windows terminal, how do you configure/disable the colors of the terminal?
I want to remove of the red background on the top line, remove the blue background on the second line, and change the top line font color to the default light-grey.
Basically I want the entire window to be a uniform black background and light grey text.
Not supported at this time. What is the use case?
|
|
|
That's interesting, somehow bfgminer 3.9.0 or btcguild pool switched from worker's diff 8 to diff 16 with olddifficulty rejection message ...
Expected. There is a workaround for very old (no longer a problem?) pools that treated difficulty wrong. This results in invalid shares being submitted unnecessarily, but is otherwise harmless. Seems strange, because bfgminer never lowers the diff, even if it is set to lower number in worker's property while mining. Can bfgminer only get worker difficulty correctly only at start? It does, just not right away. Essentially it works as lowest-of(job-difficulty, current-difficulty)
|
|
|
That's interesting, somehow bfgminer 3.9.0 or btcguild pool switched from worker's diff 8 to diff 16 with olddifficulty rejection message [2014-01-04 23:43:21] Accepted 194f432f NFY 3 pool 0 Diff 10/8 [2014-01-04 23:43:21] Stratum from pool 0 requested work update [2014-01-04 23:43:21] Pool 0 stale share detected, submitting as user requested [2014-01-04 23:43:21] Rejected 1795e873 NFY 5 pool 0 Diff 10/8 (olddifficulty) [2014-01-04 23:43:21] Rejected 0cb8968a BPM 1 pool 0 Diff 20/8 (olddifficulty) [2014-01-04 23:43:22] Pool 0 stale share detected, submitting as user requested [2014-01-04 23:43:22] Rejected 1536fed3 BPM 0 pool 0 Diff 12/8 (olddifficulty) [2014-01-04 23:43:25] Accepted 0491d025 NFY 2 pool 0 Diff 56/16 btw, 6NFY+2BPM around 20GH/s. Worker's diff is set to 8 instead 16 intentionally in btcguild worker's properties. After restart it happened again without olddifficulty rejection message: [2014-01-07 23:37:23] Accepted 07a5238f NFY 1 pool 0 Diff 33/8 [2014-01-07 23:37:23] Stratum from pool 0 requested work update [2014-01-07 23:37:24] Accepted 00313cb6 NFY 2 pool 0 Diff 1.33k/16 [2014-01-07 23:37:27] Accepted 06385d7a BPM 0 pool 0 Diff 41/16 Expected. There is a workaround for very old (no longer a problem?) pools that treated difficulty wrong. This results in invalid shares being submitted unnecessarily, but is otherwise harmless.
|
|
|
Make sure you used Zadig to install the driver for the IceFurys. It is needed for those. It shouldn't be... Icefury is just a nanofury, right? Those are HID...
|
|
|
This should really offer all the Bitcoin pull requests as optional features to include... For unmergable ones, it can have a warning that you will need to wait 3 days for a quote, and (after confirming the deposit) allow competent developers to bid on merging it.
|
|
|
Please add: - Prime POW support
- Unit system config (decimal, tonal, dozenal, octal)
- Mac builds (this should be simple now that gitian can do it)
- BitcoinTalk announcement post creator
Bonus if you can setup automatic pool hosting...
|
|
|
Sounds like Luke-Jr has his Baby-Jet and is trying to get it going at full speed (30gh/s at last check with cgminer and bfgminer). Check out the Eligius IRC channel for more info. 30gh/s? I don't even know if should i cry or should i laugh. This is just with unfinished code, and possibly some problems with the unit. Also, it's 30 Gh/s average. More like 600 Gh/s (haven't measured exactly), but not working 95% of the time. I know it's not your code, but while you're sleeping, can you fire it up with cgminer and tell us what happens? I'm somehow doubting that it's going to churn along happily at 400gh+. cgminer was working for a few seconds then losing the device, detected it again, repeat. I tracked this down to an unconnected power cable. Now that the power cable is connected, cgminer is churning along happily at over 400 Gh/s. BFGMiner is still only getting 40 Gh/s, but that's my job to finish the code
|
|
|
Sounds like Luke-Jr has his Baby-Jet and is trying to get it going at full speed (30gh/s at last check with cgminer and bfgminer). Check out the Eligius IRC channel for more info. 30gh/s? I don't even know if should i cry or should i laugh. This is just with unfinished code, and possibly some problems with the unit. Also, it's 30 Gh/s average. More like 600 Gh/s (haven't measured exactly), but not working 95% of the time.
|
|
|
There, you lazy bums... http://speedy [Adware link broken by mods] .sh/GtUYH/Refund-Request-Form-Customer-Rights-Enabled-Edition.doc Looks like a virus at the link above, beware!
|
|
|
Update on my investigations on ARM and NFY;-
Arch Linux on x86/64 bfgminer 3.9.0 = No problems, works as expected.
Arch Linux on Raspberry Pi (ARMv6) bfgminer 3.9.0 = Detects but cannot initialize, often segfaults and core dumps.
Rasberian on Raspberry Pi (ARMv6) bfgminer 3.9.0 = Detects but cannot initialize, often segfaults and core dumps.
Arch Linux on CubieBoard2 (ARMv7) bfgminer 3.9.0 = Detects, initializes, bfgminer often has to reset the NFY's because the hashrate falls below 50%, often segfaults and core dumps.
Arch Linux on BeagleBone Black (ARMv7) bfgminer 3.9.0 = Detects, initializes, occasionally segfaults and core dumps. Does not handle unplug events and a restart (of bfgminer or the ARM device) will often leave the NFY's locked. Curious you have trouble on non-RPI platforms too... Can you post backtraces for those crashes?
|
|
|
Yes, my mistake/misunderstanding: the unit I received is apparently an engineering sample.
|
|
|
Hi Luke,
Hope the holiday session is going well.
I am struggling and need a hand with NFY devices on the Raspberry PI. It's the usual "Raspberry Pi has broken USB" problem... workaround seems to be to set it to USB 1.1 mode (dwg_otc.speed=1 in cmdline.txt).
|
|
|
|