[ANN] US/North American Bitfury sales NEW STOCK ***NOW SHIPPING***

[Keefe]

I have been using bfgminer  since i received my bitfury instead of chainminer and find its a lot more stable and seems to work fine with all the pools i have tried as it does  stratum itself there is no need for the proxies.

 

This seems reasonable to me as I am a long term cgminer user.

Any tips on how to set it up?

Sorry been tied up have you got it working ?

according to bfgminer readme, it says there is no thermal shutdown regulation.  do you have heatsinks installed?

I don't think chainminer is any different. AFAIK, the boards have no temp sensors anywhere.

[1714613645]

1714613645

[1714613645]

1714613645

[1714613645]

1714613645

[tacotime]

My first BTC was paid out from my Bitfury device today

*tear*

48 hours running stable at 360 GH/s since I dropped the voltage on those two cards.

[salfter]

Tried to compile bfgminer and ran into a wall here:
"Could not find HASH_ITER - please install uthash-dev"

This was near the end when running:
./configure --enable-bfsb

Must've forgotten to include that in the dependencies...my post with the instructions has been updated.

Went ahead and tried cgminer and got it to compile, but it could not detect the bitfury (I am on a V1 M-board).

cgminer doesn't support these boards.

That said, now that I'm near my mining rig for testing, I'm trying to get bfgminer running stable on it.  It runs for a few minutes, getting ~80 GH/s out of my two boards (and another 11 from the BFL hardware also plugged in), but then it starts throwing a bunch of errors in a loop.  I think it's trying to drive the chips too hard by default.  If I change the oscillator setting for each chip from whatever default bfgminer is picking to 52, the hashrate falls back to ~68 GH/s (close to what chainminer was delivering).  So far it's still running as I write this. 

Looking at the bfgminer source code, we find this in driver-bfsb.c, in bfsb_init():

Code:

                bitfury_init_chip(proc);
                bitfury->osc6_bits = 53;
                bitfury_send_reinit(bitfury->spi, bitfury->slot, bitfury->fasync, bitfury->osc6_bits);
                bitfury_init_freq_stat(&bitfury->chip_stat, 52, 56);

I think it's starting with 53 and then setting itself to adjust later between 52 and 56.  Without heatsinks, though, my rig isn't stable at 53 long enough for this mechanism to kick in, so I'm better off fixing it to run at 52:

Code:

                bitfury_init_chip(proc);
                bitfury->osc6_bits = 52;
                bitfury_send_reinit(bitfury->spi, bitfury->slot, bitfury->fasync, bitfury->osc6_bits);
                bitfury_init_freq_stat(&bitfury->chip_stat, 52, 52);

AFAICT there is no way to set this in bfgminer.conf.  You can edit chip speeds at runtime, but the only way to make this setting permanent for now is to edit and recompile the source.

Here's a screenshot of bfgminer in action...currently at 10 minutes, and the ASICs are running in the mid-40s according to the temperature probe I have on one of them:

[ericdc30]

Thanks MBP. I still can't believe my eyes 579 GH/s!!!

https://i.imgur.com/RxT6gBx.jpg
https://i.imgur.com/4zEpLTJ.jpg


ericdc_6 is my full rig
https://i.imgur.com/dit1EH7.png

[Doff]

Is Luke actively working on getting Bfgminer to work completely with the Rigs? I realize hes done something since its working I just wonder if you have heard he is trying to get it stable.

[cypherdoc]

.05 BTC to the guy who helps me reimage 2 corrupt SD cards back to latest Chainminer.

pm me.

i actually have another SD card with a good image on it so it should just be a matter of copying it over.

[Cablez]

Just use w32diskimager found here: http://sourceforge.net/projects/win32diskimager/

On linux I think you can just use dd.

[tom99]

.05 BTC to the guy who helps me reimage 2 corrupt SD cards back to latest Chainminer.

pm me.

i actually have another SD card with a good image on it so it should just be a matter of copying it over.

   You better off not use sd for FS but you can usb flash for FS and use work better.

[Cablez]

Can a Pi be run off of a usb device instead of the SD card?  The SD cards just seem so easily corruptible compared to usb distros I have used.

