[GUIDE] BitFury Miner Support/Tuning

[darkfriend77]

[GUIDE] BitFury Miner Support/Tuning
[GUIDE] GridSeed 5-Chip USB & Blade Miner Support/Tuning
[GUIDE] Innosilicon [A1 Booster + A2 Terminator] Support/Tuning
[GUIDE] Hashra [Lunar Miners] Support/Tuning

Code:

        __________.__  __ ___________                       _____  .__                               
        \______   \__|/  |\_   _____/_ _________ ___.__.   /     \ |__| ____   ___________           
         |    |  _/  \   __\    __)|  |  \_  __ <   |  |  /  \ /  \|  |/    \_/ __ \_  __ \          
         |    |   \  ||  | |     \ |  |  /|  | \/\___  | /    Y    \  |   |  \  ___/|  | \/          
         |______  /__||__| \___  / |____/ |__|   / ____| \____|__  /__|___|  /\___  >__|             
                \/             \/                \/              \/        \/     \/                 
  _________                                  __         /\  ___________           .__                
 /   _____/__ ________ ______   ____________/  |_      / /  \__    ___/_ __  ____ |__| ____    ____  
 \_____  \|  |  \____ \\____ \ /  _ \_  __ \   __\    / /     |    | |  |  \/    \|  |/    \  / ___\ 
 /        \  |  /  |_> >  |_> >  <_> )  | \/|  |     / /      |    | |  |  /   |  \  |   |  \/ /_/  >
/_______  /____/|   __/|   __/ \____/|__|   |__|    / /       |____| |____/|___|  /__|___|  /\___  / 
        \/      |__|   |__|                         \/                          \/        \//_____/  

Thread is in construction!!!  

The goal of this thread is to consolidate all informations to operate and fine tune the bitfury miner.

Development:
- BitFury Testers/Devs

Seller:
- BitFury EU/WordWide
- BitFury US

Case:
- Custom Case Design for Bitfury Miners
- All aluminum open air case for BitFury miners

Raspberry Pi SD Image (only v2+ m-boards)
- ver. 1: 2013-Aug-29_BitfuryRasPi_v0.1
- ver. 2: 2013-Sep-27_BFSB_GM2

Information:
- Instructions for BitFury Miner
- eagle .sch format (M-Board v2.3, H-Card v1.2)

Mining Software Repositories: (use with caution, work in progress!)
- Chainminer - Orginal BitFury  Software
- BFGMiner by Luke-Jr

Clarification: BFGMiner's "littlefury" branch (which should really be renamed "bitfury", and probably will be at some point) is currently tested with LittleFury and generic GPIO only, and should also work with Metabank's rigs, but is still strictly a work-in-progress and not considered a stable or even testing release. I haven't confirmed yet that it is compatible with the board design referenced in the OP, but if not I certainly plan to port it ASAP.

- CGMiner by anajavi

<punin> compile with --enable-bitfury
<punin> con is not going to make support for our hardware because it only runs on linux, pi and needs root access
<punin> so this is as far as cgminer support will go from our side
<punin> ./cgminer --help
<punin> --bitfury-board-type <arg> Bitfury board type, 0=i2c, 1=mboardv1, 2=mboardv2 (default: 0)
<punin> --bitfury-options <arg> Set bitfury chip options chip:speed,chip.. eg. 0:55,1:56... default: ALL:54
<punin> old M-board probably doesn't work because no-one has tested it
<punin> so use --bitfury-board-type 2

- CGMiner by KNK

Anyone willing to help testing a cgminer fork changes with a full kit or at least one board in each bus (A-D)?

In sync with the latest Legkodymov's miner. For BFSB master boards you should leave BITFURY_MUX_OE undefined in bitfury-config.h and change:

Code:

#define BITFURY_MAXCHIPS 100
#define BITFURY_MAXBANKS 1
#define BITFURY_BANKCHIPS 100

to

Code:

#define BITFURY_MAXCHIPS 256
#define BITFURY_MAXBANKS 4
#define BITFURY_BANKCHIPS 16

