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

[tom99]

if you use a good sd card, and shutdown the rpi properly you shouldnt have any issues....   my bitfury equip has been running non stop since january,  once it was set up, ive never had to touch it,  other that log in via pc and change pools.... 

I second that. I have a V3 m-board and V2.2 h-cards. I just keep some fans on them, make sure the cards don't wobble and they're good to go. I just wish the stratum proxy worked as failover (if primary pool fails, go to backup, so on), instead of splitting work.

I previously griped a dozen times because the machine would always orrupt SD cards and actually managed to turn two cards un-usable. (even when trying to format under a linux OS)

I upgraded to a Class 10, 16GB card and no more issues. I can unplug the machine hot, reboot it safely, no issues for a month or two now.  Definitely an issue with using low-end SD cards.

  what was brand name of this class 10 16GB card?  I got problem again with sd card.

[1714601026]

1714601026

[1714601026]

1714601026

[1714601026]

1714601026

[1714601026]

1714601026

[xstr8guy]

if you use a good sd card, and shutdown the rpi properly you shouldnt have any issues....   my bitfury equip has been running non stop since january,  once it was set up, ive never had to touch it,  other that log in via pc and change pools....  

I second that. I have a V3 m-board and V2.2 h-cards. I just keep some fans on them, make sure the cards don't wobble and they're good to go. I just wish the stratum proxy worked as failover (if primary pool fails, go to backup, so on), instead of splitting work.

I previously griped a dozen times because the machine would always orrupt SD cards and actually managed to turn two cards un-usable. (even when trying to format under a linux OS)

I upgraded to a Class 10, 16GB card and no more issues. I can unplug the machine hot, reboot it safely, no issues for a month or two now.  Definitely an issue with using low-end SD cards.

  what was brand name of this class 10 16GB card?  I got problem again with sd card.

Patriot is a great premium brand.  Be sure to get an rPi compatible SD card though.  Check here first...  http://elinux.org/RPi_SD_cards

Kingston are crap!

[mb300sd]

Use bfgminer and you won't have SD card issues anymore. I believe chainminer does a lot of writes, while bfgminer does none. Still using the crappy SD card supplied with my unit.

[Gyrsur]

6 of my 16 bitfury v1.2 H-CARD died over the time. October 2013 batch. no overclocking and no overheating! did someone face the same experience??

EDIT: seems to me quality of the bitfury v1.2 H-CARD (October 2013 batch) is not good enough to work with it 24/7 for a half year. some component on the card died. cards did not work again if I changed the slot on the bitfury v2.3 M-CARD.

[allinvain]

6 of my 16 bitfury v1.2 H-CARD died over the time. October 2013 batch. no overclocking and no overheating! did someone face the same experience??

EDIT: seems to me quality of the bitfury v1.2 H-CARD (October 2013 batch) is not good enough to work with it 24/7 for a half year. some component on the card died. cards did not work again if I changed the slot on the bitfury v2.3 M-CARD.

I had the same problem, but luckily only 1 card died so far. Shame that they are so expensive to replace.

[allinvain]

True enough about the sd cards, sandisk + proper shutdown and they never seem to corrupt. I've yet to have one flake out on 12 rigs. The wobble thing is a very fair criticism though. Never should've been set up with that silly connector.

I just wish the stratum proxy worked as failover (if primary pool fails, go to backup, so on), instead of splitting work.

Just chuck chainminer and that proxy and run cgminer.

