**US** BitFury Setup Guide

[Trance104]

Well there we go. Thanks for that. I'm (obviously) n00b with this. This is my first rpi. I would prefer to remote into it if possible. I don't think any of my monitor have an HDMI connection. lol 

How would I go about finding out the IP address of the device?

[twmz]

Well there we go. Thanks for that. I'm (obviously) n00b with this. This is my first rpi. I would prefer to remote into it if possible. I don't think any of my monitor have an HDMI connection. lol 

How would I go about finding out the IP address of the device?

As I said, it will be xxx.xxx.xx.249.  So if your home network is 192.168.1.x, then it will be 192.168.1.249.  Or if your home network is 10.0.1.x, then it will be 10.0.1.249, etc.  So figure out the IP address of some other computer on your network and then change the last number to 249.

[Trance104]

Well there we go. Thanks for that. I'm (obviously) n00b with this. This is my first rpi. I would prefer to remote into it if possible. I don't think any of my monitor have an HDMI connection. lol  

How would I go about finding out the IP address of the device?

As I said, it will be xxx.xxx.xx.249.  So if your home network is 192.168.1.x, then it will be 192.168.1.249.  Or if your home network is 10.0.1.x, then it will be 10.0.1.249, etc.  So figure out the IP address of some other computer on your network and then change the last number to 249.

You could of told me to use ipconfig!!!!

Anyways, I got it! Thank you so much!

I GREATLY appreciate your patience. I'll be sending you a thank you tip. Won't be much, but it's still something.

Happy Thanksgiving!



*edit*

I spoke too soon. I'm getting a REALLY low hash rate. ~7 gh that slowly falls to 0 and then it sits at zero for a while. I'm mining on Slush's pool. Any tips?

[Keefe]

Well there we go. Thanks for that. I'm (obviously) n00b with this. This is my first rpi. I would prefer to remote into it if possible. I don't think any of my monitor have an HDMI connection. lol  

How would I go about finding out the IP address of the device?

As I said, it will be xxx.xxx.xx.249.  So if your home network is 192.168.1.x, then it will be 192.168.1.249.  Or if your home network is 10.0.1.x, then it will be 10.0.1.249, etc.  So figure out the IP address of some other computer on your network and then change the last number to 249.

You could of told me to use ipconfig!!!!

Anyways, I got it! Thank you so much!

I GREATLY appreciate your patience. I'll be sending you a thank you tip. Won't be much, but it's still something.

Happy Thanksgiving!



*edit*

I spoke too soon. I'm getting a REALLY low hash rate. ~7 gh that slowly falls to 0 and then it sits at zero for a while. I'm mining on Slush's pool. Any tips?

Do you already have lots of airflow over the H-boards?

To troubleshoot some problems (besides overheating), login with ssh and check what's going on with chainminer and the proxies. To get the list of screen sessions, do "sudo screen -r". Then do "sudo screen -r 1234" (replace 1234 with one of the numbers in the previous list) to view a session. Hit ctrl-a d to get out of the session without ending it. The first session listed should be chainminer, the other 3 are the proxies. Sometimes I find chainminer spewing errors about a queue being too full. Restarting chainminer with "sudo /opt/bitfury/start-miner.sh" usually fixes it.

[Cablez]

I find if the miner reboots and starts mining on its own its rate is very low.  Just use the web interface and hit stop miner then wait 2sec and hit start miner and then it works normally again.

[tom99]

make sure you have good cooling on new Hboard is OC already or you might burn it.

edit: BFgminer will work with v2 or v3 without change anything.

[sveetsnelda]

I find if the miner reboots and starts mining on its own its rate is very low.  Just use the web interface and hit stop miner then wait 2sec and hit start miner and then it works normally again.

This is due to SPI errors on start-up and only seems to happen on old versions of chainminer (it looks like they accounted for this in the newer versions).  This is listed on the announcement on the web interface.

Also, while not a big deal, you don't need to hit "stop" at all because the "start" script stops the previous miner instance anyways.  Just hit "start" (or script it so that it happens on reboot).

[Cablez]

Cool, thanks for the info sveetsnelda.

[Trance104]

Hmmm.. Only averaging ~10 gh now. I stuck a fan next to it.... I'm not sure what else to do. 

[klondike_bar]

Hmmm.. Only averaging ~10 gh now. I stuck a fan next to it.... I'm not sure what else to do. 

what happens if you SSH to the system and type
"nano /run/shm/.stat.log"

and report back what you see. If you only have 10GH, its possible or likely that some or most of the chips got too hot and switched off. if this is the case you have 3 solutions:

1) more cooling and HEATSINKS
2) modify the miner.h file. to do this, SSH in and type:
"cd /opt/bitfury/chainminer
sudo pico miner.h"
and then modify:

