OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB

[everest556]

How soon are we going to see support for Technobit's HEX16A2?

[Luke-Jr]

Pushed a "gridseed" branch to the main BFGMiner git based on nwoolls's code.
I'm not sure how these are supposed to perform, but I get some inconsistent results in benchmark mode:

Code:

DMU 0:       |  36.8/ 68.2/ 41.7kh/s | A: 28 R:0+0(none) HW:0/none
GSD 0:       |  0.73/ 1.27/ 0.17Mh/s | A:112 R:0+0(none) HW:8/none

How's it work for others who have been using them in production?

[Mr. Jinx]

How's it work for others who have been using them in production?

I'm running this for a while now with good results:

Code:

 bfgminer version 3.99.0 - Started: [2014-04-04 21:06:45] - [  0 days 12:18:32]
 [M]anage devices [P]ool management [S]ettings [D]isplay options                        [H]elp [Q]uit
 Connected to x diff 1m with stratum as user x
 Block: ...b53afe02 #544104  Diff:5.75k (41.13Gh/s)  Started: [09:24:58]
 ST:102  F:0  NB:305  AS:0  BW:[  3/  0kB/s]  E:0.00  I:11.33mBTC/hr  BS:196
 0            |  6.95/ 7.01/ 6.21Mh/s | A:26713 R:2704+0(8.6%) HW:17/none
------------------------------------------------------------------------------------------------------
 GSD 0:       | 338.6/348.9/264.6kh/s | A: 1138 R: 119+0(none) HW: 0/none
 GSD 1:       | 346.6/350.5/323.2kh/s | A: 1388 R: 128+0(none) HW: 0/none
 GSD 2:       | 344.4/351.1/320.7kh/s | A: 1383 R: 135+0(none) HW: 0/none
 GSD 3:       | 339.4/349.2/283.3kh/s | A: 1207 R: 111+0(none) HW: 0/none
 GSD 4:       | 338.4/350.2/300.9kh/s | A: 1303 R: 147+0(none) HW: 0/none
 GSD 5:       | 345.4/350.6/316.2kh/s | A: 1359 R: 155+0(none) HW: 0/none
 GSD 6:       | 345.4/351.0/330.8kh/s | A: 1431 R: 142+0(none) HW: 0/none
 GSD 7:       | 356.6/350.8/334.8kh/s | A: 1435 R: 132+0(none) HW: 0/none
 GSD 8:       | 343.9/350.6/329.5kh/s | A: 1415 R: 122+0(none) HW: 0/none
 GSD 9:       | 349.7/350.1/303.3kh/s | A: 1314 R: 116+0(none) HW: 0/none
 GSD10:       | 347.2/349.6/295.9kh/s | A: 1272 R: 143+0(none) HW: 0/none
 GSD11:       | 357.0/350.5/307.9kh/s | A: 1332 R: 144+0(none) HW:12/none
 GSD12:       | 344.4/348.9/271.1kh/s | A: 1167 R: 116+0(none) HW: 0/none
 GSD13:       | 339.6/350.2/318.7kh/s | A: 1358 R: 130+0(none) HW: 0/none
 GSD14:       | 352.7/350.3/310.1kh/s | A: 1330 R: 164+0(none) HW: 0/none
 GSD15:       | 344.9/350.5/317.0kh/s | A: 1372 R: 148+0(none) HW: 0/none
 GSD16:       | 347.0/350.2/312.9kh/s | A: 1342 R: 130+0(none) HW: 1/none
 GSD17:       | 342.5/351.2/335.5kh/s | A: 1440 R: 156+0(none) HW: 0/none
 GSD18:       | 344.6/350.6/316.4kh/s | A: 1350 R: 129+0(none) HW: 4/none
 GSD19:       | 351.0/351.1/320.8kh/s | A: 1387 R: 138+0(none) HW: 0/none
------------------------------------------------------------------------------------------------

This is on p2pool so rejects are a bit high. Only wish for now is individual freq settings.
Right now it's running gridseed-support-clean branche. With the default branche the hashrates looked higher (but maybe it is more accurate now?).

[everest556]

Pushed a "gridseed" branch to the main BFGMiner git based on nwoolls's code.
I'm not sure how these are supposed to perform, but I get some inconsistent results in benchmark mode:

Code:

DMU 0:       |  36.8/ 68.2/ 41.7kh/s | A: 28 R:0+0(none) HW:0/none
GSD 0:       |  0.73/ 1.27/ 0.17Mh/s | A:112 R:0+0(none) HW:8/none

How's it work for others who have been using them in production?

The gridseed support works fine, at least it does for me on Win7-64. How about implementing the support for Technobit Hex boards?

[Taugeran]

Pushed a "gridseed" branch to the main BFGMiner git based on nwoolls's code.
I'm not sure how these are supposed to perform, but I get some inconsistent results in benchmark mode:

Code:

