[GUIDE] BitFury Miner Support/Tuning

[zurg]

Try setting '25 aIfDSo 0' then the chips 25-32 will hash too.

24      AIfDSo  55      1.288   1.328   48      0       0       0       67      [1:7]   710     3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3         0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
25      aIfDSo  0       0.000   0.277   0       0       0       0       14      [1:8]   756     0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0         0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
speed:1320 noncerate[GH/s]:25.152 (1.006/chip) hashrate[GH/s]:28.459 good:937 errors:72 spi-err:0 miso-err:1 jobs:140 cores:5% good:25 bad:0 off:0 (best[GH/s]:0.000) Tue Sep 10 17:22:37 2013
0:      880     15.650  17.499  583     54      0       1       16      0       0       (0.978/chip)    5%
1:      440     9.503   10.959  354     18      0       0       9       0       0       (1.056/chip)    5%


Doesn't look like it wants to go further.

[1713538808]

1713538808

[1713538808]

1713538808

[1713538808]

1713538808

[server]

Did you put the boards in slots A1 and B1 ?

Try using another slot.

[zurg]

Did you put the boards in slots A1 and B1 ?

Try using another slot.

It's a US version.1, so I cant move it to any other slots.

[Ollie]

Starter kit with two H-boards. Both H-boards produce over 20 GH/s in bus B or C, but bus A produces only about 12 GH/s regardless of which h-board is in the A1 slot. I heard another on irc having similar situation. Is this a hardware problem on the M-board?

Yours still running at 20 GH/s in  bus B and C?

I still get some chips turning off and drop in hashrate along with it. Stopping and restarting temporarily fixes the problem. I hand tuned chip speeds and turned off autotune. Seems like a software problem. If the user can restart non-producing chips by clicking stop and restart, mining software should be able to do it automatically, or even avoid the problem alltogether.

[evilscoop]

Ive just used the pencil trick on my boards, for ref a 6b pencil allows for finer tuning of the value on the r02 resistor.
Ive gained about 5ghs/board

[darkfriend77]

Ive just used the pencil trick on my boards, for ref a 6b pencil allows for finer tuning of the value on the r02 resistor.
Ive gained about 5ghs/board

yep, some reported that they did the trick up to 5-6 times ... until they got the cards up to 28GH ^^ ... i would suggest having the chips working at 2.0 - 2.1 GH is a good number ... ^^ im unsure if going higher then ... 2.2 per chip ... is viable ... but maybee some of the experts can comment ...

what is the danger of the pencil trick ....? what if it gets under 1.1K Ohm the r02f ? ... anyone that can do some light in the dark?

Code:

1	aIfDSo	55	2.606	2.019	182	0
2	aIfDSo	55	1.790	2.029	125	0
3	aIfDSo	55	2.205	2.124	154	4
4	aIfDSo	55	1.861	1.998	130	7
5	aIfDSo	55	0.515	1.955	36	50
6	aIfDSo	55	2.176	2.019	152	1
7	aIfDSo	55	2.434	2.103	170	0
8	aIfDSo	55	1.632	1.712	114	1
9	aIfDSo	54	2.004	1.977	140	0
10	aIfDSo	55	2.047	2.082	143	1
11	aifdso	0	0.000	0.000	0	0
12	aIfDSo	55	1.961	1.924	137	8
13	aIfDSo	55	2.319	1.945	162	2
14	aIfDSo	56	1.875	2.167	131	7
15	aIfDSo	55	2.462	2.019	172	0
16	aIfDSo	55	2.147	2.135	150	1
17	aifdso	0	0.000	0.000	0	0
18	aIfDSo	55	1.861	1.860	130	0
19	aIfDSo	55	1.718	1.945	120	0
20	aIfDSo	55	1.561	1.659	109	5
21	aIfDSo	56	1.847	2.051	129	6
22	aIfDSo	55	1.632	1.839	114	0
23	aIfDSo	55	1.818	1.966	127	1
24	aIfDSo	55	1.732	1.892	121	0
25	aIfDSo	55	1.833	1.871	128	7 
26	aIfDSo	55	2.047	1.892	143	0
27	aIfDSo	55	1.904	1.860	133	2
28	aIfDSo	55	2.047	1.871	143	4
29	aIfDSo	55	2.019	1.818	141	0
30	aIfDSo	56	2.248	2.072	157	7
31	aIfDSo	55	2.233	2.008	156	0
32	aIfDSo	55	1.990	1.934	139	0