[cypherdoc]

turns out the sd cards weren't corrupted.

i was getting overlapping ip addresses.  i have my router set on dhcp but i've noticed that altho each raspi is supposed to let itself be assigned a new address each time on connection w/o any overlap from other BF's, some time it does and some times it doesn't.

i used one of my spare raspi's lying around to figure out that the cards weren't corrupted and determine that the ip's were in fact overlapping.

it's definitely an annoying problem given all the resets/reboots i'm having to do given the prevalence of sub par H board hashing.

[salfter]

I find that bfg does not load the spi drivers properly itself and just click start then stop miner in the web interface before starting bfg

Something like this will load the necessary kernel modules so that bfgminer will work:

Code:

sudo modprobe i2c_bcm2708
sudo modprobe spi_bcm2708

[salfter]

i was getting overlapping ip addresses.  i have my router set on dhcp but i've noticed that altho each raspi is supposed to let itself be assigned a new address each time on connection w/o any overlap from other BF's, some time it does and some times it doesn't.

I have no idea what the motivation was behind using DHCP to find the subnet and then just ignore the result and try grabbing .249 on it.  Why not just let DHCP do its job?  Any halfway-decent router's web interface will show you what devices are where; finding your rig's IP address is trivial.

As shipped, /etc/network/interfaces looks something like this after it's booted up once and found an address:

Code:

auto lo

iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.100.249
netmask 255.255.255.0
gateway 192.168.100.1

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

up route add default gw 192.168.100.1 eth0
dns-nameservers 192.168.100.1 8.8.8.8

Something like this will just get out of the way and let DHCP do its job.  If you want the rig at a certain IP address, create a DHCP reservation for it.  More importantly, this will let DNS do its job so you can refer to the rig by its hostname (which you probably want to set to something sensible with raspi-config, BTW).

Code:

auto lo

iface lo inet loopback
auto eth0
iface eth0 inet dhcp

allow-hotplug wlan0
auto wlan0
#iface wlan0 inet manual
#wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

This is for a wired network.  For WiFi, follow one of the many guides out there on getting WiFi working on a Raspberry Pi.

[tom99]

i was getting overlapping ip addresses.  i have my router set on dhcp but i've noticed that altho each raspi is supposed to let itself be assigned a new address each time on connection w/o any overlap from other BF's, some time it does and some times it doesn't.

I have no idea what the motivation was behind using DHCP to find the subnet and then just ignore the result and try grabbing .249 on it.  Why not just let DHCP do its job?  Any halfway-decent router's web interface will show you what devices are where; finding your rig's IP address is trivial.

As shipped, /etc/network/interfaces looks something like this after it's booted up once and found an address:

Code:

auto lo

iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.100.249
netmask 255.255.255.0
gateway 192.168.100.1

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

up route add default gw 192.168.100.1 eth0
dns-nameservers 192.168.100.1 8.8.8.8

Something like this will just get out of the way and let DHCP do its job.  If you want the rig at a certain IP address, create a DHCP reservation for it.  More importantly, this will let DNS do its job so you can refer to the rig by its hostname (which you probably want to set to something sensible with raspi-config, BTW).

Code:

auto lo

iface lo inet loopback
auto eth0
iface eth0 inet dhcp

allow-hotplug wlan0
auto wlan0
#iface wlan0 inet manual
#wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

This is for a wired network.  For WiFi, follow one of the many guides out there on getting WiFi working on a Raspberry Pi.

   I think sd image came with most of time 10.x.x.x ip from test run and I think sure change back to to auto DHCP.

[salfter]

 I think sd image came with most of time 10.x.x.x ip from test run and I think sure change back to to auto DHCP.

Mine didn't, and I only received it a few days ago.

[tom99]

Tried to compile bfgminer and ran into a wall here:
"Could not find HASH_ITER - please install uthash-dev"

This was near the end when running:
./configure --enable-bfsb

Must've forgotten to include that in the dependencies...my post with the instructions has been updated.

Went ahead and tried cgminer and got it to compile, but it could not detect the bitfury (I am on a V1 M-board).

cgminer doesn't support these boards.