IRC:
- BitFury Support (Server: ircnet.eversible.com / Channel: #bfsbsupport)

Instructions:
- EU/Worldwide BitFury Guide: Readme BSFSB v0.1 (using m-board v2)
- US BitFury Guide: **US** BitFury Setup Guide (using m-board v1)

Raspberry Pi:
- RPi Beginners

Know Errors:
- Hardware: Soldering errors!

Installation:

Important:



Also please note that if you are not populating the M-board fully the best results will be achieved by spreading the H-boards evenly between the four channels.

[1714217504]

1714217504

[1714217504]

1714217504

[1714217504]

1714217504

[darkfriend77]

FAQ Chainminer & Raspberry:

1. How to Connect to the BitFury's Raspberry Pi?
2. How to change default password?
3. How to fix security issues concerning the EU raspberry pi image?
4. How to fix an empty miner File?
5. How to know which chip correspond to the chip in the stats.log?
6. How to start tuning chips manually?
7. Why does my pool GH estimation is far apart of the BitFury hashrate?
8. Bad & Dead Chips
9. Hashrate droping regularly, despite bitfury admin showing steady noncerate?
10. How to update on the most actual chainminer version (gitpull)?
11. More ... stuff

1. How to Connect to the BitFury's Raspberry Pi?

Use PuTTY or an other SSH client.
Open a SSH connection to the IP of your Raspberry Pi.
User = pi
default password = raspberry

2. How to change default password?

Code:

pi@bitfury ~ $ passwd

3. How to fix security issues concerning the EU raspberry pi image?

We've spotted a minor (potentially major) security issue with the image that was distributed with the shipped
units. The user pi and root both have some ssh credentials set. You should remove these so that no one can
access your unit.

Code:

pi@bitfury ~ $ sudo rm -rf .ssh
pi@bitfury ~ $ sudo rm -rf /root/.ssh
pi@bitfury ~ $ sudo reboot

4. How to fix an empty miner File?

NOTE

Due to my personal epic screw-up the SD image does not contain a working binary. And on top of this some orders were shipped without instructions also We have whipped ourselves vigorously here over the weekend and will try to improve our process so these bloopers don't happen in the future.

Here's how to get your miner working:
1. Check your router for bitfury IP
2. SSH into the raspberry pi (username pi password raspberry)
3. Run following commands:

Code:

cd /opt/bitfury/chainminer
sudo make clean
sudo make
sudo killall screen
sudo /etc/rc.local

You should now be mining. You can check the web interface of the miner with a normal browser and setup your pools there (use the IP that you used for SSH).

5. How to know which chip correspond to the chip in the stats.log?

Sure,

you have [board:chip] on every line and on the board chips are numbered from 40 to 4F beside each chip.

Chips start in the lower left corner, connector facing down, go up, then down, then up, then down again reaching the lower right corner of the board.

spiccioli

6. How to start tuning chips manually?

Code:

pi@bitfury ~ $ nano /run/shm/.stat.log

Code:

1. Chip, Chip number

2. Prog params 	| CAPS = ON, non-caps = off)
   - A = Autotuning (if off, chip will not be modified by autotuning)
   - I = External clock (must have this on to make the chip work)
   - F = Fast clock
   - D = Clock division by 2 (should be on)
   - S = Slowclock (should be on)
   - O = Send clock to output (OutClk pin)
   NOTE: chip has bug: you have to set I to on and S to on to have slow internal clock

3. Speed, Sets clock speed (52-57) Gets set automatically if Autotuning is on

4. Noncerate, Hashrate based on solutions found

5. Hashrate, Hashrate based on..

6. Nonces/round, Amount of solutions found

7. False nonces, Nonces that were returned as valid answer, but were incorrect

8. SPIerr, SPI communication error. Usually caused by noisy chip on SPI chain. Try moving card with noisy chips to last slot of SPI bus

9. MISOerr, Master In Slave Out error. Error in communication from chip to RasPi.

10. Jobs/5min, Job requests in last 5 minutes (relates to how many nonce spaces were scanned by the chip)

11. ChipID, Letter for SPI bus (A,B,C,D) + number for card (1,2,3,4) | ChipID shown with 2 digits (e.g. 01)

12. CoresOK, Show number of cores on chip that have found a valid answer (max 756)

13. Autoclock
    - shut down = Chip will be shutdown and unavailable (Aifdso)
    - speed->0 = If still more errors than correct nonces -> shut down
    - speed up = If you have 0 errors
    - speed down = If you have >5 errors clock down 

- Edit file to fit your needs
- when done, press Ctrl-X
- Save yes
- Write file to: /opt/bitfury/best.cnf

Code:

pi@bitfury ~ $ sudo reboot

7. Why does my pool GH estimation is far apart of the BitFury hashrate?