DMU 0:       |  36.8/ 68.2/ 41.7kh/s | A: 28 R:0+0(none) HW:0/none
GSD 0:       |  0.73/ 1.27/ 0.17Mh/s | A:112 R:0+0(none) HW:8/none

How's it work for others who have been using them in production?

The gridseed support works fine, at least it does for me on Win7-64. How about implementing the support for Technobit Hex boards?

He has tried in the past. The controller on the boards doesn't play nice with linux's USB CDC driver

[Luke-Jr]

Pushed a "gridseed" branch to the main BFGMiner git based on nwoolls's code.
I'm not sure how these are supposed to perform, but I get some inconsistent results in benchmark mode:

Code:

DMU 0:       |  36.8/ 68.2/ 41.7kh/s | A: 28 R:0+0(none) HW:0/none
GSD 0:       |  0.73/ 1.27/ 0.17Mh/s | A:112 R:0+0(none) HW:8/none

How's it work for others who have been using them in production?

The gridseed support works fine, at least it does for me on Win7-64. How about implementing the support for Technobit Hex boards?

He has tried in the past. The controller on the boards doesn't play nice with linux's USB CDC driver

^ this; which is why I sent it on to nwoolls who works on Mac/Windows.
He's away right now, but perhaps when he gets home he can comment on where it is on his todo list.

[yeahright]

Pushed a "gridseed" branch to the main BFGMiner git based on nwoolls's code.
I'm not sure how these are supposed to perform, but I get some inconsistent results in benchmark mode:

Code:

DMU 0:       |  36.8/ 68.2/ 41.7kh/s | A: 28 R:0+0(none) HW:0/none
GSD 0:       |  0.73/ 1.27/ 0.17Mh/s | A:112 R:0+0(none) HW:8/none

How's it work for others who have been using them in production?

I've been using it for a while with my gridseeds with no issues but with the dualminers every time it hits a HW error it seems to stop submitting shares to the pool. I could go to manage devices disable processor and reenable and it submits shares for a bit then stops.  I've compiled it twice and still the same both times.

[chup]

Pushed a "gridseed" branch to the main BFGMiner git based on nwoolls's code.
I'm not sure how these are supposed to perform, but I get some inconsistent results in benchmark mode:

Code:

DMU 0:       |  36.8/ 68.2/ 41.7kh/s | A: 28 R:0+0(none) HW:0/none
GSD 0:       |  0.73/ 1.27/ 0.17Mh/s | A:112 R:0+0(none) HW:8/none

How's it work for others who have been using them in production?

I've been using it for a while with my gridseeds with no issues but with the dualminers every time it hits a HW error it seems to stop submitting shares to the pool. I could go to manage devices disable processor and reenable and it submits shares for a bit then stops.  I've compiled it twice and still the same both times.

That's why I lovered Dualminer frequency to 800, but this only makes babysitting Dualminers easier, not eliminating it.

[roy7]

I was wondering if you could add JSONP commands to your APIs.
JSONP extension of your APIs would allow to access bfgminer directly from any static (local to browser) page.
AJAX calls can be made from the browser directly to API port.  No cross-domain issues.

How about CORS? That seems to be the way to go nowadays...?

With CORS wouldn't the miner need to run a mini web server and return a Access-Control-Allow-Origin: header?

Edit: JSONP would be the same I guess. Doh.

[yeahright]

Pushed a "gridseed" branch to the main BFGMiner git based on nwoolls's code.
I'm not sure how these are supposed to perform, but I get some inconsistent results in benchmark mode:

Code:

DMU 0:       |  36.8/ 68.2/ 41.7kh/s | A: 28 R:0+0(none) HW:0/none
GSD 0:       |  0.73/ 1.27/ 0.17Mh/s | A:112 R:0+0(none) HW:8/none

How's it work for others who have been using them in production?

I've been using it for a while with my gridseeds with no issues but with the dualminers every time it hits a HW error it seems to stop submitting shares to the pool. I could go to manage devices disable processor and reenable and it submits shares for a bit then stops.  I've compiled it twice and still the same both times.

That's why I lovered Dualminer frequency to 800, but this only makes babysitting Dualminers easier, not eliminating it.

I've tried it clocked at 850 and default.  It does run a little longer but still stops.

[chiefstank]

devs, are you in need of a hex16a2 for getting technobit working?

[salfter]

Pushed a "gridseed" branch to the main BFGMiner git based on nwoolls's code.
I'm not sure how these are supposed to perform, but I get some inconsistent results in benchmark mode:

Code:

DMU 0:       |  36.8/ 68.2/ 41.7kh/s | A: 28 R:0+0(none) HW:0/none
GSD 0:       |  0.73/ 1.27/ 0.17Mh/s | A:112 R:0+0(none) HW:8/none

How's it work for others who have been using them in production?

I've had his features/gridseed-support-clean (IIRC) branch running for a few days now with a half-dozen Gridseeds hanging off a Raspberry Pi.  So far, it's been running like a champ.

