[GUIDE] BitFury Miner Support/Tuning

[Swimmer63]

I've heatsinked the new unmodded h-cards i have, directed fans (3x 120 mm) at them but they still get so hot they seem on the verge of burning up.
What else can i try?
For the time being, how should i set the trimpot on these cards to get ~25gh/s? (currently at 33+ gh/s)

Thank you.

Did you heatsink the chip or the back.  I put it on the back.  The heatsinks are warm, but not hot.  I gained about 5% for the cards I did.  I think I'll do the rest, though I expected a better result.

[mwk13]

@swimmer63

I applied the heatsinks to the back of the cards. It's the cards themselves that are getting extremely hot.
Are there instructions anywhere that show how to adjust the voltage using the trimpots?

[Swimmer63]

@swimmer63

I applied the heatsinks to the back of the cards. It's the cards themselves that are getting extremely hot.
Are there instructions anywhere that show how to adjust the voltage using the trimpots?

I'm sure there are but I have the old version of boards with not trim pots.

[tom99]

anyone solo with bitfury admin and I was trying it but not working or maybe I was missing something ?

[klondike_bar]

@swimmer63

I applied the heatsinks to the back of the cards. It's the cards themselves that are getting extremely hot.
Are there instructions anywhere that show how to adjust the voltage using the trimpots?

I'm sure there are but I have the old version of boards with not trim pots.

just turn the trimpot with a screwdriver. 1/8th turn clockwise should increase voltage, counterclockwise reduces. do yourself a favor and use a 10$ multimeter as you go to check the resistance and, when powering up, the voltage

[Beans]

My 4th slot never comes on and after about a hour 2 or 3 other slots start turning off at on. Does it hurt anything to skip the 4th slot?

[Trongersoll]

have we figured out how to turn these off without trashing the memory card?

[GandalfG]

have we figured out how to turn these off without trashing the memory card?

Login to Pi than  sudo poweroff

[goxed]

have we figured out how to turn these off without trashing the memory card?

Login to Pi than  sudo poweroff

I also make sure to Stop the miner process before poweroff.

[spegelius]

Has anyone done any tweaking to BFGMiner or those cgminer forks regarding bitfury? I've tried both Anajavis's fork of cgminer, which gives about 10-20% lower speed vs. chainminer and KNK's fork, which doesn't work for me (randomly finds maybe 1 or 2 chips or segfaults).

With chainminer/stratum proxy i get ~160GH/s (5 hcards, hand tweaked best.cnf)

I also tried latest BFGMiner from github, which initially gives same speed as Anajavi's cgminer, but after tweaking some parameters i can get to about 5-1% distance from chainminer's speeds (at least if the pool speed indication is to be trusted). BFGMiner states 166/150/138 with latest tweaks.

The tweaks i made are:
- limit the maximum chip speed to 56 as only few of my chips can handle even that speed
- changed the starting speed from 50 to 54 and now tried 47 (to help the few weak chips limp along...). 54 seemed to produce best results

I had a look at the BFGMiner's bitfury code and at a quick glance it feels that the autotuning is making the speed go up and down too much maybe? Same is with chainminer, i suppose... is there a way to feed your own static chip speeds, as in best.cnf to BFGMiner?

[KNK]

KNK's fork, which doesn't work for me (randomly finds maybe 1 or 2 chips or segfaults).
...
is there a way to feed your own static chip speeds, as in best.cnf to BFGMiner?

can you run my fork with

Code:

ulimit -c unlimited

and send me the coredump genereated on segfault. What defs are you using with it?
hint: I am using active low OE with my hardware which is the most likely reason for not detecting the chips.

I don't have BFSB hardware to test with, but with your help, we can make it work.
In my fork there is an option (actually it was made from legkodymov - I just fixed it) to set the chip speed via API call and because there is no auto-tuning, it's equal to the fixed speeds from best.cnf

[spegelius]

Hmm, no segfaults anymore, but still not all chips there. Also it seems that i need to start and stop chainminer before running cgminer to get it finding even those few chips. And those few chips produce only invalid nonces it seems.

Pastebin of the output: http://pastebin.com/Cp7jSjeJ

The code i built is from github and i haven't modified it. BITFURY_MUX_OE is not defined. No parameters in commandline, except url and --no-submit-stale

edit: oh and running BFGMner for and hour or so resulted total speeds 170/160/149 or so. The last number was quite well in line with ghash.io's speed.

With anjavi's cgminer it is possible to set speeds per chip. But even with the same clockbits as in best.cnf, the speed is something like 20 - 30 ghs lower than chainminer.

[KNK]

There are few things you need to change for BFSB hardware:
in bitfury-config.h

Code:

#define BITFURY_MAXBANKS 8
#define BITFURY_BANKCHIPS 14

should be

Code:

#define BITFURY_MAXBANKS 4
#define BITFURY_BANKCHIPS 64

as there are 4 banks of 4 boards, each with 16 chips

Then in tm_i2c.c you need to comment out (ore remove) the line

Code:

#define BF_OE_ACTIVE_LOW

and to change the bank definitions (bf_bank_gpio) to the ones for BFSB i.e.

Code:

static const int bf_bank_gpio[BITFURY_MAXBANKS] = {18,23,24,25};