There is a load balancing included in chainminer, im not really sure how it works. So it is possible that your
hashing power is divided amongst your setup of pools. To verify that you can check the putstats.log which shows
the connections to the pools.

8. Bad & Dead Chips

You might have dead chips (marked as A) on your board that want go anywhere else then 0, ... and autotune ("a") will even be turn of on them and you might have bad chips which autotune will probably tune down to 0 clockspeed, but still autotune ("A") will be turned on (marked as B).



For dead chips there is no solution from software side that I know off. There might be some Hardware possibilities ... I don't know.

For bad chips there is!

First you need to turn of autotune "A" to "a" so that they wont be turned down to 0, because right know as long as they produce to many errors, they will be turned down until 0.

To start of set there clockspeed to 55 on the bad chip and let him run for 10-15 min. Check again. If he is performing better or not ... find a good rate between good and error. You might go down to 54 or 53 ... just check again, where the bad chip is performing at his max. potential ... at the end it might look like this one ...

* a bad one but still more then a stick

It might even be that bad chips get again running fine after running for hours (>24h) ... some users mentioned that bitfury chips have an integrated selfhealing mechanisme ... :-)

9. Hashrate droping regularly, despite bitfury admin showing steady noncerate?

Someone may find this useful... If your pool reports your hashrate dropping regularly DESPITE bitfury admin showing steady noncerate:

1) ssh into your pi
2) run command: crontab -e
3) add this line at the end of file:

*/10    *       *       *       *       sudo /opt/bitfury/start-stratumproxy.sh

4) save & exit

It will restart your stratum proxy every 10 minutes from now on. If you want to cancel it, just run the command again and delete the line.

10. How to update on the most actual chainminer version (gitpull)?

... first .. if it ain't broke don't fix it ...

do backup of your actual bitfury chainminer version...

Code:

pi@bitfury ~ $ cp -a /opt/bitfury /usr/bitfury.backup

Then move to chainminer get latest version clean make ... restart ...

Code:

pi@bitfury ~ $ cd /opt/bitfury/chainminer
pi@bitfury ~ $ git pull
pi@bitfury ~ $ make clean
pi@bitfury ~ $ make

restart the miner ... and hope it will still hash ... :-)

11. More ... stuff

Some info on setup

Chainminer is compiled with encoded username and password that are hard coded in jobconnect.cpp. Currently miner is set to run three getwork threads to localhost 127.0.0.1:8332-8334.

Code:

hosts_t hosts[]={
		{"Basic dHl0dXMucGkyOnB1YmxpY3Bhc3M=","http://127.0.0.1:8332/",{0,0,0,0,0,0,0,0xFFFFFFFF},NULL,NULL,0,0,0} // local stratum client
		,{"Basic dHl0dXMucGkyOnB1YmxpY3Bhc3M=","http://127.0.0.1:8333/",{0,0,0,0,0,0,0,0xFFFFFFFF},NULL,NULL,0,0,0} // local stratum client
		,{"Basic dHl0dXMucGkyOnB1YmxpY3Bhc3M=","http://127.0.0.1:8334/",{0,0,0,0,0,0,0,0xFFFFFFFF},NULL,NULL,0,0,0} // local stratum client
};

If you want to use the miner without stratum proxy you may do so by setting it in the above place. However, you must first encode your miner credentials to be inserted there:

Code:

pi@bitfury01 /opt/bitfury/chainminer $ echo -n username:password | base64
dXNlcm5hbWU6cGFzc3dvcmQ=
pi@bitfury01 /opt/bitfury/chainminer $ 

Then you must copy these encoded credentials into jobconnect.cpp and rebuild the miner:

Code:

dXNlcm5hbWU6cGFzc3dvcmQ=

hosts_t hosts[]={
		{"Basic dXNlcm5hbWU6cGFzc3dvcmQ=","http://getworkpool:port/",{0,0,0,0,0,0,0,0xFFFFFFFF},NULL,NULL,0,0,0} //
};

Save the file and make. Restart miner.

[darkfriend77]

Pool:

- BTCGuild, some users are reporting problems ....

There's a protocol implementation error in the official Stratum proxy.  The original spec always stated the first message a pool should be receiving is a mining.subscribe method.  However, if you try to make the Stratum Proxy do the authorization (-cu -cp args), it sends those *before* the subscribe method.  As a result, you're getting your difficulty set to 2/4/8/etc before the "default subscribe response" is sent.  A workaround is being added to the BTC Guild stratum code today to hopefully prevent this mixup.

