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

[Keefe]

i have the entire Bank 1 at zero hashing (first 4 slots)    i have 3 140mm fans and one large box fan blowing at it.

have v2.2 H boards with v3 M board.  doesn't matter which H boards go into those slots.

any suggestions?

Im going through something sort of similar however I found that it was becasue my best.cnf file was not configured properly.

I'm tuning each chip to AIfDSo


Bank 1      Bank 2                Bank 3                            Bank 4
1: 35.137GH/s      5: 2.407GH/s      9: 32.583GH/s      13: 34.36GH/s
2: 31.768GH/s      6: 32.583GH/s      10: 0.815GH/s      14: 34.915GH/s
3: 32.175GH/s      7: 7.775GH/s      11: 36.581GH/s      15: 33.471GH/s
4: 34.915GH/s      8: 33.693GH/s      12: 35.804GH/s      16: 30.213GH/s
                  
Bank 1                           Bank 2      Bank 3                        Bank 4
1: 36.86GH/s      5: 34.456GH/s      9: 10.545GH/s      13: 19.936GH/s
2: 31.699GH/s      6: 18.045GH/s      10: 30.834GH/s      14: 20.129GH/s
3: 30.802GH/s      7: 34.424GH/s      11: 4.167GH/s      15: 18.045GH/s
4: 22.565GH/s      8: 20.417GH/s      12: 5.353GH/s      16: 15.353GH/s
                  
                  
                  
Bank 1                          Bank 2                 Bank 3      Bank 4
1: 30.68GH/s      5: 9.964GH/s      9: 35.004GH/s      13: 35.276GH/s
2: 32.212GH/s      6: 19.556GH/s      10: 28.576GH/s      14: 20.186GH/s
3: 32.227GH/s      7: 14.574GH/s      11: 23.293GH/s      15: 13.157GH/s
4: 13.085GH/s      8: 21.289GH/s      12: 23.221GH/s      16: 12.541GH/s
                  


This is my result from 3 tests at 5 minutes in on those settings - I saw a chron job 1-line script here that Keefe wrote that is supposed to reset stratum every 10 minutes, I want to try that script but to restart my miner every 5 minutes - seems like I'm getting solid hashrate within that 1st 5 minutes then everything runs - but as you can see from my past tests - my hashrate seems to drop every time after 5 minutes - I have 6 120 mm fans going and heatsinks so I have no idea what gives

Chainminer's autotune function doesn't kick in until 5 or 10 minutes (not sure which) after it starts. Also, the stats in the first 5 minutes aren't reliable. But if you think autotune is the problem, create /opt/bitfury/best.cnf like this and restart chainminer:

Code:

1	aIfDSo	53
2	aIfDSo	53
3	aIfDSo	53
...
256	aIfDSo	53

Note: Not sure if it matters, but those are tab chars between the columns, not spaces.

Here's a simple script to easily create such a best.cnf:

Code:

rm /opt/bitfury/best.cnf ; for i in {1..256} ; do echo -e "$i\taIfDSo\t53" >> /opt/bitfury/best.cnf ; done

[hendo]

thanks for the pic taco.

i really don't get this.  i've got stable speeds right now around 550 GH/s in the BF GUI yet my stratum pool monitor shows btwn 78.8 and 193 GH/s.  it's been consistently showing this disparity.  

problem is that my Avalons show consistently accurate readings on this same stratum pool monitor of 82-84 GH/s and in its cgminer GUI.

Did you adjust the Difficult for the BF? Just a thought not sure if it helps.

+1

Chainminer/bitfury boards seem to be very sensitive to low diff work.  Lots of low diff shares get queued up and the miner falls behind (polling the chips sequentially) and can't submit fast enough.

My preferred pool/s use variable difficulty and this can also be a problem. The pool will increase diff but the miner is left submitting (or proxy is rejecting) shares that are below target and can take a long time for the pool to climb to a useful diff.

To work around this, on reboots, I restart chainminer every couple of  minutes (which seems to purge the queue) until it reaches the desired diff.  Two to three times usually does it.

However, note that it can still be an issue if the pool changes the diff frequently.  If it lowers, the miner is left submitting old shares of a higher diff for a short delay which, while valid, aren't counted/rewarded appropriately.  If it raises they get rejected as below target temporarily.  Approx once a month I've checked on my miner only to find its thrashed itself back down to minimum diff shares and the pool reporting ~1GH/s.  Normally it will avg same as bitfury web.