That said, now that I'm near my mining rig for testing, I'm trying to get bfgminer running stable on it.  It runs for a few minutes, getting ~80 GH/s out of my two boards (and another 11 from the BFL hardware also plugged in), but then it starts throwing a bunch of errors in a loop.  I think it's trying to drive the chips too hard by default.  If I change the oscillator setting for each chip from whatever default bfgminer is picking to 52, the hashrate falls back to ~68 GH/s (close to what chainminer was delivering).  So far it's still running as I write this. 

Looking at the bfgminer source code, we find this in driver-bfsb.c, in bfsb_init():

Code:

                bitfury_init_chip(proc);
                bitfury->osc6_bits = 53;
                bitfury_send_reinit(bitfury->spi, bitfury->slot, bitfury->fasync, bitfury->osc6_bits);
                bitfury_init_freq_stat(&bitfury->chip_stat, 52, 56);

I think it's starting with 53 and then setting itself to adjust later between 52 and 56.  Without heatsinks, though, my rig isn't stable at 53 long enough for this mechanism to kick in, so I'm better off fixing it to run at 52:

Code:

                bitfury_init_chip(proc);
                bitfury->osc6_bits = 52;
                bitfury_send_reinit(bitfury->spi, bitfury->slot, bitfury->fasync, bitfury->osc6_bits);
                bitfury_init_freq_stat(&bitfury->chip_stat, 52, 52);

AFAICT there is no way to set this in bfgminer.conf.  You can edit chip speeds at runtime, but the only way to make this setting permanent for now is to edit and recompile the source.

Here's a screenshot of bfgminer in action...currently at 10 minutes, and the ASICs are running in the mid-40s according to the temperature probe I have on one of them:


I was trying to test run bfgminer for 6 Hboards but not good and I got like 100% HW.

[frankenmint]

For the record - My other miner from a competing camp has been working mostly flawlessly all around.  

This unit has just plainly - sucked.  I have run God-Knows how many tests and the only thing I get is inconsistent Data.  I've got a ton of Heatsinks and Fans and it will begin and tune high like within the mid to high 500s upwards to the mid 600s then it just tunes over half of my cards downward until they shut off.  

I'm now off to the store to buy yet more stuff or it (turns out my tiny screw drivers are too big STILL)  


I Too compiled BFG miner and it only ran with 100% hw errors as well (after 15 minutes of running the timings never adjusted upward as they are expected.)  

According to a post earlier - chainminer gives bad data for the 1st 5 minutes anyway so it seemed dumb to run the start mining as a cronjob every 5 minutes.

Here is my last result:

Bank 1
1: 29.721GH/s
2: 0GH/s
3: 31.854GH/s
4: 0GH/s

Bank 2
5: 32.799GH/s
6: 33.945GH/s
7: 0GH/s
8: 0GH/s

Bank 3
9: 26.586GH/s
10: 0GH/s
11: 0GH/s
12: 0GH/s

Bank 4
13: 11.024GH/s
14: 14.431GH/s
15: 5.412GH/s
16: 0GH/s


Off to the electronics store...I'll report better stuff once I can get things up and running.  (I have to run by the job to pickup a multimeter to also check the voltages on individuals cards and will do this soon.  Sorry to be a dumbass about this but do I meaure with the pulse chip and negative lead on the mboard while the unit is on and hashing?  And once I do so I should be tuning it down to .850 right?  I presumed that if the cards turned on period, that they are not necessarily overvoltaged, that overvolted cards will not turn on and begin hashing at all.)

[Keefe]

For the record - My other miner from a competing camp has been working mostly flawlessly all around.  

This unit has just plainly - sucked.  I have run God-Knows how many tests and the only thing I get is inconsistent Data.  I've got a ton of Heatsinks and Fans and it will begin and tune high like within the mid to high 500s upwards to the mid 600s then it just tunes over half of my cards downward until they shut off.  

I'm now off to the store to buy yet more stuff or it (turns out my tiny screw drivers are too big STILL)  


I Too compiled BFG miner and it only ran with 100% hw errors as well (after 15 minutes of running the timings never adjusted upward as they are expected.)  