- BitMinter, for most users working fine ...

I've been mining on this pool with a 46 GH/s Bitfury ASIC miner for a few days now. I noticed that my hashrate reported by Bitminter dropped occasionally, all the way down to 900 MH/s. These drops coincided with my share target dynamically dropping to a very low number. Then I noticed that the stratum proxy on the Bitfury ASIC wasn't submitting shares any faster with the lower target. The share submission rate stayed the same as the difficulty target slowly climbed back up to maximum level, and my reported hashrate rose back up to normal levels with exactly the same pace.

After removing the -rt (or --real-target) flag from my stratum proxy, this hasn't happened again. This change results in a slightly higher load on the Raspberry Pi that's controlling the ASIC (because the miner now tries to send every diff1 share to the proxy), so I'm not recommending anyone to do this unless you are actually experiencing the above problem.

Monitoring:

- Communication:

Code:

tail /run/shm/.putstat.log

putworks, got, done, sent, url

- Stats:

Heres how you use the make-shift stat collector with the tools currently available, please note that this is a work in progress. But asfar as I can see it works:

ssh in to your bitfury-pi

Code:

pi@bitfury ~ $ mkdir /home/pi/logs
pi@bitfury ~ $ cd  /home/pi/logs
pi@bitfury ~/logs $ nano logger.sh

paste the following code in, modify the board count and desired data collection time and save the file.

Code:

#!/bin/bash
# Bitfury chainminer logfile consolidation script
# Jlsminingcorp and Isokivi, September 2013
# Version 1.4

# User configurable variables
# $logfile is the path to the bitfury chainminer log file
# $output is the path to the board-data output file that you would like to write to
# $outputdir is the directory to store output in
# $logtime is the time (in minutes) to collect data for
# $numboards is the number of H-boards your the miner
logfile="/run/shm/.stat.log"
output="boards.log"
outputdir="."
logtime="0"
numboards="2"

# Timestamps
datestamp=$(ls --full-time "$logfile" | awk '{print $6}')
timestamp=$(ls --full-time "$logfile" | awk '{print $7}' | awk -F"." '{print $1}')

# If log file or output files don't exist then take appropriate action
if [ ! -e "$logfile" ]; then
    echo "$(date)"" : ""Logfile does not exist in the specified location"
    echo "$(date)"" : ""Logfile does not exist in the specified location" >> "$output"
    exit 1
fi

if [ ! -d "$outputdir"/old_logs ]; then
    mkdir "$outputdir"/old_logs
fi

if [ -e "$outputdir"/"$output" ]; then
    numoutput=$(find "$outputdir"/old_logs -type f -name ""$output"*" | wc -l)
    let numoutput="$numoutput"+1
    mv "$outputdir"/"$output" "$outputdir"/old_logs/"$output"."$numoutput"
fi
echo "Date,Time,Board Position,Speed,Noncerate [GH/s],Hashrate [GH/s],Good,Errors,SPI-Errors,Miso-Errors" > "$outputdir"/"$output"

for (( i=1; i<="$numboards"; i++)); do
    chipout="$outputdir""/chips_board_""$i"
    if [ -e "$chipout" ]; then
        numchipout=$(find "$outputdir"/old_logs -type f -name ""chips_board_""$i"*" | wc -l)
        let numchipout="$numchipout"+1
        mv "$chipout" "$outputdir"/old_logs/"$chipout"."$numchipout"
    fi
    echo "Chip stats for board: ""$i" > "$chipout"
    echo "Date,Time,Chip,ProgParams,Speed,Noncerate,Hashrate,Nonces/round,False nonce,SPIerr,MISOerr,Jobs/5min (hash rate),ChipID,CoresOK" >> "$chipout"
done

echo "Starting to log data"
echo "Time to collect data for: ""$logtime"" minutes"

