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

[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

[Doff]

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

A couple things I found with cooling is you don't want to cool it too much, there is this weird middle ground. Also you need to check the Voltage on each Unit, I found some were at .87, some at .80, others at .88, it was all over the place. I have almost all of them now at 8.6 with one card that has some dead Chips. Its been stable for two days but it did take a lot testing. I now only have 3 fans on top of the unit, and 1 Box fan on low blowing across it from the opposite side of the regulators.

You check the voltage with the Unit on, using the Ground on the two Silver PCI power connectors at the end, and the other on the pulse regulator on the silver part. I also had to ask since I don't usually mess with electronics in this way.

The other fine tuning you need to do is with the best.cnf. I just copied the .stat.log to a new file called best.cnf after it ran for around 12 hours and then turned off the Auto on the dead chips, or near dead chips which gave me another 5-7G. I found that info here https://bitcointalk.org/index.php?topic=287590.msg3079406#msg3079406 and from people in this post.

[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

A couple things I found with cooling is you don't want to cool it too much, there is this weird middle ground. Also you need to check the Voltage on each Unit, I found some were at .87, some at .80, others at .88, it was all over the place. I have almost all of them now at 8.6 with one card that has some dead Chips. Its been stable for two days but it did take a lot testing. I now only have 3 fans on top of the unit, and 1 Box fan on low blowing across it from the opposite side of the regulators.

You check the voltage with the Unit on, using the Ground on the two Silver PCI power connectors at the end, and the other on the pulse regulator on the silver part. I also had to ask since I don't usually mess with electronics in this way.

The other fine tuning you need to do is with the best.cnf. I just copied the .stat.log to a new file called best.cnf after it ran for around 12 hours and then turned off the Auto on the dead chips, or near dead chips which gave me another 5-7G. I found that info here https://bitcointalk.org/index.php?topic=287590.msg3079406#msg3079406 and from people in this post.

Others stated NOT to do it that way as it overdeclares your voltage by anywhere between .06 and .02 V

I took out 10 cards, just trying the top six performing cards for the next 30 minutes to confirm for sure that these are working well they are avg about 30 Gh per card (which in my mind is okay if they at least stay on)

[Doff]

All I know is once I got the heat right, and fixed the overclocked voltage on the bad cards they have been running fantastic.


speed:13536 noncerate[GH/s]:574.280 (2.243/chip) hashrate[GH/s]:586.880 good:40113 errors:426 spi-err:10 miso-err:263 duplicates:3 jobs:262 cores:99% good:256 bad:0 off:0 (best[GH/s]:593.464) Mon Nov 11 01:10:03 2013
board-2 speed   nrate   hrate   good    errors  spi-err miso-er duplic  good    bad     off     per chip        good cores
0:      848     38.397  38.812  2682    14      3       0       1       16      0       0       (2.400/chip)    100%
1:      848     37.438  37.374  2615    8       0       0       0       16      0       0       (2.340/chip)    100%
2:      848     35.648  37.533  2490    55      1       0       0       16      0       0       (2.228/chip)    97%
3:      848     36.665  37.025  2561    7       0       0       0       16      0       0       (2.292/chip)    100%
4:      848     36.751  37.480  2567    12      3       0       1       16      0       0       (2.297/chip)    99%
5:      848     36.278  37.913  2534    62      0       0       1       16      0       0       (2.267/chip)    98%
6:      848     36.980  37.596  2583    63      0       0       0       16      0       0       (2.311/chip)    97%
7:      832     35.147  35.577  2455    14      0       0       0       16      0       0       (2.197/chip)    100%
8:      848     35.247  36.666  2462    17      2       0       0       16      0       0       (2.203/chip)    100%
9:      832     33.816  34.330  2362    11      0       0       0       16      0       0       (2.113/chip)    100%
A:      848     36.307  36.370  2536    10      0       0       0       16      0       0       (2.269/chip)    100%
B:      848     36.235  37.649  2531    67      0       0       0       16      0       0       (2.265/chip)    98%
C:      848     34.761  36.867  2428    50      0       0       0       16      0       0       (2.173/chip)    98%
D:      848     36.063  36.212  2519    8       0       1       0       16      0       0       (2.254/chip)    100%
E:      848     34.088  34.383  2381    5       0       262     0       16      0       0       (2.130/chip)    93%
F:      848     34.460  35.091  2407    23      1       0       0       16      0       0       (2.154/chip)    99%

That's been running since Early Friday without needing to touch it, consistently over 570GH

[frankenmint]

how did you get that output from the pi?

[Doff]

how did you get that output from the pi?

I just cat the file like this, lots of ways you can do it in linux.  

cat .stat.log | tail -n 18

That gives you the last 18 lines of the log.

Also you may need to elongate your terminal window otherwise it truncates it in a weird way.

[frankenmint]

how did you get that output from the pi?

I just cat the file like this, lots of ways you can do it in linux.  

cat .stat.log | tail -n 18

That gives you the last 18 lines of the log.

Also you may need to elongate your terminal window otherwise it truncates it in a weird way.

That has got to be the one BIG positive about this whole experience, I never touched any linux before this

[Doff]

how did you get that output from the pi?

I just cat the file like this, lots of ways you can do it in linux.  

cat .stat.log | tail -n 18

That gives you the last 18 lines of the log.

Also you may need to elongate your terminal window otherwise it truncates it in a weird way.

That has got to be the one BIG positive about this whole experience, I never touched any linux before this

I think you will be happy once you get all your rigs running at 570+, they have definitely been more finicky then I thought they would be.

I honestly think if I knew what I was doing I could get this thing over 600. I am kinda hoping more people experiment with the OCT Hardware and share it with the community. I know there are some fantastic hardware guys out there.

[cypherdoc]

just to throw more crap variables into the mix; i had a bad Raspi.

bad enough only to take hashing sub 100's for several days making it all the more confusing.  thank goodness it fully failed allowing me to figure it wasn't so much the boards.  inserted a new one and am at least now up in the 400's now.

Chainminer doesn't match my pool readings either.  ugh.

[frankenmint]

just to throw more crap variables into the mix; i had a bad Raspi.

bad enough only to take hashing sub 100's for several days making it all the more confusing.  thank goodness it fully failed allowing me to figure it wasn't so much the boards.  inserted a new one and am at least now up in the 400's now.

Chainminer doesn't match my pool readings either.  ugh.

Deleted my last post because I'm still needing to tune down two cards that go out to zero.  Did your Raspi give any symptoms? 

[ktbken]

Hi
Anyone got bfg working with new v3 boards  as it cannot seem to see them with normal settings that work for v1-2 ?