[GUIDE] BitFury Miner Support/Tuning

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

[Cablez]

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.

I have a v1 M-board and I am constantly having SD corruption issues on reboot or shutdown. No fan headers here.  I just keep 3 images ready to go so I have little downtime due to software when I am messing around with the hardware.

[klondike_bar]

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.

I have a v1 M-board and I am constantly having SD corruption issues on reboot or shutdown. No fan headers here.  I just keep 3 images ready to go so I have little downtime due to software when I am messing around with the hardware.

hmm

also, ive been having 'semaphore timeout' errors when trying to write images with my sd card reader (internal) so i cant even reformat the bad card right now

[jddebug]

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.

I have a v1 M-board and I am constantly having SD corruption issues on reboot or shutdown. No fan headers here.  I just keep 3 images ready to go so I have little downtime due to software when I am messing around with the hardware.

hmm

also, ive been having 'semaphore timeout' errors when trying to write images with my sd card reader (internal) so i cant even reformat the bad card right now

On mine, when the card fails it is ruined. I had to start with a new one both times.

[Cablez]

That is odd.  I use the SD card formatter 4.0 for mine. It takes two passes to get the whole 4G card with overwrite but I can then re-image it just fine.

[spegelius]

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

I'll do some testing later. However, there was some problems with the cgminer. First, i'm running a multimining setup, which means i poll for most profitable coin from coinchoose or coinwarz and then switch miners to mine that coin. Not sure if this gives any advantage nowadays, but been tweaking it for some time. With stratum proxy this works fine, as chainminer is running uninterrupted, only the proxy is restarted. Or course there's some rejected shares when switching coins, but from chainminer's side it's mostly business as usual.

Now enter cgminer; restarting it means first shutting down the chips and then finding them again and reinitializing. This seems to crap out at some point and chips aren't found anymore. It got to a point where there was only one chip found for first board. So i shut down cgminer and fired up chainminer/stratum-proxy with previous best.cnf. Not going well, first and second boards were way below normal speeds, some chips showed only error results and speed was 0.0GH/s. Only after deleting best.cnf and /run/shm/.chip.cnf, i.e. allowing chainminer to autotune speeds, i got all boards running fine. Phew, thought i had blown something for a minute...

Anyways, some ideas what might have happened:
* constant reinitialization crapped spi or chips or something...
* this resulted some chips left in a bad state; telling them to run at the 55 speed wasn't resetting them properly
* only after setting all chips to 54 (apparently chainminer does this in autotune mode) the chips were revived and now back to hashing at previous speeds
* or could it simply be that running constantly with too high speed finally craps the chips for some reason?

So with cgminer something like first setting the speed to 54 (or maybe 50?) and only after that tuning them to full speed might keep them working properly?

[KNK]

I don't think the chips are damaged if running at high speed ( but it also depends on the temp of course )
How do you stop cgminer?
If it is not clean shutdown - some chips may be left hashing (obviously old jobs) which may be the reason for them to remain undetected on the next start.

I don't see any reason to restart cgminer - you can enable or disable a pool from the API, so all you need to do is to feed the full list of pools/currencies on startup and disable the ones you don't want to use

[spegelius]

I have heatsinks at the backs of the hcards and 3 12cm fans blowing, they shouldn't be too hot.

I use API to shut cgminer down, but i've seen cgminer hang randomly so it is possbile that the last stage kill -9 might shut it down wrong way...

Good all with API, i'll have to implement that later this week or weekend. For now i'll stick with stratum proxy and pools that work well with it (namely pools that allow manual difficulty setting for miners).