# During the data collection period (set by $logtime) parse data from the logfile to the output files
let countdown="$logtime"*"60"
while [ "$countdown" -ge "0" ]; do

    # If timestamp in the log file is the same as the timestamp on the last entry in the output file then sleep for a while
    # Should make sure that we're somewhere in the middle of the 5 minute chainminer logging period
    # Could use "while" here, but risk getting stuck in a never-ending loop if log file is not being updated
    prevtimestamp="none"
    if [ -e "$outputdir"/old_logs/"$output"."$numoutput" ]; then
        prevtimestamp=$(tail -n 1 "$outputdir"/old_logs/"$output"."$numoutput" | awk -F"," '{print $2}')
    fi
    if [ "$timestamp" == "$prevtimestamp" ]; then
        echo "Chainminer log file not yet updated. Will now sleep for a short while."
        echo "Chainminer log file not yet updated. Will now sleep for a short while." >> "$outputdir"/"$output"
        sleep 60
        timestamp=$(ls --full-time "$logfile" | awk '{print $7}' | awk -F"." '{print $1}')
    fi

    # Strip board data out of the chainminer log file and copy to the output file
    IFS=$'\r\n' datalines=($(grep -A "$numboards" record "$logfile" | tail -n "$numboards" ))
    for i in "${datalines[@]}"; do
        echo -ne "$datestamp","$timestamp", >> "$outputdir"/"$output"
        echo "$i" | tr ":" " " | awk '{$1=$1}1' OFS="," >> "$outputdir"/"$output"
    done

    # Strip chip data out of the chainminer log file and copy to chip output files (one for each H-board)
    for (( i=1; i<="$numboards"; i++)); do
        chipout="$outputdir""/chips_board_""$i"
        let startline="$i"*"16"-"15"
        let endline="$i"*"16"
        while read line; do
            echo -ne "$datestamp","$timestamp", >> "$chipout"
            echo "$line" | awk '{for (i=1; i<=12; i++) printf("%s%s", $(i), i<12 ? OFS="," : "\n"); }'  >> "$chipout"
        done < <(awk 'NR==v1,NR==v2' v1="${startline}" v2="${endline}" "$logfile")
    done

    echo "Time remaining: ""$countdown"" seconds"
    if [ "$countdown" -gt "0" ]; then
        sleep 300
    fi
    let countdown="$countdown"-"300"
    timestamp=$(ls --full-time "$logfile" | awk '{print $7}' | awk -F"." '{print $1}')

done

echo "Finished logging data"
exit 0

chmod +x logger.sh

Code:

pi@bitfury ~/logs $ screen ./logger.sh

Once it has finished: less chips_board_1
Copy the contents and paste it to http://anduck.net/bfsb/#
Press go.
Repeat above three for the next board.
Enjoy!
If you feel like tipping the people who contributed jlsminingcorp (the script) [address pending] and Anduck (the web-app) 1Anduck6bsXBXH7fPHzePJSXdC9AEsRmt4 are the proper recipients.

Software  Tuning:

To put it short, I disabled autotune after a 24h run for all chips and used the best run generated as a starting point. I tuned the chips based on about 50 5 minute runs, rising the speed of a chip if it had 0 errors and lowering it if it had 10% or more. Takes forever and is anal as hell.. most of you guys will love doing this .

Well firstly I mean turning autotune off, that's a typo.

I let the harware run for about 24h, grabbed the best.log and copied it as follows:

Code:

cp /tmp/.best /opt/bitfury/best.cnf

And started manually changing the speeds in /opt/bitfury/best.cnf based on a large number of results with 5 or more minute intervals, thus using a new .stat.log every time. The log only holds a five minute sample, so I collected a large number of notes on each chip using paper and pen. When a chip constantly had 0 errors I pushed it's speed higher and when a chip constantly showed over 10% errors I lovered it. I also re-enabled a bad chip that autotune had shut down, it's not working properly, but is producing 2/3 valid shares without interfering with the other chips, using a speed of 52.

All other chips are now between 54 and 56 speed, 57 was a now go on every chip because of the hightened error rate.

The final modifications (so far) were made based on 20 samples and I believe that this is optimal for now, I will propably try altering the operating temperature next, with a modifiable make-shif enclosure and see where that leads me.

I am by far not sure the 10% rule is optimal, someone else will propably figure out the optimal number there.

The results of my current settings measured from poolside over 6 shifts (9h) put my hashrate with only the 2-board starter kit at 50,68 Gh/s.

I'm raising or lowering the speed of the chips, depending on the number of errors. I have also turned off the autotune. The point of manual tuning is that it works a little bit better than autotune.

Let's take the first chip as an example. Autotune is on (AIfDSo). It can be turned off by changing the capital A to a normal a (aIfDSo). Now the chip will always run at the speed you have set. Current speed is 55. Minimum is 52 and maximum is 57, higher the better of course. In this case I would raise the speed to 56 since there are practically no errors.