If your pool supports setting diff target, rough guidance would be ~1 per GH. eg. full rig 512 diff.

Does anyone else have similar experiences with vardiff pools?... I don't believe there is a way in stratum for miner/proxy to 'request' a given difficulty from the pool.

[ktbken]

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.

 

[tacotime]

thanks for the pic taco.

i really don't get this.  i've got stable speeds right now around 550 GH/s in the BF GUI yet my stratum pool monitor shows btwn 78.8 and 193 GH/s.  it's been consistently showing this disparity.  

problem is that my Avalons show consistently accurate readings on this same stratum pool monitor of 82-84 GH/s and in its cgminer GUI.

might be kind of silly but did you change all three pools to the same pool/worker name?  these aren't failovers, the device will mine on all three pools at the same time

My final suggestion is to just switch to BTC guild and then make the sharediff 256 or 512

[cypherdoc]

Anyone here solo mining with slush's stratum locally?

It uses vardiff. Now the 8889 port monitor shows zero hashing while chainminer  has been showing a stable 550 all night

[allinvain]

Dave, any idea when you'll get a phone number setup. I'd like to call you guys with a somewhat urgent matter.

[cypherdoc]

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?

[klondike_bar]

i have the entire Bank 1 at zero hashing (first 4 slots)    i have 3 140mm fans and one large box fan blowing at it.

have v2.2 H boards with v3 M board.  doesn't matter which H boards go into those slots.

any suggestions?

Im going through something sort of similar however I found that it was becasue my best.cnf file was not configured properly.

I'm tuning each chip to AIfDSo


Bank 1      Bank 2                Bank 3                            Bank 4
1: 35.137GH/s      5: 2.407GH/s      9: 32.583GH/s      13: 34.36GH/s
2: 31.768GH/s      6: 32.583GH/s      10: 0.815GH/s      14: 34.915GH/s
3: 32.175GH/s      7: 7.775GH/s      11: 36.581GH/s      15: 33.471GH/s
4: 34.915GH/s      8: 33.693GH/s      12: 35.804GH/s      16: 30.213GH/s
                  
Bank 1                           Bank 2      Bank 3                        Bank 4
1: 36.86GH/s      5: 34.456GH/s      9: 10.545GH/s      13: 19.936GH/s
2: 31.699GH/s      6: 18.045GH/s      10: 30.834GH/s      14: 20.129GH/s
3: 30.802GH/s      7: 34.424GH/s      11: 4.167GH/s      15: 18.045GH/s
4: 22.565GH/s      8: 20.417GH/s      12: 5.353GH/s      16: 15.353GH/s
                  
                  
                  
Bank 1                          Bank 2                 Bank 3      Bank 4
1: 30.68GH/s      5: 9.964GH/s      9: 35.004GH/s      13: 35.276GH/s
2: 32.212GH/s      6: 19.556GH/s      10: 28.576GH/s      14: 20.186GH/s
3: 32.227GH/s      7: 14.574GH/s      11: 23.293GH/s      15: 13.157GH/s
4: 13.085GH/s      8: 21.289GH/s      12: 23.221GH/s      16: 12.541GH/s
                  


This is my result from 3 tests at 5 minutes in on those settings - I saw a chron job 1-line script here that Keefe wrote that is supposed to reset stratum every 10 minutes, I want to try that script but to restart my miner every 5 minutes - seems like I'm getting solid hashrate within that 1st 5 minutes then everything runs - but as you can see from my past tests - my hashrate seems to drop every time after 5 minutes - I have 6 120 mm fans going and heatsinks so I have no idea what gives

Chainminer's autotune function doesn't kick in until 5 or 10 minutes (not sure which) after it starts. Also, the stats in the first 5 minutes aren't reliable. But if you think autotune is the problem, create /opt/bitfury/best.cnf like this and restart chainminer:

Code:

1	aIfDSo	53
2	aIfDSo	53
3	aIfDSo	53
...
256	aIfDSo	53

Note: Not sure if it matters, but those are tab chars between the columns, not spaces.

Here's a simple script to easily create such a best.cnf:

Code:

rm /opt/bitfury/best.cnf ; for i in {1..256} ; do echo -e "$i\taIfDSo\t53" >> /opt/bitfury/best.cnf ; done