(I should probably clarify that I have the round 5-chip miner, and I'm using it for scrypt mining only.  WeMineAll says I'm delivering a bit over 2 MH/s.  I've not tried enabling dual-mining since some early crashy attempts with other software when I got my first two Gridseeds.)

[ThomasMuller]

First I would like to thank Luke Jr for his hard work.

Gentlemen,

I have some questions about running BFG with Gridseed. Under Windows 7 -64bit

a. How can I specify the COM ports to use instead of relying on auto detection? let's say I have 6 units. I would like to do something like -d grid 3,4,5,6,7,8 where each would be the COM port.

b. sometimes the third column gets stuck showing 0.0kh/s. I read that this is what the pool is receiving. It looks like that the Gridseed is ok because the first and the second are updating consistently. so what should we do in this case? I already tried to manually disable/enable from within BFG but no luck the only way that is working for me is to quit/restart BFG multiple times until I get lucky. But I don't want to depend on luck!

c. in the case of a power outage or power cycle is there any way to delay startup of these devices? I think it is bad if they all come to life at the same time. I would like to implement a more controlled boot sequence.

Thank you and Hash Speed! ;-)

Gilson

[salfter]

a. How can I specify the COM ports to use instead of relying on auto detection? let's say I have 6 units. I would like to do something like -d grid 3,4,5,6,7,8 where each would be the COM port.

I have two bfgminer instances running on a Raspberry Pi, one controlling Bitfury and BFL hardware for SHA256 mining and another controlling Gridseed hardware for scrypt mining.  The config files for each are set to only look for the relevant hardware.  bfgminer.conf.sha256 includes these statements (among others):

Code:

"scan" : [
        "bfsb:auto",
        "bitforce:/dev/ttyUSB0",
        "bitforce:/dev/ttyUSB1"
],
"set-device" : [
        "BSB:osc6_bits=52"
],

bfgminer.conf.scrypt, by comparison, includes these:

Code:

"scan" : [
        "gridseed:/dev/ttyACM0",
        "gridseed:/dev/ttyACM1",
        "gridseed:/dev/ttyACM2",
        "gridseed:/dev/ttyACM3",
        "gridseed:/dev/ttyACM4",
        "gridseed:/dev/ttyACM5"
],
"set-device" : [
        "gridseed:clock=850"
],

Since the BFL and Gridseed miners are both USB devices, I needed to tell each instance which devices to use. (The Bitfury hardware is connected to the Raspberry Pi's GPIO header, so auto-detect works for that.) Something similar ought to be possible under Windows, but I don't have direct experience with mining on Windows as I've always used Linux for this purpose.  You'd most likely want to replace occurrences of /dev/tty* with something else.

[ThomasMuller]

Code:

"scan" : [
        "gridseed:/dev/ttyACM0",
        "gridseed:/dev/ttyACM1",
        "gridseed:/dev/ttyACM2",
        "gridseed:/dev/ttyACM3",
        "gridseed:/dev/ttyACM4",
        "gridseed:/dev/ttyACM5"
],

no experience with mining on Windows as I've always used Linux for this purpose.  You'd most likely want to replace occurrences of /dev/tty* with something else.

I was going to say "/dev/tty*" is Linux naming convention for serial ports. Does anyone know if "gridseed:COMx" would work?

Thanks,

Gilson

[Mr. Jinx]

For windows it should be something like "gridseed:\\.\COM5"

ps: Nwoolls just told me it's also possible to set frequency per gridseed. I didn't know this was possible.
Not easy to match a gridseed in bfgminer with a linux device, but works great!

Example:

Code:

"set-device" : [
        "gridseed@/dev/ttyACM0:clock=825",
        "gridseed@/dev/ttyACM1:clock=875",
        "gridseed@/dev/ttyACM2:clock=825",
        "gridseed@/dev/ttyACM3:clock=850",
        "gridseed@/dev/ttyACM4:clock=850",
        "gridseed@/dev/ttyACM5:clock=875",
        "gridseed@/dev/ttyACM6:clock=850",
        "gridseed@/dev/ttyACM7:clock=850",
        "gridseed@/dev/ttyACM8:clock=850",
        "gridseed@/dev/ttyACM9:clock=875"
]

[Luke-Jr]

Does anyone use the E(fficiency) displayed on the TUI? Any other options I can deprecate to make more room for new ones? :p

[rupy]

Can you underclock bfl singles with bfgminer somehow?

[hurricandave]

Does anyone use the E(fficiency) displayed on the TUI? Any other options I can deprecate to make more room for new ones? :p

   I don't pay much attention to it but I would add that with BTC mining you are not likely to find the PPS value "I" relevant much these days either. Even BTCGuild has abandoned PPS completely.

[cafminer1]

Does anyone use the E(fficiency) displayed on the TUI? Any other options I can deprecate to make more room for new ones? :p

I would like it to be replaced by the old "accepted shares per minute", a good measure of miners performance.

BTW [H]elp says U = shares per minute, but it s not displayed nor I can find how or where to turn it on...

Thanks!