Chip two: change the "aifdso" to "aIfDSo" and let's see how it does (it won't work at all with aifdso).

Chip three: Something wrong with it. Turn off the autotune and keep the speed at 52. At least this is what I would do because 0,6 GH/s is still better than 0.

More info here http://punin.com/README_BFSB_v0.1.txt

Hardware Tuning:

August Boards ... R01F measures 1.3K Ohm in Circuit
October Boards ... R01F measures 1.8K Ohm in Circuit

Be sure to test before you start "pencil" modding the boards what resistance the resistor has!!!

For a more durable way to overvoltage the boards you should replace resistor R01F. The nominal value is 1.0K, and to increase the voltage the resistor needs to be replaced with one of a higher value.

A value of 1.5K is generally still safe, and should increase voltage from 0.65 to 0.7. If you want to go higher, you can try 2.2K or maybe even 3.3K if you feel lucky.

Of course, as punin said, this will void your warranty, and may break your card. Keep a close eye on the regulator temperature. Also, the resistor is in a somewhat tricky position to desolder, and you risk getting tin on the pins of the regulator.

The resistor should be 0603 size to fit properly on the pad. Also, I recommend a 1% type with low temperature coefficient. Resistors with high positive temperature coefficient may cause thermal runaway: as the resistor heats up, the voltage increases, causing the resistor to heat up even more.


Note: if you accidentally mess up the capacitor next to the resistor (C10F), and you wish to replace it, use 1nF, 50V, X7R type. Similarly, resistor R02F is 10k, 1%.

a) Get an Ohmmeter or DMM

b) Get an HB or softer Pencil

c) Locate R02F resistor. Donot mod R01F.

d) Make sure R02F measures 1.3KOhm

e) Rub pencil on the surface of R02F 3 - 4 times

f) Measure resistance, if it's 1.2K plug the board in

g) Measure output voltage, and repeat steps e,f if necessary for fine-tuning

h) Hash like a boss

i got those pictures sent from a user ...

to guide through the process of the pencil mod ....

***be aware that you loose warranty of the h-board in doing this ... and you can brick your board!!!***

details:

- temp +10-15°
- 1.6 times higher electricity needed
- up to 50% increased hashrate

Step 1: unplug your h-board ... and locate the R02F Resistor



Step 2: use ur multimeter on the resistor and verify that it shows 1.3k Ohm



Step 3: use a HB (medium grade) pencil (http://en.wikipedia.org/wiki/Pencil) and rub 2-3 times



Step 4: use ur multimeter on the resistor and check how much it was lowered in resistance ...as long as your higher then 1.2k restart step 3 & step 4 ... if it is under 1.2k just swip a little with your finger ...

Step 5: plug in again and start




have fun ...

HC Hardware Tuning:

Here's How I did it:

a) Buy Copper VGA RAM Heatsinks. Usually ships in sets of 8, so 2 packs per h-board.

a.1) I bought these:  http://www.ebay.com/itm/161102078777?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649

b) Affix each piece of VGA RAM Heatsink to the back of each BitFury chip on the H-Board. The RAM heatsinks come with thermal adhesives affixed.

c) Cut a 2 inch strip of DDR3 / DDR2 RAM heatskink for cooling the regulator area. Affix the heatsink to the back of board near the regulator with either thermally conductive glue or use some kind of thermal paste and small dabs of superglue / epoxy at the edges

d) Pencil mod the board until voltage reaches 0.8V. One of my boards is at 0.8V another at 0.84V. I would say 0.85V is the max after which either the regulator will shut down or the hash rate will drop dramatically.

e) Cool the boards with 120mm or bigger cooling fans.

f) Play around with best.cnf (I first changed of all the chip speeds to 54, and measured nonce rate after 10mins of hashing, then changed to 55 and again measured nonce rates. Compared the differences on a excel spreadsheet, and chose 54 or 55 depending on which produced higher hash rates for the chip.)

g) I Use only one pool for mining

h) renice the miner process to -14 or lower

Code:

 2100 root        6 -14 33196 18864  4064 R 81.0  3.8 36h27:30 python ./mining_proxy.py -o us3.eclipsemc.com -p 3333 -cu XXXXXXXXXXX -cp XXXX -gp 8332 -v