i would suggest checking the voltage on the problem boards. over 0.86V and it might just be that they are getting a little too much voltage and thats causing issues without intensive cooling. try tuning the voltage on problem boards to <0.85V

opposite for the boards that are stable but less than 35GH. check thier voltage and perhaps try tuning it up 0.005-0.01V and see what happens; you should get an extra 1-3GH

[salfter]

I think I have things running at a stable 70 GH/s for two boards now.  It took a bit of stopping and restarting, and I ended up switching from BTC Guild to EclipseMC, but both the web interface and the pool say I've been mining at a bit over 70 GH/s for several hours now.

Last night, I pulled out the D945GNT and the GPUs and added a power adapter cable and a USB hub. The "adapter cable" is a 24-pin ATX extension modified as follows:

1. Tie PS_ON to GND so the power supply stays on as long as it's plugged in (mine has a hard switch on it that can be used to shut it off).
2. Bring out the two +12V pins (and GND) to a pair of 2.5mm barrel plugs for my Jalapeños.

I might add a smaller barrel connector on one of the +5V lines to power the USB hub; that'd allow me to get rid of the wall wart that was included with the hub.

This is what I currently have running:

• v3 M-board with two v2.2 H-boards and a Raspberry Pi model B (version numbers are IIRC)
• Seasonic SSR-550RM power supply (was originally purchased for GPU mining)
• Cooler Master JetFlo 120 fan (maxes out at 95 cfm @ 2000 rpm, but I have it connected through an (included) adapter that knocks the speed back to 1600 rpm as full speed may have been cooling it too much)
• a powered USB hub
• Coldtears 2.8" USB LCD
• two BFL Jalapeños
• D-Link DAP-1522 wireless bridge

The Kill-a-Watt says all this is pulling about 140W at 80 GH/s.  The motherboard-and-GPUs combo was pulling another 300W or so for about 450 kH/s of scrypt mining.  Even with Novacoin mining being worth 10x the equivalent Bitcoin mining, 300W for ~4.5 GH/s equivalent is a bit much...the Jalapeños do that with a tenth of the power.  I could probably knock a few watts off that by replacing the wireless bridge with either a USB WiFi dongle or a proper wired network connection, and by running the hub off of the power supply.  I'd like to put the Bitfury rig in one of the Spotswood cases...waiting for the $ to arrive from CampBX.

I have a bunch of RAM heatsinks on the way...will probably be a week or two before they arrive.  When they do, what's the best way to install them?  Some pictures show them applied to the component side, but most seem to have them on the other side.  I know there are a bunch of thermal vias under each chip, which would seem to indicate that placing the heatsinks on the back of the board would possibly be more effective at getting heat away from the chips.  Are the thermal vias tented or exposed, though?  I've not tried looking at them through a magnifying glass yet, and my near vision apparently isn't what it once was (now get off my lawn!).  If exposed, heatsinks on the back would definitely be the way to go, right?  If tented, it's not so obvious which would be better.

[cypherdoc]

arghhhh.  these things are really sensitive.

just tried redirecting to a pool and needed a reboot.  now not working at all. 

any suggestions when one gets zeros across all slots?

[Keefe]

arghhhh.  these things are really sensitive.

just tried redirecting to a pool and needed a reboot.  now not working at all. 

any suggestions when one gets zeros across all slots?

Reboot again or restart chainminer.

[cypherdoc]

arghhhh.  these things are really sensitive.

just tried redirecting to a pool and needed a reboot.  now not working at all.  

any suggestions when one gets zeros across all slots?

Reboot again or restart chainminer.

i did.  several times.  finally got it to come back up but at suboptimal rates.

these things are really finicky.  once you get them running at optimal rates i wouldn't fiddle with them.  i'm learning to appreciate my avalons coupled with cgminer.

also, it appears to me that the stratum proxy within chainminer does not interface well with a local instance of stratum on one's server when solo mining.  so i'm forced to pool  if i get around to it i may install bfgminer or even cgminer to try and solo once again.  

[cypherdoc]

can someone link me to directions on how to make a backup image of the SD card onto a new one?  these look to be of poor quality and i think i have a corrupted one.

[salfter]

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?

This is cribbed largely from my post yesterday on bringing up cgminer...main difference is that bfgminer needs libjansson, and the configure invocation's a little different:

Code:

# install dependencies

apt-get install autoconf automake libtool libusb-1.0-0-dev libusb-1.0-0 libcurl4-openssl-dev libncurses5-dev libudev-dev libjansson-dev uthash-dev

