[GUIDE] BitFury Miner Support/Tuning

[solarion]

Is there anyway to use a different stratum proxy with chain miner? Resetting it every 10 or 60 min still leads to issues after several days. Anyway to put slush's proxy in it, or is that what it is using?

I tried bfgminer as the proxy and though the shares make it to bfgminer, they're all discarded as hw errors. Not sure where the problem lies as I've encoded credentials into jobconnect. Perhaps I'll throw the question at Luke-jr at some point.

Update:
Nevermind THAT ^^^ CGMiner works a treat now on bitfury rigs. Bye Bye chainminer and the lamo proxy. Thanks ckolivas for the awesome miner! Finally got some cgremote action on bitfury rigs. Huge thanks to Kano, who apparently did the bulk of the work to the bab driver.

https://bitcointalk.org/index.php?topic=28402.msg4726840#msg4726840

[1714221261]

1714221261

[1714221261]

1714221261

[1714221261]

1714221261

[1714221261]

1714221261

[ndonnard]

The goal of this thread has been reached with success! A lot of info!

[adib]

Is there anyway to use a different stratum proxy with chain miner? Resetting it every 10 or 60 min still leads to issues after several days. Anyway to put slush's proxy in it, or is that what it is using?

I tried bfgminer as the proxy and though the shares make it to bfgminer, they're all discarded as hw errors. Not sure where the problem lies as I've encoded credentials into jobconnect. Perhaps I'll throw the question at Luke-jr at some point.

Update:
Nevermind THAT ^^^ CGMiner works a treat now on bitfury rigs. Bye Bye chainminer and the lamo proxy. Thanks ckolivas for the awesome miner! Finally got some cgremote action on bitfury rigs.

How did you get Cgminer to work with bitfury h-cards?
I only managed with bfgminer, cgminer only wants usb stuff

[solarion]

Is there anyway to use a different stratum proxy with chain miner? Resetting it every 10 or 60 min still leads to issues after several days. Anyway to put slush's proxy in it, or is that what it is using?

I tried bfgminer as the proxy and though the shares make it to bfgminer, they're all discarded as hw errors. Not sure where the problem lies as I've encoded credentials into jobconnect. Perhaps I'll throw the question at Luke-jr at some point.

Update:
Nevermind THAT ^^^ CGMiner works a treat now on bitfury rigs. Bye Bye chainminer and the lamo proxy. Thanks ckolivas for the awesome miner! Finally got some cgremote action on bitfury rigs.

How did you get Cgminer to work with bitfury h-cards?
I only managed with bfgminer, cgminer only wants usb stuff

I compiled cgminer with --enable-bab (black arrow bitfury). It autodetected all of my v2.2 cards properly. I can't speak to how this works with v1 cards, though I know it tries to detect those first.

I've gotten cgminer to match chainminer top end performance with similar settings, which is a huge win given cgminer's wealth of features. The real advantage to running cgminer on bitfury rigs wasn't immediately obvious however. I let a rig with 14 h cards run overnight with stock cgminer parameters and it tuned out so many hardware errors that efficiency improved by over 11%(.8622 vs .7747). Aside from potential uses to diagnose problems I've no further use for chainminer.    

[spegelius]

Yeah cgminer does work with these cards, ive been testing it now and then, but have always returned to chainminer. The reason is that even though the speed looks very good after a while it tunes itself to max speed (385GH/s vs. 420GH/s max speeds, chainminer vs cgminer), after a day or so it goes below chainminer speeds. I guess restarting cgminer daily would fix that, haven't really bothered as chainminer just rolls on on autotune. And cgminer does have some options to tune bitfury cards manually, but currently i just want my rigs to run without constant tuning .

[solarion]

Put a meter on that rig. You'll find that power consumption is dropping off a cliff. Cgminer is tuning out hw errors and chainminner is happily gobbling up power without regard to hw errors. The difference in efficiency is not small.

You can make cgminer behave the same way by just changing the tune up/down values. That's an optional value you can pass directly to cgminer without changing the code.

[daddyfatsax]

Put a meter on that rig. You'll find that power consumption is dropping off a cliff. Cgminer is tuning out hw errors and chainminner is happily gobbling up power without regard to hw errors. The difference in efficiency is not small.

You can make cgminer behave the same way by just changing the tune up/down values. That's an optional value you can pass directly to cgminer without changing the code.

What options are you starting cgminer with?

[spegelius]

Put a meter on that rig. You'll find that power consumption is dropping off a cliff. Cgminer is tuning out hw errors and chainminner is happily gobbling up power without regard to hw errors. The difference in efficiency is not small.