max_error : from 5 to 6 (increases tolerance to errors slightly)
min_good : from 50 to 40 (increases tolerance to low-performance slightly)
max_speed : from 57 to 55
def_speed : from 55 to 53
min_speed : 52
[these options help prevent the system from switching chips off if they are borderline working]

3) modify the optimal settings to start the miner at a more managable speed. SSH and type:
"nano /run/shm/.stat.log"
change everything to AIfDSo 53
exit, and tell it to save as "opt/bitfury/best.cnf"

[jddebug]

Hmmm.. Only averaging ~10 gh now. I stuck a fan next to it.... I'm not sure what else to do. 

what happens if you SSH to the system and type
"nano /run/shm/.stat.log"

and report back what you see.

klondike_bar,

If you (or anyone who understands what these logs mean) have time, please take a look at these. I've found my bitfurys are not performing like others I read about here and would like to get them working better. I've performed no mods. I just plugged them in and this is what I got. These are first batch US kits btw.

Maybe I should do as you suggested to Trance but I'd like the feedback first.

http://pastebin.com/MwU03Rdi    (nano /run/shm/.stat.log  from first part of my kit)

http://pastebin.com/01phz1a5     (nano /run/shm/.stat.log  from second part of my kit)

Thank you.

[klondike_bar]

Hmmm.. Only averaging ~10 gh now. I stuck a fan next to it.... I'm not sure what else to do. 

what happens if you SSH to the system and type
"nano /run/shm/.stat.log"

and report back what you see.

klondike_bar,

If you (or anyone who understands what these logs mean) have time, please take a look at these. I've found my bitfurys are not performing like others I read about here and would like to get them working better. I've performed no mods. I just plugged them in and this is what I got. These are first batch US kits btw.

Maybe I should do as you suggested to Trance but I'd like the feedback first.

Thank you.

If possible, shorten the lists to only the chips performing lower than 1.7GH, and it will be easier to spot the trend/problem. What batch is your hardware from? in the august/october stuff the hardware benefited from modding higher (not just speed but also getting low-performance chips to run correctly), but for the newer batch with higher voltage, issues will arise if you dont provide sufficient cooling (this means heatsinks AND airflow)

I would suggest: buy a $10-15 multimeter and check the voltage on each card. Take the red positive signal from the top contact on the large cube-like inductor and the ground from the pci-e or screw terminal GND. You want a voltage around 0.77-0.82 if you have 'okay' cooling and 0.82-0.88 if you have relatively large heatsinks on each backside of the PCB, and lots of cool airflow

In your case, the voltage on a lot of your cards seems low, almost like the august batch. check the voltage and if necessary, apply the pencil mod to increase it. If the voltage is high, then the issue is your cooling

[jddebug]

Hmmm.. Only averaging ~10 gh now. I stuck a fan next to it.... I'm not sure what else to do. 

what happens if you SSH to the system and type
"nano /run/shm/.stat.log"

and report back what you see.

klondike_bar,

If you (or anyone who understands what these logs mean) have time, please take a look at these. I've found my bitfurys are not performing like others I read about here and would like to get them working better. I've performed no mods. I just plugged them in and this is what I got. These are first batch US kits btw.

Maybe I should do as you suggested to Trance but I'd like the feedback first.

Thank you.

If possible, shorten the lists to only the chips performing lower than 1.7GH, and it will be easier to spot the trend/problem. What batch is your hardware from? in the august/october stuff the hardware benefited from modding higher (not just speed but also getting low-performance chips to run correctly), but for the newer batch with higher voltage, issues will arise if you dont provide sufficient cooling (this means heatsinks AND airflow)

I would suggest: buy a $10-15 multimeter and check the voltage on each card. Take the red positive signal from the top contact on the large cube-like inductor and the ground from the pci-e or screw terminal GND. You want a voltage around 0.77-0.82 if you have 'okay' cooling and 0.82-0.88 if you have relatively large heatsinks on each backside of the PCB, and lots of cool airflow

In your case, the voltage on a lot of your cards seems low, almost like the august batch. check the voltage and if necessary, apply the pencil mod to increase it. If the voltage is high, then the issue is your cooling

I'll clean up those logs and remove everything thats over 1.7GH. Sorry about that. I didn't know what would be good information and what would be useless. Yes, these are August batch.

[jddebug]

I could use a legend telling what each column means. Is the hashrate 1.561 or 1.934? Does one of these tell what the voltage is?


2       AIfDSo  55      1.561   1.934   109     7       0       0       183     [0:1]   36      5 7 5 6 7 7 8 8 7 7 7 7 7 7 7 7         2 0 2 1 0 0 0 0 1 1 0 0 0 0 0 0

[JTrain_51]

Definitely very good advise and TLC on your miners.

Totally agree great advice!
Love your miners - hope to see more work done

[Keefe]

I could use a legend telling what each column means. Is the hashrate 1.561 or 1.934? Does one of these tell what the voltage is?


