HashFast BabyJet users thread

[tacotime]

What HW revision you got?

1.1

cgminer 4.0.0 still crashes and can't hotplug itself back in, so I went back to 3.11.0

[-ck]

What HW revision you got?

1.1

cgminer 4.0.0 still crashes and can't hotplug itself back in, so I went back to 3.11.0

Yes there was a crash in 4.0 that was fixed afterwards in git. The bug is actually there in earlier versions as well but it's harder to trip.

EDIT: I'll be releasing a new version tonight 4.0.1 with a few more improvements for hfa devices.

[tacotime]

Big problem I'm seeing with this new firmware is that it no longer automatically restarts the unit by hotplugging once it dies from the internal watchdog on 3.11.0... shoot.  Messing with 4.0.0 again now.

edit: Do not update this if you have a rev 1.1 board, the newer firmware is less stable at higher clocks!!

ckolivas, please pass me older firmware with the watchdog if you have it, this new firmware is super unstable for me

[DoogieHouser]

What HW revision you got?

1.1

cgminer 4.0.0 still crashes and can't hotplug itself back in, so I went back to 3.11.0

Q: How can you tell which hardware rev you've got?

Very non portable code (not mine), minimal instructions, comes with all attendant warnings blah blah, but here if you're brave:
http://ck.kolivas.org/apps/cgminer/temp/ckhf-140224.tar.gz

Since my Ubuntu installation is fairly new, I went ahead and added the dependencies mentioned in firmware_update.py, as follows:

Code:

#!/bin/bash
# pre-setup.sh - Run before setup.sh
# 
sudo apt-get install libusb-1.0-0-dev
sudo apt-get install python-usb
sudo apt-get install python-pip
sudo pip install --upgrade pyusb

Output from firmware_update.py

Code:

confirm is  False
FIRMWARE_DIR is  .
Traceback (most recent call last):
  File "./firmware_update.py", line 62, in <module>
    DFU_PROGRAMMER=shutil.which("dfu-programmer")
AttributeError: 'module' object has no attribute 'which'

[DoogieHouser]

[OT] Mt. Gox is off-line.  BTC prices are at a three-month low...

[-ck]

ckolivas, please pass me older firmware with the watchdog if you have it, this new firmware is super unstable for me

This was the 0.3 release candidate:
http://ck.kolivas.org/apps/cgminer/temp/uc3.cropped.hfu
Don't assume any of these downloads will remain online long term.

I'm currently trying to thrash out with them and help a 0.4 actually be released. We're looking at a release candidate for that one now.

[tacotime]

Rolled back and seems to be working okay again, thanks

With the other firmware it ran for 10 or so minutes okay and then kept detecting errors and downclocking the unit, then finally when it hit ~530 MHz.  At that point it just kept resetting it every 30 seconds or so, it was really strange.  That was with 4.0.0.  With 3.11.0 it would run very stable for a while and then wouldn't be able to recover from crashes at all (15s of failing to give golden nonces or whatever).  It was just keep going down until it his 0 MH/s and sit there.

This new firmware is also seemingly slower than what it was shipped with (v0.2?) at the same clocks; was getting ~445 GH/s per unit at the pool, now I'm getting only ~410 GH/s.  I'll let it run overnight and see if it's just variance.  Looking at the power meter, they're drawing exactly the same amount as before.

[ninjarobot]

I'm currently trying to thrash out with them and help a 0.4 actually be released. We're looking at a release candidate for that one now.

Thanks ckolivas, your help is invaluable. Much appreciated.

[DoogieHouser]

I'm currently trying to thrash out with them and help a 0.4 actually be released. We're looking at a release candidate for that one now.

Thanks ckolivas, your help is invaluable. Much appreciated.

+1 Thanks, ckolivas!

When I first started using cgminer 4.0.0, the clock rate dropped from 612 MHz to 538 MHz in less than two hours. The BabyJet would disappear, cgminer would lower the clock rate, and reconnect.

Yesterday, I ran my BabyJet with bfgminer 3.10.0, to see how the hashrate compared to cgminer 4.0.0. When bfgminer was connected to the BabyJet, it ran about 5 GH/s faster, but I think it is due to the fact that cgminer is hotplugging the miner every 20 - 30 minutes. However, bfgminer declares the BabyJet dead every 6 - 12 hours, and the only way to reconnect is to restart bfgminer. This requires constant monitoring.

Anyway, today I am pleased to see that after four hours, cgminer is still running at 600 MHz, and hashing around 400 GH/s, according to Eligius (bfgminer hashed 380 - 390 GH/s)

Code:

 cgminer version 4.0.0 - Started: [2014-02-24 23:10:06]
--------------------------------------------------------------------------------------------------
 (5s):1.067T (avg):794.4Gh/s | A:1518537  R:2064  HW:5360  WU:11050.7/m
 ST: 1  SS: 47  NB: 33  LW: 1646160  GF: 0  RF: 0
 Connected to stratum.mining.eligius.st diff 256 with stratum as user 
 Block: 11fee3d5...  Diff:3.13G  Started: [03:35:41]  Best share: 3.92M