Can anyone confirm cgminer working with V2.2 H-cards? I followed instructions found elsewhere in the forum, compiled from a certain github repo (can't find link right now) with --enable-bab and running cgminer did not hash, just gave spi errors. If I could get cgminer going for my V3 m/V2.2 H rig, I'd be very very happy  

All of my hcards are v2 and running cgminer. Just nano driver-bab.c and change this:

#define BAB_SPI_SPEED 96000

to this:

#define BAB_SPI_SPEED 625000

run make again and you're gold.

These options can be passed to cgminer on startup:

--bab-options <arg> Set BaB options max:def:min:up:down:hz:delay:trf

As mentioned above bfgminer also works with --enable-bfsb, but cgminer autotunes bitfury, uses far less of the rpi's weak cpu, and runs much better imo.

I tried that but it seems that hashrate is consistently lower than with chainminer. I've got v2.3 h-cards. The v1.2 h-cards run on average about the same as with chainminer - or so it seems. I should mention that I did not change the SPI SPEED value for the v1.2 h-cards rigs only for the v2.3.


Maybe I should let cgminer tune for a longer period of time?

[daddyfatsax]

I tried changing the SPI_SPEED on my v1.2 cards, and it just gives me "BaB delay getting work" when it starts up.

[solarion]

I tried changing the SPI_SPEED on my v1.2 cards, and it just gives me "BaB delay getting work" when it starts up.

Change line 1663 in driver-bab.c from "false" to "true". Don't forget to run make again.

[solarion]

True enough about the sd cards, sandisk + proper shutdown and they never seem to corrupt. I've yet to have one flake out on 12 rigs. The wobble thing is a very fair criticism though. Never should've been set up with that silly connector.

I just wish the stratum proxy worked as failover (if primary pool fails, go to backup, so on), instead of splitting work.

Just chuck chainminer and that proxy and run cgminer.

Can anyone confirm cgminer working with V2.2 H-cards? I followed instructions found elsewhere in the forum, compiled from a certain github repo (can't find link right now) with --enable-bab and running cgminer did not hash, just gave spi errors. If I could get cgminer going for my V3 m/V2.2 H rig, I'd be very very happy  

All of my hcards are v2 and running cgminer. Just nano driver-bab.c and change this:

#define BAB_SPI_SPEED 96000

to this:

#define BAB_SPI_SPEED 625000

run make again and you're gold.

These options can be passed to cgminer on startup:

--bab-options <arg> Set BaB options max:def:min:up:down:hz:delay:trf

As mentioned above bfgminer also works with --enable-bfsb, but cgminer autotunes bitfury, uses far less of the rpi's weak cpu, and runs much better imo.

I tried that but it seems that hashrate is consistently lower than with chainminer. I've got v2.3 h-cards. The v1.2 h-cards run on average about the same as with chainminer - or so it seems. I should mention that I did not change the SPI SPEED value for the v1.2 h-cards rigs only for the v2.3.


Maybe I should let cgminer tune for a longer period of time?

Watch the hw error rate. Cgminer is set to 1.0% tuneup and 10.0% tunedown so it wipes out huge numbers of hw errors. The mechanism it uses to do this is the osc so it's tuning chips all the way down to speed 32 over time. This causes power efficiency to improve dramatically over time, but if you don't want it to do that or you want it to do it in moderation then simply pass different values to cgminer at startup via the --bab-options parameter mentioned above. It's extremely flexible and capable of matching chainminer's performance.

[allinvain]

For me the power efficiency is not so important yet, I merely want it to match or exceed the performance of chainminer. Should I also set the BAB_SPI_SPEED higher even on v1.2 cards, and could you give me an example of the bab-options you use or perhaps some more aggressive bab options?

lol, found a post on a different forum by you that could be beneficial:

I've been altering these lines in driver-bab.c

#define BAB_MAXSPEED 57
#define BAB_DEFMAXSPEED 55
#define BAB_DEFSPEED 53
#define BAB_MINSPEED 52
#define BAB_ABSMINSPEED 32

#define BAB_TUNEUP 1.0
#define BAB_TUNEDOWN 10.0

These are also the values that can be passed to cgminer on startup. The format was posted by kano in the cgminer thread...somewhere around pg 700 I believe.

[allinvain]

I think I may have gotten the hang of the bab-options startup variable. I'm now using the following for v1.2 h-card rigs

Code:

--bab-options 57:53:52:1:15

For v2.3 I use:

Code:

 --bab-options 53:53:51:1:15

Now it remains to be seen if for the long term the pool side performance matches that of chainminer.

[solarion]

You might try 57:54:54:2:15 on v2 cards and see what you get.

[allinvain]

Cool, thanks for the tip. I shall give it a go.

Here is a quote from kano:

The BaB driver with 7 boards uses less than 10% CPU on RPI Arch - and for my 7 BA BaB boards, mines at over 270GH/s
It seems to be limited to 2 boards per SPI channel. More tends to get all sorts of errors.
Will look into resolving that ... one day.

Kind of a bummer Most of my rigs have more than 2 boards per SPI channel so :\ yeah..

After a few minutes of running with the bab-options set on my v1.2 rigs it still seems that performance is not consistently equivalent to that of chainminer. That may have something to do with the quote from kano above.

Another thing is I'm not sure if cgminer turns off dead or "zombie" chips like I would when manually editing the chainminer best.cnf file. By zombie chips I mean those that no matter what always hash at a pitifully low hashrate (0.05 to 0.10).

[solarion]

Cool, thanks for the tip. I shall give it a go.

Here is a quote from kano:

The BaB driver with 7 boards uses less than 10% CPU on RPI Arch - and for my 7 BA BaB boards, mines at over 270GH/s
It seems to be limited to 2 boards per SPI channel. More tends to get all sorts of errors.
Will look into resolving that ... one day.

Kind of a bummer Most of my rigs have more than 2 boards per SPI channel so :\ yeah..

After a few minutes of running with the bab-options set on my v1.2 rigs it still seems that performance is not consistently equivalent to that of chainminer. That may have something to do with the quote from kano above.

Another thing is I'm not sure if cgminer turns off dead or "zombie" chips like I would when manually editing the chainminer best.cnf file. By zombie chips I mean those that no matter what always hash at a pitifully low hashrate (0.05 to 0.10).

It does shut them down. Check the driver for BAB_BAD_DEAD. This is set to BAB_BAD_MIN * 2 by default. I have cgminer running on a full rig.

The display tells you exactly what's going on with your rig:

0: BaB 0      : 4.16.256 B:034 D:000

BaB 0 4(banks)16(cards)256(chips)34(bad_min)0(disabled)

Here's a very naughty rig:

0: BaB 0       : 4.13.200 B:008 D:025

Cgminer doesn't seem to like the cards set to .85v. The same cards freak out bfgminer.

You can also decrease the time necessary for testing by changing the history setting to something like 120(s) from the default 300(s).

[allinvain]

All my v1.2 h-cards are overclocked so maybe cgminer does not like that. The v2.3 is not overclocked by me but it comes out of the box pretty much pushed to the limits (ie the adjustable voltage pot is aggressively tuned already). I dunno, I will wait until the next release of cgminer and see if kano/ckolivas make any improvements. I said it before and I will say it again, I wish cgminer/bfgminer had a chip table that allowed me to manually set which chips I want to be completely turned off or tuned down from the start.

[JakeTri]

All my v1.2 h-cards are overclocked so maybe cgminer does not like that. The v2.3 is not overclocked by me but it comes out of the box pretty much pushed to the limits (ie the adjustable voltage pot is aggressively tuned already). I dunno, I will wait until the next release of cgminer and see if kano/ckolivas make any improvements. I said it before and I will say it again, I wish cgminer/bfgminer had a chip table that allowed me to manually set which chips I want to be completely turned off or tuned down from the start.

bfgminer already support table with per chip start value.

Here is part of my bfgminer config file that I use on my system where I have about 14 bad chips and I want them to start very low (at 32) but everything else to start at 56. If you want you can set start value for every single chip (like on chainminer).

Code:

"scan-serial" : [ "bfsb:auto" ],
"set-device" : [
        "bfsb:osc6_bits=56",
        "bfsb0av:osc6_bits=32",
        "bfsb0be:osc6_bits=32",
        "bfsb0bi:osc6_bits=32",
        "bfsb0cj:osc6_bits=32",
        "bfsb1ar:osc6_bits=32",
        "bfsb1aw:osc6_bits=32",
        "bfsb1bn:osc6_bits=32",
        "bfsb2ag:osc6_bits=32",
        "bfsb2av:osc6_bits=32",
        "bfsb2ay:osc6_bits=32",
        "bfsb2ch:osc6_bits=32",
        "bfsb3ad:osc6_bits=32",
        "bfsb3bn:osc6_bits=32",
        "bfsb3cb:osc6_bits=32"
]

[allinvain]

All my v1.2 h-cards are overclocked so maybe cgminer does not like that. The v2.3 is not overclocked by me but it comes out of the box pretty much pushed to the limits (ie the adjustable voltage pot is aggressively tuned already). I dunno, I will wait until the next release of cgminer and see if kano/ckolivas make any improvements. I said it before and I will say it again, I wish cgminer/bfgminer had a chip table that allowed me to manually set which chips I want to be completely turned off or tuned down from the start.

bfgminer already support table with per chip start value.

Here is part of my bfgminer config file that I use on my system where I have about 14 bad chips and I want them to start very low (at 32) but everything else to start at 56. If you want you can set start value for every single chip (like on chainminer).

Code:

"scan-serial" : [ "bfsb:auto" ],
"set-device" : [
        "bfsb:osc6_bits=56",
        "bfsb0av:osc6_bits=32",
        "bfsb0be:osc6_bits=32",
        "bfsb0bi:osc6_bits=32",
        "bfsb0cj:osc6_bits=32",
        "bfsb1ar:osc6_bits=32",
        "bfsb1aw:osc6_bits=32",
        "bfsb1bn:osc6_bits=32",
        "bfsb2ag:osc6_bits=32",
        "bfsb2av:osc6_bits=32",
        "bfsb2ay:osc6_bits=32",
        "bfsb2ch:osc6_bits=32",
        "bfsb3ad:osc6_bits=32",
        "bfsb3bn:osc6_bits=32",
        "bfsb3cb:osc6_bits=32"
]

How do you identify the chips? I'm assuming the number after "bfsb" is the bank number but the rest of the characters are? Is there some logic to it.

[JakeTri]

All my v1.2 h-cards are overclocked so maybe cgminer does not like that. The v2.3 is not overclocked by me but it comes out of the box pretty much pushed to the limits (ie the adjustable voltage pot is aggressively tuned already). I dunno, I will wait until the next release of cgminer and see if kano/ckolivas make any improvements. I said it before and I will say it again, I wish cgminer/bfgminer had a chip table that allowed me to manually set which chips I want to be completely turned off or tuned down from the start.

bfgminer already support table with per chip start value.

Here is part of my bfgminer config file that I use on my system where I have about 14 bad chips and I want them to start very low (at 32) but everything else to start at 56. If you want you can set start value for every single chip (like on chainminer).

Code:

"scan-serial" : [ "bfsb:auto" ],
"set-device" : [
        "bfsb:osc6_bits=56",
        "bfsb0av:osc6_bits=32",
        "bfsb0be:osc6_bits=32",
        "bfsb0bi:osc6_bits=32",
        "bfsb0cj:osc6_bits=32",
        "bfsb1ar:osc6_bits=32",
        "bfsb1aw:osc6_bits=32",
        "bfsb1bn:osc6_bits=32",
        "bfsb2ag:osc6_bits=32",
        "bfsb2av:osc6_bits=32",
        "bfsb2ay:osc6_bits=32",
        "bfsb2ch:osc6_bits=32",
        "bfsb3ad:osc6_bits=32",
        "bfsb3bn:osc6_bits=32",
        "bfsb3cb:osc6_bits=32"
]

How do you identify the chips? I'm assuming the number after "bfsb" is the bank number but the rest of the characters are? Is there some logic to it.

Yes your are right, the number after bfsb is the bank number (0 to 3) the next 2 letters identify the chip in the bank (64 chips per bank - first chip is "aa" follow by "ab", "ac" ... then "az", "ba" ... and so on until "cl").

[Taugeran]

posted an RMA request for 3 h-cards. just a heads up MBP 

[Lloydimiller4]

I've got 8 Bitfury ASIC chips that I don't want/need. I will send them to anyone who wants them if they cover shipping costs. PM me.