Is CPU mining with bfgminer possible for scrypt? I see the algo setting for SSH256 cpu mining, but only do ASICs for that now. Would like to have bfgminer do both GPU and CPU scrypt mining in one instance if possible.
Yes, the algo setting is not valid in scrypt mode (there is only one not-really-optimise algo). |
|
|
|
|
Been doing a lot of major cleanups to the OpenCL driver as part of the big 4.0 release upcoming, bringing it up to par with the rest of the drivers.
I'm wondering if anyone uses the --gpu-dyninterval option, or has ever had any success with it?
Looking at the code, it seems to be broken and do the opposite of what it claims...
If nobody cares about it, I'll probably just remove it entirely.
|
|
|
|
Is there an easy way to replug AntMiner U1 device in bfgminer? New cgminer introduced a menu to work with broken USB devices. From time to time, U1 device dies, it is not mining and it is not dead, like in this example, AMU 3 device was mining for some time at 2GHps but it is not mining for a while (or mining at low hashrate): 4 | 8.35/ 8.33/ 6.61Gh/s | A:3492 R:1+0(.03%) HW:0/none
--------------------------------------------------------------------------------
AMU 0: | 2.06/ 2.06/ 1.99Gh/s | A:1015 R:0+0(none) HW:0/none
AMU 1: | 2.07/ 2.06/ 2.01Gh/s | A:1084 R:1+0(.09%) HW:0/none
AMU 2: | 2.06/ 2.06/ 1.99Gh/s | A:1081 R:0+0(none) HW:0/none
AMU 3: | 2.10/ 2.14/ 0.62Gh/s | A: 314 R:0+0(none) HW:0/none
--------------------------------------------------------------------------------
I am not sure what is a problem but devices were running at 2GHps for several days but they make trouble today... ;-) I know, I can restart bfgminer, it will fix the problem. That's odd, BFGMiner's watchdog should automatically restart it in this case... Any idea what's going on that stops it? |
|
|
|
Hi guys i had two miners that now i use with cgminer, but i want do the same thing with bfgminer.
The miners are 1 Technobit Hex16A2 and 1 BitBurner 52GH/s
How i can find the drivers to use them in BFGminer?
TechnoBit HEX16A2: For some reason, these are incompatible with Linux's USB CDC/ACM drivers, so I have been unable to complete a driver for them; while I've tried to get Linux developers involved to fix it, they just don't seem interested. In lieu of that, I recently shipped the sample unit to nwoolls, who does his development on Mac/Windows, and will be sending him my notes and incomplete driver code so he can complete it. BitBurner: No contact, docs, or samples from this vendor. Support is not planned at this time. Please contact the manufacturer and/or vendors to recommend they get in touch. |
|
|
|
|
BFGMiner git (and therefore the next version) has added support for NF2.
|
|
|
|
|
My GPU VM isn't working lately; does anyone have a GPU mining rig I can do some testing on via SSH?
|
|
|
|
I am getting a warning in eloipool.log file 2014-02-16 02:48:08,360 merkleMaker CRITICAL Traceback (most recent call last):
File "/opt/eloipool-server/eloipool/merklemaker.py", line 692, in run
self.merkleMaker_I()
File "/opt/eloipool-server/eloipool/merklemaker.py", line 682, in merkleMaker_I
self.merkleMaker_II()
File "/opt/eloipool-server/eloipool/merklemaker.py", line 648, in merkleMaker_II
return self._updateMerkleTree()
File "/opt/eloipool-server/eloipool/merklemaker.py", line 548, in _updateMerkleTree
self._updateMerkleTree_I()
File "/opt/eloipool-server/eloipool/merklemaker.py", line 512, in _updateMerkleTree_I
r = self._updateMerkleTree_fromTS(TS)
File "/opt/eloipool-server/eloipool/merklemaker.py", line 477, in _updateMerkleTree_fromTS
MP = self._CallGBT(TS)
File "/opt/eloipool-server/eloipool/merklemaker.py", line 327, in _CallGBT
MP = access.getblocktemplate(self.GBTReq)
File "/opt/eloipool-server/eloipool/bitcoinrpc/authproxy.py", line 112, in __call__
'Content-type': 'application/json'})
File "/usr/lib/python3.2/http/client.py", line 967, in request
self._send_request(method, url, body, headers)
File "/usr/lib/python3.2/http/client.py", line 995, in _send_request
self.putrequest(method, url, **skips)
File "/usr/lib/python3.2/http/client.py", line 850, in putrequest
raise CannotSendRequest(self.__state)
http.client.CannotSendRequest: Request-sent
What is it and how to get read of it? Thanks, This seems to be yet another bug in the latest bitcoinrpc. Eligius runs 22e290b0bcabf6bc88b4d3f5a7d074677e8fe7b9 |
|
|
|
Sorry being such a bother. I looked at the source on github and found some pointers on how I can set the clock on the BabyJet. static const struct bfg_set_device_definition hashfast_set_device_funcs_probe[] = {
{"clock", hashfast_set_clock, "clock frequency (can only be set at startup, with --set-device)"},
{NULL},
}; Is clock rate setting through --set-device really implemented? What would be the argument? I tried things like --set-device HFA:clock=600 which didn't seem to work Are you actually running the code from git? That being said, I didn't test this yet either... but it's so simple I'd be surprised by a bug. |
|
|
|
Telling Windows to use its standard CDC driver tends to be relatively simple.
Is this that Windows INF business? If so I can link to some files and give some pointers. Yes |
|
|
|
No, WinUSB/etc just expose a raw USB interface to software.
Ok, so I guess if there is no driver for it for windows, then it wont work on windows (not that I'm aware of any manufacturer driver for linux) Thanks for your help. Telling Windows to use its standard CDC driver tends to be relatively simple. |
|
|
|
Just to clarify, there is no "emulating a com port" going on, VCOM is a native OS interface on every OS.
So that's what the generic drivers like WinUSB, libusb-win32 and libusbk are for? No, WinUSB/etc just expose a raw USB interface to software. |
|
|
|
|
Just to clarify, there is no "emulating a com port" going on, VCOM is a native OS interface on every OS.
|
|
|
|
I tried BFGminer 3.10 on win7 on my Hashfast Babyjet yesterday and even tho the "M1" device was listed as an USB device during startup, BFGMiner didn't detect it as a device.
I looked at the readme files but couldn't find any mentioning of the babyjet, even tho release notes state it's supported.
Can anybody help me out?
HashFast uses a USB CDC protocol, so you'll need the correct CDC driver. I'm not sure if they've made an official one yet or not. |
|
|
|
Quick sanity check/question...
I tested bfgminer out against my scrypt alt coin pre-launch and it worked great, although the number of stale shares was high. I'm trying it now post-launch, with a network hashrate of around 8MHash/sec.
I would think I didn't have it setup right, but I've seen it accept all of ONE share in about 20 minutes.
Is that normal? Is the wallet server (one of the dnsseed machines) just too busy to serve up shares? I'm not seeing any errors from bfgminer:
bfgminer version 3.10.0 - Started: [2014-02-14 19:11:16] - [ 0 days 00:24:57]
[M]anage devices [P]ool management [ S]ettings [D]isplay options [H]elp [Q]uit
Connected to nibble diff 1 without LP as user nibblerpc
Block: ...935339f78f5705f0 Diff:1 ( 7.16Mh/s) Started: [19:34:39]
ST:5 F:0 NB:7 AS:0 BW:[ 64/ 31 B/s] E:0.01 I: 0.00 BTC/hr BS:2
3 79.0C | 1.07/ 1.07/ 2.90Mh/s | A:1 R:0+0(none) HW:0/none
---------------------------------------------------------------------------------
OCL 0: 79.0C | 466.3/464.0/ 0.0kh/s | A:0 R:0+0(none) HW:0/none
OCL 1: 78.0C | 0.47/ 0.46/ 2.88Mh/s | A:1 R:0+0(none) HW:0/none
OCL 2: | 141.1/140.4/ 0.0kh/s | A:0 R:0+0(none) HW:0/none
---------------------------------------------------------------------------------
[2014-02-14 19:14:25] New block detected on network
[2014-02-14 19:16:26] New block detected on network
[2014-02-14 19:21:23] Found block for pool 0!
[2014-02-14 19:21:23] Accepted 00006227 OCL 1 Diff 2/1
[2014-02-14 19:21:23] New block detected on network
[2014-02-14 19:21:23] New block detected on network
[2014-02-14 19:26:33] New block detected on network
Something just feels wrong, and I've connected to pools for my coin and been served right up.
Hmmm, am I just thinking about this wrong? The rate would make sense if it was only reporting actual blocks that I found, not just work shares. Wondering about that since its apparently doing something on CL 0 and 2... Diff 1 is very high for scrypt. |
|
|
|
Does -S bfl:all work? I thought we had to use -S bitforce:all for the Butterfly Labs gear (bitforce is the name of their current gen chip)? "bfl" (or any other TLA) will select all drivers providing said TLA devices. |
|
|
|
|
I'd be interested in XMPP control (ideally with a nice button-based interface).
|
|
|
|
The one I pulled less than 2 hours ago? Is there a way for me to ID what I pulled?
All the files are timestamped 2/9/2014 around 23:07 - but I'm GMT -6 (US Central).
I apologize for not really understanding git beyond how to fetch things.
Oh... I have no idea if this is significant, but miner #1, which is working as expected, has an Intel CPU. Miners #2 and #3 that are being quirky are AMD. Beyond that, they are pretty similar setups.
git checkout 223df8d && make (test this) git checkout c675a33 && make (test this) git checkout 98e5076 && make (test this) Started with a fresh clone: git clone https://github.com/luke-jr/bfgminercd bfgminer ./autogen.sh ./configure -enable-opencl --enable-scrypt make -j3 And reproduced the problem. git checkout 223df8d make problem still there. git checkout 98e5076 make problem still there. Very weird that its working normally on one of the three machines. git checkout 223df8d make problem still there. Hrm, that means my refactors didn't do it after all!  Can you post your (original checkout)'s .git/logs/HEAD file so we can figure out what the last version that worked for you was? |
|
|
|
Hi guys, I'm gonna try to steal 5 minutes of your time  I just updated my ubuntu host running 11 block erupters. BFGMiner updated to 3.10.0 and now none of the erupters are showing up. My configuration file only contains pool conf, and bfgminer runs with the -S erupter:all switch. I already tried adding devices manually (M+), one at time and all at once, but no luck. Am I doomed?  Check that you're in the "video" UNIX group. |
|
|
|
The one I pulled less than 2 hours ago? Is there a way for me to ID what I pulled?
All the files are timestamped 2/9/2014 around 23:07 - but I'm GMT -6 (US Central).
I apologize for not really understanding git beyond how to fetch things.
Oh... I have no idea if this is significant, but miner #1, which is working as expected, has an Intel CPU. Miners #2 and #3 that are being quirky are AMD. Beyond that, they are pretty similar setups.
git checkout 223df8d && make (test this) git checkout c675a33 && make (test this) git checkout 98e5076 && make (test this) |
|
|
|
|
More likely I broke that... Can you perhaps pinpoint which commit caused the problem?
Thanks
|
|
|
|
|
Show Posts