--------------------------------------------------------------------------------------------------
 [U]SB device management [P]ool management [S]ettings [D]isplay options [Q]uit
 020: HFB 20: 600MHz  77C  33% 0.79V  | 1.026T/842.4Gh/s | A: 27648 R:  0 HW:114 WU:11722.2/m
--------------------------------------------------------------------------------------------------
 [2014-02-25 01:00:49] HFB 8 failure, disabling!
 [2014-02-25 01:08:37] HFB 9 failure, disabling!
 [2014-02-25 01:24:12] HFB 10 failure, disabling!
 [2014-02-25 01:40:58] HFB 11 failure, disabling!
 [2014-02-25 01:58:18] HFB 12 failure, disabling!
 [2014-02-25 02:01:07] HFB 13 failure, disabling!
 [2014-02-25 02:15:29] HFB 14 failure, disabling!
 [2014-02-25 02:29:59] HFB 15 failure, disabling!
 [2014-02-25 03:03:18] HFB 16 failure, disabling!
 [2014-02-25 03:07:29] HFB 17 failure, disabling!
 [2014-02-25 03:28:11] HFB 18: Failed to reset after hash failure, disabling
 [2014-02-25 03:28:11] HFB 18 failure, disabling!
 [2014-02-25 03:36:00] HFB 19 failure, disabling!

[-ck]

Great, I'm really hoping they actually do release a firmware soon this time, and I'm trying to use 4.0.1 as a tag they can use specifically for all its hashfast related changes, improvements and bugfixes. I added some important ones just an hour ago. Here's a preview from the current git manual (all this is available now if you build from git with the newer firmware, new in bold):

Hashfast devices

--hfa-hash-clock <arg> Set hashfast clock speed (default: 550)

This will change the initialisation clock speed on all attached hfa devices.
Note that if instability is detected by cgminer and the device has to undergo
a reset, cgminer will lower the clockspeed on resetting it each time till the
value returns to the default of 550.

--hfa-fail-drop <arg> Set how many MHz to drop clockspeed each failure on an overlocked hashfast device (default: 10)

If you overclock your hashfast device with --hfa-hash-clock and cgminer detects
it failing to return hashes, it will restart it at a lower clock speed if
possible. Changing this value will allow you to choose how much it will lower
the clock speed or to disable this function entirely.

--hfa-fan <arg>     Set fanspeed percentage for hashfast, single value or range (default: 10-85)

This changes the range of fanspeeds used on hashfast devices with firmware that
supports it. Note that the fanspeed will dynamically change to try and maintain
a target temperature with --hfa-temp-target but if the target temperature is
disabled, the fanspeed will remain static.
eg:
--hfa-fan 25-100

--hfa-temp-overheat <arg> Set the hashfast overheat throttling temperature (default: 95)

Cgminer will temporarily stop sending hashfast devices work once this
temperature is reached. Note that with the water cooling in these devices,
temperature recovery is likely to be very quick and the device will start
hashing again after only a very brief period.

--hfa-temp-target <arg> Set the hashfast target temperature (0 to disable) (default: 88)

On hashfast devices with firmware that supports dynamic fanspeed and die speeds,
cgminer will try to maintain temperature according to this target by adjusting
fanspeed and then if need be, throttle speeds on a die-by-die basis. Disabling
this feature will leave a constant fanspeed and die speed but will not disable
the temp-overheat feature.

--hfa-name <arg>    Set a unique name for a single hashfast device specified with --usb or the first device found

This command allows you to specify the unique name stored in nvram on a single
hashfast device. This name can be queried from the API stats command and comes
up as "op name". Discrete names are used by cgminer to try to maintain settings
across restarts, unplugs/hotplugs and so on. If this command is used by itself,
the name will be given to the first hashfast device it encounters and then
cgminer will proceed to go back to regular mining. If you have multiple devices,
it is best to discretely choose the device you wish to use with the --usb
command. For example
'lsusb' on linux shows the following devices (297c:0001 is a hfa device):
 Bus 001 Device 079: ID 297c:0001
 Bus 004 Device 042: ID 297c:0001
If you wished to name the second device Slug you would add the commands:
 --hfa-name Slug --usb 4:42

[storm2k5]

Q: How can you tell which hardware rev you've got?

There is a sticker on the board. I think CGMiner debug log also tells you HW Rev (also firmware rev btw)

[DoogieHouser]

Q: How can you tell which hardware rev you've got?

There is a sticker on the board. I think CGMiner debug log also tells you HW Rev (also firmware rev btw)

As I suspected, the HW rev is 1.1 (mine shipped on January 28th)

cgminer 4.0.0 will run for a few hours @ 600 MHz (81 C), then a few hours at 575 MHz (78 C), then 555, etc. When it drops below 550, I just restart cgminer and repeat the cycle. It beats bfgminer getting stuck in an endless loop after it declare the BabyJet dead. 