speed:1652
noncerate[GH/s]:58.526 (1.829/chip)
hashrate[GH/s]:58.746
good:4088
errors:114
spi-errors:1
miso-errors:0
jobs:295 (record[GH/s]:58.082)
0:	825	30.036	30.208	2098	82	1	0
4:	827	28.490	28.538	1990	32	0	0

[cscape]

what is the danger of the pencil trick ....? what if it gets under 1.1K Ohm the r02f ? ... anyone that can do some light in the dark?

I don't know how serious the danger is. The voltage regulator has a current and temperature limit, so it should protect itself. From what I've seen, it just turns itself off when it's not happy anymore. The card will stop mining, but a quick power cycle will fix it. Of course, if this happens when you're not watching, you could lose a lot of hashes, so I wouldn't get it too close.

Of course, increased heat will decrease lifetime of the chips, but how important is that given the increasing difficulty ? A few months at 120% rated capacity may return more than a few years at 100%.

[evilscoop]

4:      888     28.891  32.903  2018    256     0       2

r02 @ 1.199k with 6b pencil

[arorts]

4:      888     28.891  32.903  2018    256     0       2

r02 @ 1.199k with 6b pencil

Nice but it seems that the mod introduced Miso errors that could contaminate other boards (in case more are in the same m-board).

[evilscoop]

4:      888     28.891  32.903  2018    256     0       2

r02 @ 1.199k with 6b pencil

Nice but it seems that the mod introduced Miso errors that could contaminate other boards (in case more are in the same m-board).

sadly it had those before
It has one duff chip thats forced back online at 48 that give the odd miso

ill keep an eye on it, I avg about 5-10 miso errors over the 2 boards without the mod over 24hrs

[darkfriend77]

what is the danger of the pencil trick ....? what if it gets under 1.1K Ohm the r02f ? ... anyone that can do some light in the dark?

I don't know how serious the danger is. The voltage regulator has a current and temperature limit, so it should protect itself. From what I've seen, it just turns itself off when it's not happy anymore. The card will stop mining, but a quick power cycle will fix it. Of course, if this happens when you're not watching, you could lose a lot of hashes, so I wouldn't get it too close.

Of course, increased heat will decrease lifetime of the chips, but how important is that given the increasing difficulty ? A few months at 120% rated capacity may return more than a few years at 100%.

+1 thanx a lot ...

[dani]

can anyone interpret what this means?

22 148069 140517 140494

• http://127.0.0.1:8332/  (eligius acc1)

0 163196 2326 2326 [1]http://127.0.0.1:8333/          (btcguild)
22 148332 141428 141405 [2]http://127.0.0.1:8334/  (eligius acc2)

I saw my hashrate drop slightly, I am hashing on 3 workers (two different pools). I know it reads "Queue length   Getworks  Nonces found   Nonces submitted   Server". Does btcguild have so little nonces comapred to eligius because difficulty setting is much higher? (it was 64 but i only hashed with ~25gh, oops  ). It seems I have problems with spi/msi errors? Is this bad? Or can I ignore that, as it is only a tiny percentage?
What if the queue length switches between >0 and <100? Is this bad? I sometimes see the hashrate on the pool (eligius) drop drastically. This seems not to happen on btcguild, but I'm no fan of hashing on the biggest pool out there. I want to support smaller pools. Please enlighten me you guys! 