[spegelius]

There are few things you need to change for BFSB hardware:
in bitfury-config.h

Code:

#define BITFURY_MAXBANKS 8
#define BITFURY_BANKCHIPS 14

should be

Code:

#define BITFURY_MAXBANKS 4
#define BITFURY_BANKCHIPS 64

as there are 4 banks of 4 boards, each with 16 chips

Then in tm_i2c.c you need to comment out (ore remove) the line

Code:

#define BF_OE_ACTIVE_LOW

and to change the bank definitions (bf_bank_gpio) to the ones for BFSB i.e.

Code:

static const int bf_bank_gpio[BITFURY_MAXBANKS] = {18,23,24,25};

Allright, now it's working, thanks. Speed average 151 GH/s with the default chip speed of 42 i assume? How does this setting correlate to setting 54 in best.cnf for example? 54, scrolled down on the code 

Also i got the segfault by trying to set --bitfury-clockbits 0:55,1:55,2:55... etc. Seems the arg parsing fails? I do have ulimit set to unlimited, but all i get is this:

Code:

 [2013-12-29 20:16:06] BITFURY slot: 3, chip #69 detected                    
 [2013-12-29 20:16:06] BITFURY slot: 3, chip #70 detected                    
 [2013-12-29 20:16:06] BITFURY slot: 3, chip #71 detected                    
 [2013-12-29 20:16:06] BITFURY slot: 3, chip #72 detected                    
 [2013-12-29 20:16:06] BITFURY slot: 3, chip #73 detected                    
 [2013-12-29 20:16:06] BITFURY slot: 3, chip #74 detected                    
 [2013-12-29 20:16:06] BITFURY slot: 3, chip #75 detected                    
 [2013-12-29 20:16:06] BITFURY slot: 3, chip #76 detected                    
 [2013-12-29 20:16:06] BITFURY slot: 3, chip #77 detected                    
 [2013-12-29 20:16:06] BITFURY slot: 3, chip #78 detected                    
 [2013-12-29 20:16:06] BITFURY slot: 3, chip #79 detected                    
 [2013-12-29 20:16:06] BITFURY: 80 chips detected!                    
 [2013-12-29 20:16:06] Probing for an alive pool                    
 [2013-12-29 20:16:07] Pool 0 difficulty changed to 512                    
 [2013-12-29 20:16:08] Pool 0 difficulty changed to 64                    
/home/pi/bin/_cgminer: line 30: 18301 Segmentation fault      ${CGMINERBIN} $PARAMS $1 $2 $3 $4 $5 $6 $7 $8 $9

I'm running cgminer through shell scripts, should i run it directly to get the coredump?

[KNK]

I am using the API to set clockbits as it can be done at any time, so i have fixed just that (not the command line options)
Run cgminer with --api-listen and use:

Code:

php api-example.php 'setclkb|0,13,55|'

where the first number is the slot and the second is the chip

[spegelius]

Ah ok, i'll check the api. Btw, running at about 158.4GH/s average, using --bitfury-clockbits 55. This is right around the ballpark with chainminer and definite improvement to stratum-proxy/chainminer combo due to problems with some pools and difficulty. Great

Looking at the --bitfury-clockbits code, the slot (or bank) is needed also, as in api call, so the arg format should be like bank:chip:speed.

[KNK]

Looking at the --bitfury-clockbits code, the slot (or bank) is needed also, as in api call, so the arg format should be like bank:chip:speed.

Looking at it too. Got the core dump at line 388 ... probably just uninitialised variable ... will see

EDIT: Fix committed - command line option working too

EDIT2: Now you can define the number of boards too so in bitfury-config.h for BFSB boards use:

Code:

#define BITFURY_BOARDCHIPS 16
#define BITFURY_BANKBOARDS 4
#define BITFURY_MAXBANKS 4

[spegelius]

Great, thanks. Going to leave this running for the night and see how it goes.

Also sent a small tip for your troubles.

Edit: now that i set the chip speeds as per best.cnf, i only get to 151GH/s. Oh well, just gonna run with 55 on all chips for now.

[KNK]

Thanks for the tip
If you get to much hw errors on some chips - you may need to fine tune the scan delay multiplier in driver-bitfury.c (line 210 - between 900 and 1200) and the shift value in libbitfury.c (line 631 - between 0x100000 and 0x200000) ... I think I got them right, but they may be for my specific hardware configuration

EDIT:  for per chip info check:

Code:

php api-example.php stats | grep -v 'stats returned' | egrep -e chip -e work -e hw -e gh -e mhz -e clock

if for some of the chips it shows different MHz on each run you will need to tweak those values above

[klondike_bar]

have we figured out how to turn these off without trashing the memory card?

Login to Pi than  sudo poweroff

I also make sure to Stop the miner process before poweroff.

I am getting fed up of the SD card issues. anytime the miner needs to be powered off the card seems to be wiped.

I *think* that there is a relation between the SD issues and using the fan slots on the board - it might be possible that having 2x230mm fans spin down when power is removed is causing a small amount of power to be backfed onto the RPi until the fans slow to a stop.

when i did not have fans, i could turn off the PSU without any effects on the SD card.