Topic: [ANN] US/North American Bitfury sales NEW STOCK ***NOW SHIPPING*** - page 70. (Read 576785 times)

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

   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.

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:


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


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

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

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.

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.

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

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

On linux I think you can just use dd.

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

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.

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

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


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

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


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():


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:


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:

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.

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

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

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


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



Back to chainminer for now. 

There should be no need to touch the original proxys  but is you want to stop them from starting at boot comment the line out in /etc/rc.local
i have commented out the chainminer start as well.
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
When bfg is running you will see lines saying the last 8 results where bad etc you can ignore these its just bfg doing auto tune

Was looking around and didn't find much, but would love to see a "howto" if there is one for bfgminer and a fully 16-card Bitfury v1 kit.  chainminer to date has not impressed me.

Within the Pi itself run stop-stratum.sh?  There is no way to stop it from the interface.