[darkfriend77]

Added info about the CGMiner ... for BitFury

- CGMiner for BitFury

<punin> compile with --enable-bitfury
<punin> con is not going to make support for our hardware because it only runs on linux, pi and needs root access
<punin> so this is as far as cgminer support will go from our side
<punin> [13.9.2013 0:17:44] Antti Lehto: --bitfury-board-type <arg> Bitfury board type, 0=i2c, 1=mboardv1, 2=mboardv2 (default: 0)
<punin> --bitfury-options <arg> Set bitfury chip options chip:speed,chip.. eg. 0:55,1:56... default: ALL:54
<punin> oops
<punin> ./cgminer --help
<punin> --bitfury-board-type <arg> Bitfury board type, 0=i2c, 1=mboardv1, 2=mboardv2 (default: 0)
<punin> --bitfury-options <arg> Set bitfury chip options chip:speed,chip.. eg. 0:55,1:56... default: ALL:54
<punin> old M-board probably doesn't work because no-one has tested it
<punin> so use --bitfury-board-type 2

[arorts]

Most of the stratum log lines I read are asking for new work and barely are there with "accepted work" . It used to list a lot of "accepted" share lines but not anymore. Why the change? Is that a problem???

Code:

NFO proxy getwork_listener._on_authorized # Worker 'XXXXX' asks for new work
2013-09-13 04:41:53,612 INFO proxy jobs.submit # Submitting 432aa92
2013-09-13 04:41:53,617 DEBUG protocol protocol.writeJsonRequest # < {"params": ["XXXXX", "1372565647 11709", "00621839", "585297df", "f198c1a7"], "id": 3838, "method": "mining.submit"}
2013-09-13 04:41:53,675 INFO proxy getwork_listener._on_authorized # Worker 'XXXXX' asks for new work
2013-09-13 04:41:53,693 DEBUG protocol protocol.lineReceived # > {u'error': None, u'result': True, u'id': 3591}
2013-09-13 04:41:53,697 WARNING proxy getwork_listener._on_submit # [75ms] Share from 'XXXXX' accepted, diff 247
2013-09-13 04:41:53,803 INFO proxy getwork_listener._on_authorized # Worker 'XXXXX' asks for new work
2013-09-13 04:41:53,930 INFO proxy getwork_listener._on_authorized # Worker 'XXXXX' asks for new work
2013-09-13 04:41:54,057 INFO proxy getwork_listener._on_authorized # Worker 'XXXXX' asks for new work
2013-09-13 04:41:54,183 INFO proxy getwork_listener._on_authorized # Worker 'XXXXX' asks for new work
2013-09-13 04:41:54,311 INFO proxy getwork_listener._on_authorized # Worker 'XXXXX' asks for new work
2013-09-13 04:41:54,437 INFO proxy getwork_listener._on_authorized # Worker 'XXXXX' asks for new work

My pool seems to be reporting around my correct hashrate. Also, I checked my .putstat.log and it shows this:

Code:

pi@bitfury ~ $ cat /run/shm/.putstat.log
0 65693 3169 3169 [0]http://127.0.0.1:8332/
0 0 0 0 [1]http://127.0.0.1:8333/
0 0 0 0 [2]http://127.0.0.1:8334/

Do you see any problems??  Please help  

[evilscoop]

cgminer builds ok
most of the display options are broken though and hang the miner

Code:

BITFURY 0: 48.98G/49.77Gh/s | A:1408 R:0 HW:0 WU:697.5/m


[2013-09-13 10:41:37] Accepted 07c8aaf3 Diff 32/32 BITFURY 0
 [2013-09-13 10:41:41] Accepted 05d8fca3 Diff 43/32 BITFURY 0
 [2013-09-13 10:41:47] Accepted 001f09a1 Diff 2.11K/32 BITFURY 0
 [2013-09-13 10:41:49] Accepted 0004a45a Diff 14.1K/32 BITFURY 0
 [2013-09-13 10:41:51] Accepted 025c7689 Diff 108/32 BITFURY 0
 [2013-09-13 10:41:52] Accepted 06cd424b Diff 37/32 BITFURY 0
 [2013-09-13 10:41:54] Accepted 07ae8f6b Diff 33/32 BITFURY 0
 [2013-09-13 10:41:54] Accepted 043e8079 Diff 60/32 BITFURY 0