[storm2k5]

Q: How can you tell which hardware rev you've got?

There is a sticker on the board. I think CGMiner debug log also tells you HW Rev (also firmware rev btw)

As I suspected, the HW rev is 1.1 (mine shipped on January 28th)

cgminer 4.0.0 will run for a few hours @ 600 MHz (81 C), then a few hours at 575 MHz (78 C), then 555, etc. When it drops below 550, I just restart cgminer and repeat the cycle. It beats bfgminer getting stuck in an endless loop after it declare the BabyJet dead. 

--hfa-fail-drop <arg> Set how many MHz to drop clockspeed each failure on an overlocked hashfast device (default: 10)

Did you try to set that to 0?

[CurcO]

So the FW .03 is way better at OC  than the Candidate release 0.4 however both are a step in the right direction ... I now get very few errors when I OC above 650 ,  , thx Ckolivas

[edgie13]

So the FW .03 is way better at OC  than the Candidate release 0.4 however both are a step in the right direction ... I now get very few errors when I OC above 650 ,  , thx Ckolivas

What gh/s are you getting at the pool when OCed above 650?  Thanks.

[CurcO]

650 = 450 gh/s
687 = 480 gh/s ( the best I get)
700 = 460 (I see it getting Blabber out of 2 dies ) which causes it to not work efficiently

[CurcO]

Pool Eligius and also I have the same result with BTCGuild

[Taugeran]

I'm currently trying to thrash out with them and help a 0.4 actually be released. We're looking at a release candidate for that one now.

Thanks ckolivas, your help is invaluable. Much appreciated.

+1 Thanks, ckolivas!

When I first started using cgminer 4.0.0, the clock rate dropped from 612 MHz to 538 MHz in less than two hours. The BabyJet would disappear, cgminer would lower the clock rate, and reconnect.

Yesterday, I ran my BabyJet with bfgminer 3.10.0, to see how the hashrate compared to cgminer 4.0.0. When bfgminer was connected to the BabyJet, it ran about 5 GH/s faster, but I think it is due to the fact that cgminer is hotplugging the miner every 20 - 30 minutes. However, bfgminer declares the BabyJet dead every 6 - 12 hours, and the only way to reconnect is to restart bfgminer. This requires constant monitoring.

Anyway, today I am pleased to see that after four hours, cgminer is still running at 600 MHz, and hashing around 400 GH/s, according to Eligius (bfgminer hashed 380 - 390 GH/s)

Code:

 cgminer version 4.0.0 - Started: [2014-02-24 23:10:06]
--------------------------------------------------------------------------------------------------
 (5s):1.067T (avg):794.4Gh/s | A:1518537  R:2064  HW:5360  WU:11050.7/m
 ST: 1  SS: 47  NB: 33  LW: 1646160  GF: 0  RF: 0
 Connected to stratum.mining.eligius.st diff 256 with stratum as user 
 Block: 11fee3d5...  Diff:3.13G  Started: [03:35:41]  Best share: 3.92M
--------------------------------------------------------------------------------------------------
 [U]SB device management [P]ool management [S]ettings [D]isplay options [Q]uit
 020: HFB 20: 600MHz  77C  33% 0.79V  | 1.026T/842.4Gh/s | A: 27648 R:  0 HW:114 WU:11722.2/m
--------------------------------------------------------------------------------------------------
 [2014-02-25 01:00:49] HFB 8 failure, disabling!
 [2014-02-25 01:08:37] HFB 9 failure, disabling!
 [2014-02-25 01:24:12] HFB 10 failure, disabling!
 [2014-02-25 01:40:58] HFB 11 failure, disabling!
 [2014-02-25 01:58:18] HFB 12 failure, disabling!
 [2014-02-25 02:01:07] HFB 13 failure, disabling!
 [2014-02-25 02:15:29] HFB 14 failure, disabling!
 [2014-02-25 02:29:59] HFB 15 failure, disabling!
 [2014-02-25 03:03:18] HFB 16 failure, disabling!
 [2014-02-25 03:07:29] HFB 17 failure, disabling!
 [2014-02-25 03:28:11] HFB 18: Failed to reset after hash failure, disabling
 [2014-02-25 03:28:11] HFB 18 failure, disabling!
 [2014-02-25 03:36:00] HFB 19 failure, disabling!

You can use bfgminer with --cmd-dead <cmd here> to restart bfgminer when it dies

[storm2k5]

650 = 450 gh/s
687 = 480 gh/s ( the best I get)
700 = 460 (I see it getting Blabber out of 2 dies ) which causes it to not work efficiently

Interesting, I also got my best OC at 687.

[CurcO]

650 = 450 gh/s
687 = 480 gh/s ( the best I get)
700 = 460 (I see it getting Blabber out of 2 dies ) which causes it to not work efficiently

Interesting, I also got my best OC at 687.

Strom2k5 What rev ?, I'm on 1.1