2       AIfDSo  55      1.561   1.934   109     7       0       0       183     [0:1]   36      5 7 5 6 7 7 8 8 7 7 7 7 7 7 7 7         2 0 2 1 0 0 0 0 1 1 0 0 0 0 0 0

I like to call the 1.934 number the work rate, though most call it the hashrate. It's based on how many work units were processed. It's a function of the voltage and speed setting (55 in this case), and is usually quite stable, unless the VRM is overloaded/overheating. The 1.561 number, commonly called the noncerate, is based on how many good nonces are found, and will vary randomly even under perfect conditions (i.e. no errors).

Here's a legend for your line above:
Chip#: 2
Flags: AIfDSo (A = autotune on, check the source code for the others)
Speed: 55
Noncerate: 1.561
Hashrate: 1.934
Good nonces: 109
Nonce errors: 7
SPI errors: 0
MISO errors: 0
Work units: 183
Chip position: [0:1]
Bad cores: 36 (how many of 756 have not yet found a good nonce)

I don't know what the last two sets of numbers are.

The boards don't have digital voltage or temp meters, unfortunately.

[Keefe]

2) modify the miner.h file. to do this, SSH in and type:
"cd /opt/bitfury/chainminer
sudo pico miner.h"
and then modify:

max_error : from 5 to 6 (increases tolerance to errors slightly)
min_good : from 50 to 40 (increases tolerance to low-performance slightly)
max_speed : from 57 to 55
def_speed : from 55 to 53
min_speed : 52
[these options help prevent the system from switching chips off if they are borderline working]

Don't forget to recompile chainminer after editing miner.h or nothing will change. Just running 'make' should do that.

[Keefe]

I could use a legend telling what each column means. Is the hashrate 1.561 or 1.934? Does one of these tell what the voltage is?


2       AIfDSo  55      1.561   1.934   109     7       0       0       183     [0:1]   36      5 7 5 6 7 7 8 8 7 7 7 7 7 7 7 7         2 0 2 1 0 0 0 0 1 1 0 0 0 0 0 0

I like to call the 1.934 number the work rate, though most call it the hashrate. The work rate is based on how many work units were processed. It's a function of the voltage and speed setting (55 in this case), and is usually quite stable. The 1.561 number, commonly called the noncerate, is based on how many good nonces are found, and will vary randomly even under perfect conditions (i.e. no errors).

Here's a legend for your line above:
Chip#: 2
Flags: AIfDSo (A = autotune on, check the source code for the others)
Speed: 55
Noncerate: 1.561
Hashrate: 1.934
Good nonces: 109
Nonce errors: 7
SPI errors: 0
MISO errors: 0
Work units: 183
Chip position: [0:1]
Bad cores: 36 (how many of 756 have not yet found a good nonce)

I don't know what the last two sets of numbers are.

The boards don't have digital voltage or temp meters, unfortunately.

In case you're curious about the math...

After the first 5 minutes of chainminer running, the stats are updated every 5 minutes, so the numbers are based on the previous 5 minutes of work. Each core does 4194304 (2²²) hashes per work unit. 183 work units * 756 cores * 4194304 hashes / 300 seconds = 1.934 billion hashes per second.

On average, 1 good nonce (diff=1) should be found per 4294967296 (2³²) hashes. Since 109 good nonces were found, it calcs the noncerate like this: 109 good nonces * 4294967296 average hashes per nonce / 300 seconds = 1.561 billion hashes per second. This was probably just an unlucky 5 minute interval and you'll see the noncerate higher than the hashrate at other times.

The 7 nonce errors are nonces the chip reported as good but chainminer found to be actually bad. This happens because of bad bit flips during the hashing process in the chip and occurs much more often when overclocked too much. Less than 5% average nonce errors is just fine. In this case, we can expect at least 4.8% nonce errors anyway because apparently 36 of the 756 cores are malfunctioning, at least at this clock speed and voltage. The chip's hashing cores are arranged in a 21x36 grid, at least logically, so it is common to find a whole row or column bad. You can see that visually in /tmp/.core.log

[Keefe]

3) modify the optimal settings to start the miner at a more managable speed. SSH and type:
"nano /run/shm/.stat.log"
change everything to AIfDSo 53
exit, and tell it to save as "opt/bitfury/best.cnf"

Don't forget the slash: /opt/bitfury/best.cnf

[jddebug]

2) modify the miner.h file. to do this, SSH in and type:
"cd /opt/bitfury/chainminer
sudo pico miner.h"
and then modify:

max_error : from 5 to 6 (increases tolerance to errors slightly)
min_good : from 50 to 40 (increases tolerance to low-performance slightly)
max_speed : from 57 to 55
def_speed : from 55 to 53
min_speed : 52
[these options help prevent the system from switching chips off if they are borderline working]

Don't forget to recompile chainminer after editing miner.h or nothing will change. Just running 'make' should do that.

Do I need to be in a particular directory when I run "make"?