tbh its nice, but think ill wait for bfgminer with auto adjusting freq, Im not keen on cgminer myself.

[GH]

Just to let you know what is possible:

speed:1760 noncerate[GH/s]:63.651 (1.989/chip) hashrate[GH/s]:67.191 good:4446 errors:207 spi-errors:1 miso-errors:0 jobs:375 (record[GH/s]:65.097)
4:   880   32.985   33.643   2304   42   0   0
8:   880   30.666   33.548   2142   165   1   0
                   
This is NOT the best result, just a momentary (average) snapshot. Overvolting and manual tuning (resulting speeds all 55 here) will do wonders with this great (but sometimes strange, especially when cold) hardware!

I had even higher rates with a faulty chip which recovered for 24 hours and didn't throw errors, what it now does again after a restart...?

Good luck and thanks for the input and efforts of everybody here!

 

[juhakall]

I had even higher rates with a faulty chip which recovered for 24 hours and didn't throw errors, what it now does again after a restart...?

I have a similar chip. It takes around 24 hours until it stops producing errors after a poweroff & restart.

[arorts]

cgminer builds ok
most of the display options are broken though and hang the miner

Code:

BITFURY 0: 48.98G/49.77Gh/s | A:1408 R:0 HW:0 WU:697.5/m
 
[2013-09-13 10:41:37] Accepted 07c8aaf3 Diff 32/32 BITFURY 0
 [2013-09-13 10:41:41] Accepted 05d8fca3 Diff 43/32 BITFURY 0
 [2013-09-13 10:41:47] Accepted 001f09a1 Diff 2.11K/32 BITFURY 0
 [2013-09-13 10:41:49] Accepted 0004a45a Diff 14.1K/32 BITFURY 0
 [2013-09-13 10:41:51] Accepted 025c7689 Diff 108/32 BITFURY 0
 [2013-09-13 10:41:52] Accepted 06cd424b Diff 37/32 BITFURY 0
 [2013-09-13 10:41:54] Accepted 07ae8f6b Diff 33/32 BITFURY 0
 [2013-09-13 10:41:54] Accepted 043e8079 Diff 60/32 BITFURY 0

tbh its nice, but think ill wait for bfgminer with auto adjusting freq, Im not keen on cgminer myself.

I'm dying to know when Bitfury will be more open and finally let others do what they do best: mining software without imposing them support restrictions and conditions. Not sure if there's any politics involved or what's the contingency for not doing so.

Cgminer or Bfgminer please come to Bitfury...or viceversa!!  :p
 

[cscape]

I'm dying to know when Bitfury will be more open and finally let others do what they do best: mining software without imposing them support restrictions and conditions. Not sure if there's any politics involved or what's the contingency for not doing so.

What's not open about bitfury ? All the information needed to port other mining software to the Raspberry PI is available.

[arorts]

I'm dying to know when Bitfury will be more open and finally let others do what they do best: mining software without imposing them support restrictions and conditions. Not sure if there's any politics involved or what's the contingency for not doing so.

What's not open about bitfury ? All the information needed to port other mining software to the Raspberry PI is available.

Well, there's perhaps a confusion here but I'm almost sure I read cgminer's developing team sort of complaining about some lack of collaboration or difficulty to let cgminer's mining software to be available for bitfury and that they were asked to pay for support or the like.
I just really look forward to seeing more available and tested mining software just like with most other mining hardware rather than sort of proprietary software. Feel free to correct me but for some reason that doesn't seem to be the case with Bitfury.