# clone the repo

git clone https://github.com/luke-jr/bfgminer
cd bfgminer

# build and install

./autogen.sh
./configure --enable-bfsb --disable-opencl --disable-adl
make
(cd libblkmaker && sudo make install && sudo ldconfig)
sudo make install

Compiling on the RPi will take a few minutes...be patient while it does its thing.

Once it's installed, use something like this to run it:

Code:

sudo bfgminer -S bfsb:auto

Support for a bunch of other ASIC miners will be included, so you could (if you wanted) connect them to your RPi through a powered hub and have one bfgminer instance running all of them.  I was getting good speed with the pools I tried, but the warning (see the Bitfury section in README.ASIC in the repo) about a lack of thermal shutdown support at this time means I'll hold off on running this until I get my heatsinks in.

[frankenmint]

okay so i took my full kit to its final home and now its acting wierd:

I can access it through putty and also through the ip address to get to the bitfury web interface.

I CANNOT see it on my router at all.

It is not hashing at all 

I figured it was an ip conflict but I can manually ip to the bitfury using my browser, although on the router interface, I do not see the device at all.  While in testing mode at work I was able to see it appear as rasberrypi.  Any ideas guys?  Using a generic ATT 2wire wireless router.

[Keefe]

okay so i took my full kit to its final home and now its acting wierd:

I can access it through putty and also through the ip address to get to the bitfury web interface.

I CANNOT see it on my router at all.

It is not hashing at all 

I figured it was an ip conflict but I can manually ip to the bitfury using my browser, although on the router interface, I do not see the device at all.  While in testing mode at work I was able to see it appear as rasberrypi.  Any ideas guys?  Using a generic ATT 2wire wireless router.

Maybe the router is only telling you the devices that requested an IP via DHCP?

Once logged into the rPi with putty, try a traceroute to some internet IP address (i.e. 74.125.224.164) and see if/where it stops.

[Soros Shorts]

Got my October kit yesterday and I'm happy to find out that it fits the Spotswood v2 case perfectly. The auto-IP configuration script worked flawlessly too.



With just fans and no heatsinks it only hashed  at 400-450 GH/s due to the H-cards frequently shutting down. With a single goxed-style copper heatsink behind the regulator the nonce rate went up to 525 GH/s. There is still plenty of shutting down of the H-cards going on, and I would probably need to add more heatsinks when I find the time.

IMHO these Oct H-cards come a little to hot from the factory for the average mining enthusiast. Fortunately you have the option of turning the voltage down.

The picture below shows it sitting on top of an August kit.

[frankenmint]

Maybe the router is only telling you the devices that requested an IP via DHCP?

Once logged into the rPi with putty, try a traceroute to some internet IP address (i.e. 74.125.224.164) and see if/where it stops.

Ok tried this.


From 192.168.1.249 icmp_seq=148 Destination Host Unreachable
From 192.168.1.249 icmp_seq=149 Destination Host Unreachable
From 192.168.1.249 icmp_seq=150 Destination Host Unreachable

 Seems that I cannot send anything outbound at all. its not the 2nd half where dave says to set the gateway on the image either because I've done this before and the setup was working correctly at my workstation not too long ago. 

[Keefe]

Maybe the router is only telling you the devices that requested an IP via DHCP?

Once logged into the rPi with putty, try a traceroute to some internet IP address (i.e. 74.125.224.164) and see if/where it stops.

Ok tried this.


From 192.168.1.249 icmp_seq=148 Destination Host Unreachable
From 192.168.1.249 icmp_seq=149 Destination Host Unreachable
From 192.168.1.249 icmp_seq=150 Destination Host Unreachable

 Seems that I cannot send anything outbound at all. its not the 2nd half where dave says to set the gateway on the image either because I've done this before and the setup was working correctly at my workstation not too long ago. 

Check that it has the right gateway address. Is your router 192.168.0.1 or 192.168.1.1 or something else? My router is 192.168.0.1 and my rPi is correctly using it as its default gateway:

Code:

pi@192-168-0-249:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0

[frankenmint]

That did it     ITS WORKING

PM me an address and I'll shoot you a tip.  Thanks again!  Now I'm off to convert this to a BFG bitfury.


You were right too - Work settings work but this router has funny defaults in it which it why it wasn't seeming to work.