h.1) I use htop to do it
h.1.1) sudo apt-get install htop
h.1.2) pi@bitfury / $ htop
h.1.3) Press F7 repeatedly to reduce nice.

[evilscoop]

Nice thx..

Also there is a dev version of bfgminer is the works currently at :-
https://github.com/luke-jr/bfgminer/tree/littlefury

worth keeping an eye on

[Isokivi]

- BitMinter

I've been mining on this pool with a 46 GH/s Bitfury ASIC miner for a few days now. I noticed that my hashrate reported by Bitminter dropped occasionally, all the way down to 900 MH/s. These drops coincided with my share target dynamically dropping to a very low number. Then I noticed that the stratum proxy on the Bitfury ASIC wasn't submitting shares any faster with the lower target. The share submission rate stayed the same as the difficulty target slowly climbed back up to maximum level, and my reported hashrate rose back up to normal levels with exactly the same pace.

After removing the -rt (or --real-target) flag from my stratum proxy, this hasn't happened again. This change results in a slightly higher load on the Raspberry Pi that's controlling the ASIC (because the miner now tries to send every diff1 share to the proxy), so I'm not recommending anyone to do this unless you are actually experiencing the above problem.

I'd like to add that I did not have this issue with bitminter and that my board came with the software fully installed unlike the op's board.

[kano]

For now I can't see there being cgminer support.
I even tried to buy one and was told no.

[Isokivi]

For now I can't see there being cgminer support.
I even tried to buy one and was told no.

Over irc I've seen the cgminer development gradually progressing over the past few days, I suppose punin (and others?) are "going at it" allready.

[kano]

For now I can't see there being cgminer support.
I even tried to buy one and was told no.

Over irc I've seen the cgminer development gradually progressing over the past few days, I suppose punin (and others?) are "going at it" allready.

A fork, not cgminer.

[darkfriend77]

- BitMinter

I've been mining on this pool with a 46 GH/s Bitfury ASIC miner for a few days now. I noticed that my hashrate reported by Bitminter dropped occasionally, all the way down to 900 MH/s. These drops coincided with my share target dynamically dropping to a very low number. Then I noticed that the stratum proxy on the Bitfury ASIC wasn't submitting shares any faster with the lower target. The share submission rate stayed the same as the difficulty target slowly climbed back up to maximum level, and my reported hashrate rose back up to normal levels with exactly the same pace.

After removing the -rt (or --real-target) flag from my stratum proxy, this hasn't happened again. This change results in a slightly higher load on the Raspberry Pi that's controlling the ASIC (because the miner now tries to send every diff1 share to the proxy), so I'm not recommending anyone to do this unless you are actually experiencing the above problem.

I'd like to add that I did not have this issue with bitminter and that my board came with the software fully installed unlike the op's board.

I can report the same .... my 2 H-boards are working fine with BitMinter. I had an issue the first few hours, but .... it fixed itself somehow running now for 24h + without problem ...

[MXRider]

That is a sample picture of the file /run/shm/.stat.log

Autotune ON = AIfDSo
Autotune OFF = aIfDSo

Number after the AIfDSo is the speed of the chip (52-57). Chip is off if it says 0.

[Dalkore]

Thank you for this guide.  I have a couple arriving very soon and can't wait to get them online.  I'll post any feedback or questions I come up with.

[Ollie]

Starter kit with two H-boards. Both H-boards produce over 20 GH/s in bus B or C, but bus A produces only about 12 GH/s regardless of which h-board is in the A1 slot. I heard another on irc having similar situation. Is this a hardware problem on the M-board?

[arorts]

ALERT!! ACHTUNG!! HUOMIO!!
We've spotted a minor (potentially major) security issue with the image that was distributed with the shipped units. The user pi and root both have some ssh credentials set. You should remove these so that no one can access your unit. (This should not be such big issue if you're behind NAT).

How to correct this:
- SSH into your Raspberry Pi with user pi (default password = raspberry)
- Type commands

Code:

sudo rm -rf .ssh
sudo rm -rf /root/.ssh
sudo reboot

- SSH into your Raspberry Pi with user pi (default password = raspberry)

And you should also change your default password, otherwise the unit can still be accessed.

Thanks a lot for putting together this thread!  

So just so that I understand, if I SSH into my rPi using those credentials, reset my password and then remove SSH using the first set of commands, won't that lock me out? How am I supposed to re-login into my rPi in the future if not via SSH and will the new login/password still remain?