According to a post earlier - chainminer gives bad data for the 1st 5 minutes anyway so it seemed dumb to run the start mining as a cronjob every 5 minutes.

Here is my last result:

Bank 1
1: 29.721GH/s
2: 0GH/s
3: 31.854GH/s
4: 0GH/s

Bank 2
5: 32.799GH/s
6: 33.945GH/s
7: 0GH/s
8: 0GH/s

Bank 3
9: 26.586GH/s
10: 0GH/s
11: 0GH/s
12: 0GH/s

Bank 4
13: 11.024GH/s
14: 14.431GH/s
15: 5.412GH/s
16: 0GH/s


Off to the electronics store...I'll report better stuff once I can get things up and running.  (I have to run by the job to pickup a multimeter to also check the voltages on individuals cards and will do this soon.  Sorry to be a dumbass about this but do I meaure with the pulse chip and negative lead on the mboard while the unit is on and hashing?  And once I do so I should be tuning it down to .850 right?  I presumed that if the cards turned on period, that they are not necessarily overvoltaged, that overvolted cards will not turn on and begin hashing at all.)

About the voltage measurement, yes while running, but read this: https://bitcointalk.org/index.php?topic=287590.msg3542758#msg3542758

If the voltage is too high, they might begin hashing for a bit until the regulator gets overloaded by a rise in temp.

[frankenmint]

following Dave's post:

One thing worth looking at is the .stat.log - its located here: /run/shm/.stat.log - at the bottom is a card summary.  If you are seeing high miso-err or spi-err from a card, its introducing noise.  That card will drag down any cards following it in its bank.  Try placing that card in the last position of any bank and it shouldn't affect its neighbors.  If it still won't play nice, RMA it - log into your megabigpower.com account and go through the Returns process.

Dave

`speed:13312 noncerate[GH/s]:177.511 (0.693/chip) hashrate[GH/s]:188.753 good:12399 errors:1067 spi-err:38 miso-err:318 jobs:295 cor              es:24% good:256 bad:0 off:0 (best[GH/s]:251.141) Sun Nov 10 23:08:14 2013'

[Keefe]

following Dave's post:

One thing worth looking at is the .stat.log - its located here: /run/shm/.stat.log - at the bottom is a card summary.  If you are seeing high miso-err or spi-err from a card, its introducing noise.  That card will drag down any cards following it in its bank.  Try placing that card in the last position of any bank and it shouldn't affect its neighbors.  If it still won't play nice, RMA it - log into your megabigpower.com account and go through the Returns process.

Dave

`speed:13312 noncerate[GH/s]:177.511 (0.693/chip) hashrate[GH/s]:188.753 good:12399 errors:1067 spi-err:38 miso-err:318 jobs:295 cor              es:24% good:256 bad:0 off:0 (best[GH/s]:251.141) Sun Nov 10 23:08:14 2013'

Is just one of the cards producing all those spi/miso errors?

[frankenmint]

following Dave's post:

One thing worth looking at is the .stat.log - its located here: /run/shm/.stat.log - at the bottom is a card summary.  If you are seeing high miso-err or spi-err from a card, its introducing noise.  That card will drag down any cards following it in its bank.  Try placing that card in the last position of any bank and it shouldn't affect its neighbors.  If it still won't play nice, RMA it - log into your megabigpower.com account and go through the Returns process.

Dave

`speed:13312 noncerate[GH/s]:177.511 (0.693/chip) hashrate[GH/s]:188.753 good:12399 errors:1067 spi-err:38 miso-err:318 jobs:295 cor              es:24% good:256 bad:0 off:0 (best[GH/s]:251.141) Sun Nov 10 23:08:14 2013'

Is just one of the cards producing all those spi/miso errors?

Don't know - I have all cards plugged in when I got this reading.


`speed:13312 noncerate[GH/s]:383.569 (1.498/chip) hashrate[GH/s]:409.743 good:26792 errors:2066 spi-err:36 miso-err:171 jobs:362 cores:13% good:256 bad:0 off:0 (best[GH/s]:0.000) Mon Nov 11 00:08:00 2013' 

My last reading just now