You can make cgminer behave the same way by just changing the tune up/down values. That's an optional value you can pass directly to cgminer without changing the code.

Hmm, seriously? I'll have to test the power draw. With chainminer it sucks about ~300W on the wall @380GH/s, i haven't tried it with cgminer.

Tuning... somehow that doesn't sound as fun it sounded few months ago . Oh well, it'll be propably worth it.

[solarion]

Put a meter on that rig. You'll find that power consumption is dropping off a cliff. Cgminer is tuning out hw errors and chainminner is happily gobbling up power without regard to hw errors. The difference in efficiency is not small.

You can make cgminer behave the same way by just changing the tune up/down values. That's an optional value you can pass directly to cgminer without changing the code.

What options are you starting cgminer with?

I've been altering these lines in driver-bab.c

#define BAB_MAXSPEED 57
#define BAB_DEFMAXSPEED 55
#define BAB_DEFSPEED 53
#define BAB_MINSPEED 52
#define BAB_ABSMINSPEED 32

#define BAB_TUNEUP 1.0
#define BAB_TUNEDOWN 10.0

https://github.com/ckolivas/cgminer/blob/master/driver-bab.c

These are also the values that can be passed to cgminer on startup. The format was posted by kano in the cgminer thread...somewhere around pg 700 I believe.

Actually 710:

https://bitcointalk.org/index.php?topic=28402.msg4726840#msg4726840

From asic-readme:

--bab-options <arg> Set BaB options max:def:min:up:down:hz:delay:trf

https://github.com/ckolivas/cgminer/blob/master/ASIC-README

[Gyrsur]

6 of my 16 bitfury v1.2 H-CARD died over the time. October 2013 batch. no overclocking and no overheating! did someone face the same experience??

EDIT: seems to me quality of the bitfury v1.2 H-CARD (October 2013 batch) is not good enough to work with it 24/7 for a half year. some component on the card died. cards did not work again if I changed the slot on the bitfury v2.3 M-CARD.

[eestimees]

I need some help.. I have M-board 2.3 and 16x H-card v1.2

today I had to shutdown (sudo halt) miner to move it. After blowing away some dust and starting it again, is started hashing fine.. approx 15min later it stopped.. webserver responds

Code:

The requested URL / was not found on this server.

and no ssh connectivity at all.. next time I stayed in with my ssh connection. now I cant do a thing in shell all commands are dissapeared.. Do I have faulty SD-card that has unmounted itself?

Code:

pi@bitfury ~ $ pwd
/home/pi
pi@bitfury ~ $ ls
-bash: ls: command not found
pi@bitfury ~ $ ps 
-bash: ps: command not found
pi@bitfury ~ $ df -h
-bash: /bin/df: No such file or directory
pi@bitfury ~ $ 

[bobcaticus]

I need some help.. I have M-board 2.3 and 16x H-card v1.2

today I had to shutdown (sudo halt) miner to move it. After blowing away some dust and starting it again, is started hashing fine.. approx 15min later it stopped.. webserver responds

Code:

The requested URL / was not found on this server.

and no ssh connectivity at all.. next time I stayed in with my ssh connection. now I cant do a thing in shell all commands are dissapeared.. Do I have faulty SD-card that has unmounted itself?

Code:

pi@bitfury ~ $ pwd
/home/pi
pi@bitfury ~ $ ls
-bash: ls: command not found
pi@bitfury ~ $ ps 
-bash: ps: command not found
pi@bitfury ~ $ df -h
-bash: /bin/df: No such file or directory
pi@bitfury ~ $ 

I'd recommend a new image and SD card

[eestimees]

I'd recommend a new image and SD card

got a link to image? OP links does not work...

EDIT: found it, prev page

[arorts]

As you might know, openssl libraries based on 1.01 and 1.02 beta releases are apparently infected with the heartbleed bug. This is the bug that allows snooping and steeling of information over SSL connections.

Does anyone know whether it's safe to upgrade/recompile the openssl libraries that came with the Raspberry PI distributed by Bitfury???
What's the simplest/safest method to do so??

I just typed openssl version -v and it definitely shows version 1.0.1e, which seems to carry the bug as explained here!!!:

Check out http://heartbleed.com

This is a CRITICAL topic!!! Please advise!!!

[KNK]

I think it is based on raspbian, so all you need to do is update the package once available

see http://storyhub.actionaid.org/forums/viewtopic.php?t=74133&p=531967

[bobcaticus]

As you might know, openssl libraries based on 1.01 and 1.02 beta releases are apparently infected with the heartbleed bug. This is the bug that allows snooping and steeling of information over SSL connections.

Does anyone know whether it's safe to upgrade/recompile the openssl libraries that came with the Raspberry PI distributed by Bitfury???
What's the simplest/safest method to do so??