[af_newbie]

For now I can't see there being cgminer support.
I even tried to buy one and was told no.

Over irc I've seen the cgminer development gradually progressing over the past few days, I suppose punin (and others?) are "going at it" allready.

A fork, not cgminer.

https://github.com/legkodymov/cgminer

Kano, it is not like you have a trademark on cgminer name.  Call it a fork, a variant or whatever.
It is still a cgminer.

You can incorporate it into cgminer that Con is maintaining or not.  It is ultimately Con's call.

I think Luke-Jr already got a branch for this.

[BenTuras]

So just so that I understand, if I SSH into my rPi using those credentials, reset my password and then remove SSH using the first set of commands, won't that lock me out? How am I supposed to re-login into my rPi in the future if not via SSH and will the new login/password still remain?

Your pi/raspberry login will still work. You are only removing the credentials of punin (i guess).

[-ck]

For now I can't see there being cgminer support.
I even tried to buy one and was told no.

Over irc I've seen the cgminer development gradually progressing over the past few days, I suppose punin (and others?) are "going at it" allready.

A fork, not cgminer.

https://github.com/legkodymov/cgminer

Kano, it is not like you have a trademark on cgminer name.  Call it a fork, a variant or whatever.
It is still a cgminer.

You can incorporate it into cgminer that Con is maintaining or not.  It is ultimately Con's call.

There's no argument here. What he means is that there was a fork made from a slightly earlier version of cgminer from which the driver was developed. There is nothing wrong with that. However the code only works on an RPi, and I have since been asked to merge the code into mainline cgminer. The code itself is unusable generically in cgminer which is designed to work on other architectures and operating systems so I cannot include the code as it currently is - especially since it works in a way that is a profound security issue. It also happens that the hardware design of devices made with bitfury chips to date depend on that unique relationship with RPi devices so I've been unable to rewrite the driver to make the usb sticks and other bitfury based hardware work anywhere else.  I've not found a decent solution to this issue, but I'm still investigating and watching.

[kano]

For now I can't see there being cgminer support.
I even tried to buy one and was told no.

Over irc I've seen the cgminer development gradually progressing over the past few days, I suppose punin (and others?) are "going at it" allready.

A fork, not cgminer.

https://github.com/legkodymov/cgminer

Kano, it is not like you have a trademark on cgminer name.  Call it a fork, a variant or whatever.
It is still a cgminer.

You can incorporate it into cgminer that Con is maintaining or not.  It is ultimately Con's call.

I think Luke-Jr already got a branch for this.

Woo hoo rant time
Funny how people post such rants when the reason is shown in the last line
Read the above post ...

This is actually a typical problem we are seeing at the moment, someone goes and forks cgminer, writes a driver, but they don't keep incorporating the latest changes.

Also ... of course when we make critical changes to the inner workings of cgminer, of course we can't test that on hardware we don't have.
Oh well SEP.

As I said I even asked to BUY the hardware, but was told no. Odd.

Enjoy the cake, the cake is a lie

[af_newbie]

As I said I even asked to BUY the hardware, but was told no. Odd.

Sorry, no rant from me.  Just you keep saying it is not cgminer.  It is cgminer, maybe not the one you and Con are maintaining but cgminer nevertheless.
 
You asked to buy and they said no?  That is odd indeed.  I don't know what these h/w guys are smoking.  They should be sending free cards to you, Con and Luke-Jr pronto.  How much they cost?  $50/card? 

[Luke-Jr]

Clarification: BFGMiner's "littlefury" branch (which should really be renamed "bitfury", and probably will be at some point) is currently tested with LittleFury and generic GPIO only, and should also work with Metabank's rigs, but is still strictly a work-in-progress and not considered a stable or even testing release. I haven't confirmed yet that it is compatible with the board design referenced in the OP, but if not I certainly plan to port it ASAP.

[dani]

Code:

Code:

A = Autotuning (if off, chip will not be modified by autotuning) [A = on / a = off]
I = External clock (must have this on to make the chip work)     [I = on / i = off]
F = Fast clock                                                   [F = on / f = off]
D = Clock division by 2 (should be on)                           [D = on / d = off]
S = Slowclock (should be on)                                     [S = on / s = off]
O = Send clock to output (OutClk pin)                            [O = on / o = off]

anyone has more information on what happens when turnin on/off those? I found setting i to 1 chips lets other chips across the whole unit to stop working. Anything else?