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

Mr. Jinx

member

Activity: 112

Merit: 10

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"
]

ThomasMuller

full member

Activity: 141

Merit: 100

Quote from: salfter on April 08, 2014, 11:10:58 AM

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

salfter

hero member

Activity: 651

Merit: 501

My PGP Key: 92C7689C

Quote from: ThomasMuller on April 08, 2014, 10:50:11 AM

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

full member

Activity: 141

Merit: 100

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

hero member

Activity: 651

Merit: 501

My PGP Key: 92C7689C

Quote from: Luke-Jr on April 05, 2014, 04:05:08 AM

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.)

chiefstank

member

Activity: 81

Merit: 10

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

yeahright

full member

Activity: 297

Merit: 100

Quote from: chup on April 06, 2014, 05:58:42 AM

Quote from: yeahright on April 05, 2014, 04:41:32 PM

Quote from: Luke-Jr on April 05, 2014, 04:05:08 AM

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.

roy7

sr. member

Activity: 434

Merit: 250

Quote from: Luke-Jr on October 27, 2013, 03:05:47 PM

Quote from: af_newbie on September 12, 2013, 04:28:26 PM

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.

chup

sr. member

Activity: 736

Merit: 262

Me, Myself & I

Quote from: yeahright on April 05, 2014, 04:41:32 PM

Quote from: Luke-Jr on April 05, 2014, 04:05:08 AM

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.

yeahright

full member

Activity: 297

Merit: 100

Quote from: Luke-Jr on April 05, 2014, 04:05:08 AM

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.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Taugeran on April 05, 2014, 02:32:18 PM

Quote from: everest556 on April 05, 2014, 10:11:57 AM

Quote from: Luke-Jr on April 05, 2014, 04:05:08 AM

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.

Taugeran

hero member

Activity: 658

Merit: 500

CCNA: There i fixed the internet.

Quote from: everest556 on April 05, 2014, 10:11:57 AM

Quote from: Luke-Jr on April 05, 2014, 04:05:08 AM

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

everest556

newbie

Activity: 38

Merit: 0

Quote from: Luke-Jr on April 05, 2014, 04:05:08 AM

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?

Mr. Jinx

member

Activity: 112

Merit: 10

Quote from: Luke-Jr on April 05, 2014, 04:05:08 AM

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?).

Luke-Jr

legendary

Activity: 2576

Merit: 1186

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?

everest556

newbie

Activity: 38

Merit: 0

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

chanberg

hero member

Activity: 672

Merit: 500

Wonder if the auto dynamic freq change ever been implemented for the gridseeds? Would be nice if bfgminer just auto dialed the freq and let it do its thing to find its best frequency

pauljbl

newbie

Activity: 39

Merit: 0

Nwools and Luke have you ever tried 15 Nanofurys on Linux as wondering if the drivers are buggy as on the same machine with windows they run fine.

MobGod

hero member

Activity: 532

Merit: 500

Quote from: Mr. Jinx on April 04, 2014, 01:39:47 PM

If you mean Linux, check out these steps:
https://bitcointalksearch.org/topic/m.5734631

Instead of "git clone -b feature/gridseed-support https://github.com/nwoolls/bfgminer" you can do:
"git clone -b feature/gridseed-support-new https://github.com/nwoolls/bfgminer.git"

I think the "gridseed-support-clean" branch is even newer so you may want to try that one.
Not sure if this branch is advised to use though.

ps: How about individual freq. settings per miner that auto adjust automatically? Would be cool to get optimized results.

no i need it for windows this is the source
https://github.com/nwoolls/bfgminer/tree/feature/gridseed-support-new

Mr. Jinx

member

Activity: 112

Merit: 10

If you mean Linux, check out these steps:
https://bitcointalksearch.org/topic/m.5734631

Instead of "git clone -b feature/gridseed-support https://github.com/nwoolls/bfgminer" you can do:
"git clone -b feature/gridseed-support-new https://github.com/nwoolls/bfgminer.git"

I think the "gridseed-support-clean" branch is even newer so you may want to try that one.
Not sure if this branch is advised to use though.

ps: How about individual freq. settings per miner that auto adjust automatically? Would be cool to get optimized results.

Topic: OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 10. (Read 1193208 times)