I just typed openssl version -v and it definitely shows version 1.0.1e, which seems to carry the bug as explained here!!!:

Check out http://heartbleed.com

This is a CRITICAL topic!!! Please advise!!!

I've passed this info along to our devs and will get a response shortly.

-Jason

[arorts]

As you might know, openssl libraries based on 1.01 and 1.02 beta releases are apparently infected with the heartbleed bug. This is the bug that allows snooping and steeling of information over SSL connections.

Does anyone know whether it's safe to upgrade/recompile the openssl libraries that came with the Raspberry PI distributed by Bitfury???
What's the simplest/safest method to do so??

I just typed openssl version -v and it definitely shows version 1.0.1e, which seems to carry the bug as explained here!!!:

Check out http://heartbleed.com

This is a CRITICAL topic!!! Please advise!!!

I've passed this info along to our devs and will get a response shortly.

-Jason

Well I did update my overall Raspbian using this command line, which apparently does include any OpenSSL updates as well:

Code:

sudo apt-get update && sudo apt-get dist-upgrade

However, now when I run cat /run/shm/.stat.log it's now showing even the slots where there are no H-Cards with tons of errors from B-F.

speed:13325 noncerate[GH/s]:328.450 (1.283/chip) hashrate[GH/s]:441.082 good:22942 errors:26313 spi-err:1757 miso-err:1191 jobs:283 cores:11% good:246 bad:2 off:8 (best[GH/s]:0.000) Tue Apr  8 18:28:18 2014
0:   871   32.484   35.038   2269   82   0   1   16   0   0   (2.030/chip)   17%
1:   758   30.050   33.125   2099   102   0   0   15   1   0   (1.878/chip)   16%
2:   817   33.959   35.123   2372   49   1   0   15   1   0   (2.122/chip)   18%
3:   869   34.260   34.880   2393   49   1   0   16   0   0   (2.141/chip)   18%
4:   809   31.496   31.191   2200   34   0   0   16   0   0   (1.969/chip)   17%
5:   704   28.318   28.580   1978   28   0   2   13   0   3   (1.770/chip)   15%
6:   822   25.240   27.534   1763   69   0   1   15   0   1   (1.578/chip)   13%
7:   872   34.245   34.700   2392   34   0   0   16   0   0   (2.140/chip)   18%
8:   768   26.028   27.101   1818   43   0   2   14   0   2   (1.627/chip)   14%
9:   767   24.925   25.642   1741   31   0   2   14   0   2   (1.558/chip)   13%
A:   868   27.445   31.032   1917   654   35   30   16   0   0   (1.715/chip)   15%
B:   880   0.000   19.385   0   5037   345   225   16   0   0   (0.000/chip)   0%
C:   880   0.000   19.448   0   5025   343   236   16   0   0   (0.000/chip)   0%
D:   880   0.000   19.501   0   5026   351   224   16   0   0   (0.000/chip)   0%
E:   880   0.000   19.268   0   5030   331   239   16   0   0   (0.000/chip)   0%
F:   880   0.000   19.533   0   5020   350   229   16   0   0   (0.000/chip)   0%


Previously, this file simply ended at A and didn't gave me all those errors.

Any thoughts?  

UPDATE: It seems the problem went away by itself so no more nasty extra lines in that file. :-)

[Stanford]

The goal of this thread has been reached with success! A lot of info!

Totally agree with you! I have already found here  answers to the problems I have faced with!

[arorts]

Anyone has seen the repeating message "New proxy version available  Please update!" when checking their proxy process in the miner?

Any process to back it up and update it to a new version?

[bobcaticus]

As you might know, openssl libraries based on 1.01 and 1.02 beta releases are apparently infected with the heartbleed bug. This is the bug that allows snooping and steeling of information over SSL connections.

Does anyone know whether it's safe to upgrade/recompile the openssl libraries that came with the Raspberry PI distributed by Bitfury???
What's the simplest/safest method to do so??

I just typed openssl version -v and it definitely shows version 1.0.1e, which seems to carry the bug as explained here!!!:

Check out http://heartbleed.com

This is a CRITICAL topic!!! Please advise!!!

I've passed this info along to our devs and will get a response shortly.

-Jason

Well I did update my overall Raspbian using this command line, which apparently does include any OpenSSL updates as well:

Code:

sudo apt-get update && sudo apt-get dist-upgrade

Thanks - either that or this will do the trick:

Code:

sudo apt-get update
sudo apt-get install openssl libssl-dev

This information was added to the blog as well: https://www.megabigpower.com/blog/?p=60

Arorts - I will look into that.