HashFast BabyJet users thread

[mgio]

You either need to change clock speeds, either OC or underclock use in cgminer "--hfa-hash-clock 600", I see from ex that the die's like to run over the 70-80 C , from your post you have one core in in the 51 C/.82V which tells me that core that is not working also you can see that the V is  high as to the nominal output in V is .79..

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

CurcO thanks for your answer.

I found that
-using HF image on RPI with cgminer 3.09 -> cgminer says 490ghps
-using cgminer 3.12 on windows -> cgminer says 250ghps
-pool says 250ghps

I tried over/underclocking it in the range from 500-600mhz, underclocking makes it slower, overclocking makes it faster (max average I saw was 300ghps - far away from the 400+ other are getting)

Could it be an issue with PSU / connectors?

What is your HW count (hardware errors, its on the top line of cgminer output)? You probably have the same problem I do. Which is, cgminer things its hashing fine but its really gettings tons of errors due to some defective cores. The reason why the temps are lower is probably because much of the chip isn't actually hashing due to errors. Also what is your WU rate?

In cgminer, my bj shows 400+ GH/s (at stock frequency) but only 230 GH/s in eligius. As of now, there is no way to fix this. Perhaps a firmware update might fix it. But if you manage to fix it, let me know.

[1715019004]

1715019004

[storm2k5]

mgio,

well that was my first thought so I looked at HW very early on, it doesn't seem excessively high:

Code:

A:8704 R:0 HW:17 WU:4175.2/m

after a couple mins @585mhz.

[ImI]

is it possible to do clock settings per device?

i have 5 BJ running at one RPI at the moment and would like to clock each one seperate.

[storm2k5]

What Pool ? , I found that on P2pools the like coinex.pw it preforms at that range, gives a lot of errors from Pool submit errors to watchdog errors, so I have to stick to a BTC pool like , slush, Eligius , or similar. Don't know why the miner preforms slower , hmm  Phil might know why ( aka the HF Engineer that has been an excellent source for help).

I'm currently trying eligius and I'm getting around the same ghps there (~250ghps) so it's probably not the pools fault.
I also tried the 2nd set of PCI-E connectors from the PSU, no difference.

My board shows "REV 1.2" and cgminer 3.12 says "Update hashfast firmware to set fan speed" at start up. Is it possible I don't have the newest firmware?

I'm seriously questioning the cgminer release from hashfast. WU and ghps shows doubled when I use it (compared to the 3.12 on windows)
I'm wondering if they didn't just put
ghps = 2*ghps;
just to make it look good (?)

[CurcO]

wow Rev 1.2 , I'm on Rev 1.1  make you wonder if this is PCB related . Still a word from Phil would be great.

[storm2k5]

wow Rev 1.2 , I'm on Rev 1.1  make you wonder if this is PCB related . Still a word from Phil would be great.

Well, it's not like 1.2 brought me luck so far

Here's a screen shot, maybe somebody can spot whats wrong:


I'm a bit puzzled by the accepted share %age (~50%) Can somebody tell me why that value isn't higher? (something like total - rejected - HW)

[Micky25]

I think there's something wrong with your cooling system. Can you check if all screws on the cooling head are tight fit?
If you remove the top bezel the radiator blows off better.

[storm2k5]

I think there's something wrong with your cooling system. Can you check if all screws on the cooling head are tight fit?
If you remove the top bezel the radiator blows off better.

I already did that I also checked and reapplied thermal paste and did a visual check of the cores (nothing chipped off)
Also, all the fans are blowing in the correct direction. Temps didn't change after all that.

Really, I did read this entire thread beforehand and tried everything I could think of and nothing I did seem to change any behavior.
Also, the fact that 2 of my cores show 50-60° at 0.82V leads me to believe that they are not working at all or at a very very low rate.

Also I think it's weird I'm not seeing anything that points to a hardware problem in log.

[Micky25]

if they don't work at all, they maybe don't show up in a log. 84° on one and 60° on the other looks like somethings broken.

[storm2k5]

if they don't work at all, they maybe don't show up in a log. 84° on one and 60° on the other looks like somethings broken.

I'm starting to think so too...

[CurcO]

Makes me think that we all need the new Firmware from HF which has been announced to be "delivered soon" , Kinda depressing since Cgminer 3.12.1 has the code for using the Firmware however we wait and wait, its been  7 days and counting

[storm2k5]

Well, hashfast has a proven track record of delivering stuff on time, no?

Does anybody know what the 2 buttons on the board are supposed to be for? I saw posts mentioning to press them, but not really what they do.
Reset?

[dbbit]

only good exp. with windows and 3.12 since days and 3.12.1 since today as well (way better than with the RPi). Many thanks to you too.

I can't say whether it's actually working better. It's different. Instead of getting the familiar:


 [2014-02-04 09:45:09] HFA 0 NOTICE: ######################### WARNING: Work Watchdog Reboot Imminent!
 [2014-02-04 09:45:11] HFA 0 HFGetHeader usb read err:(-99) LIBUSB_ERROR_OTHER
 [2014-02-04 09:45:11] HFA 0 attempted reset got err:(-5) LIBUSB_ERROR_NOT_FOUND
 [2014-02-04 09:45:11] HFA 0: device disappeared, disabling
 [2014-02-04 09:45:11] HFA 0 failure, disabling!
 [2014-02-04 09:45:11] HFA 0: hfa_send_frame: USB Send error, ret -4 amount 0 vs. tx_length 8
 [2014-02-04 09:45:17] Hotplug: Hashfast added HFA 1



Which we've all come to know and love, I now get pages and pages of the following spew on reset:

attempted reset got err:(0) LIBUSB_SUCCESS
HFGetHeader usb read err:(-1) LIBUSB_ERROR_IO
attempted reset got err:(0) LIBUSB_SUCCESS
HFGetHeader usb read err:(-1) LIBUSB_ERROR_IO
attempted reset got err:(0) LIBUSB_SUCCESS
HFGetHeader usb read err:(-1) LIBUSB_ERROR_IO
attempted reset got err:(0) LIBUSB_SUCCESS
...



I don't think it resets any less frequently, and because of the long spew, cgwatcher takes a little longer to reset it in fact.

There's probably no way around the firmware watchdog, it's just the cgminer now behaves differently

I take that back. It's definitely worse. Because of the very long recovery time after failure, my cgminer 3.12 Hashrate is significantly worse than 3.11. I used to get 410ghs - over the last 12 hours I averaged 350gh/s, and it's all because of very long and DEEP low spikes (down to 45gh/s) in Eligius. On 3.11, the deepest a spike went down was around 290gh/s.

[-ck]

Meh I screwed something up on 3.12.1 that would make cgminer just go idle eventually, so I've posted a hotfix 3.12.23.12.3 release.

[mgio]

mgio,

well that was my first thought so I looked at HW very early on, it doesn't seem excessively high:

Code:

A:8704 R:0 HW:17 WU:4175.2/m

after a couple mins @585mhz.

That looks very low. After a few minuntes my errors are up to the hundreds of thousands.
The WU number is low, though, which makes sense since that is directly proportional to your hashrate. Maybe you have some defective cores that aren't spewing out errors but just aren't working.

[dbbit]

Meh I screwed something up on 3.12.1 that would make cgminer just go idle eventually, so I've posted a hotfix 3.12.2 release.

Thanks! I still get an insanely long reset time though (minutes instead of seconds), while cgminer 3.12.2 is contemplating pages of these messages:


 [2014-02-07 14:04:02] HFB 0 attempted reset got err:(0) LIBUSB_SUCCESS
 [2014-02-07 14:04:02] HFB 0 HFGetHeader usb read err:(-1) LIBUSB_ERROR_IO
 [2014-02-07 14:04:03] HFB 0 attempted reset got err:(0) LIBUSB_SUCCESS
 [2014-02-07 14:04:03] HFB 0 HFGetHeader usb read err:(-1) LIBUSB_ERROR_IO
 [2014-02-07 14:04:03] HFB 0 attempted reset got err:(0) LIBUSB_SUCCESS
 [2014-02-07 14:04:03] HFB 0 HFGetHeader usb read err:(-1) LIBUSB_ERROR_IO
 [2014-02-07 14:04:03] HFB 0 attempted reset got err:(0) LIBUSB_SUCCESS
 [2014-02-07 14:04:03] HFB 0 HFGetHeader usb read err:(-1) LIBUSB_ERROR_IO
 [2014-02-07 14:04:03] HFB 0 attempted reset got err:(0) LIBUSB_SUCCESS
 [2014-02-07 14:04:03] HFB 0 HFGetHeader usb read err:(-1) LIBUSB_ERROR_IO
 [2014-02-07 14:04:03] HFB 0 attempted reset got err:(0) LIBUSB_SUCCESS



This is the usage difference over 7 hours:

[yrral]

I've finally posted an official version that is designed to make the most of the new firmware coming up, cgminer 3.12.1

Announce and details here:
https://bitcointalk.org/index.php?topic=28402.msg4989440#msg4989440

This should also fix the windows reliability issues for those poor souls mining with their BlowJobs on windows.

ckolivas: I'm assuming your units have the beta HF firmware flashed on them? It seems like per-die frequency control could be very useful. How much faster speeds are you getting with the new firmware + cgminer per-die control?

[-ck]

Meh I screwed something up on 3.12.1 that would make cgminer just go idle eventually, so I've posted a hotfix 3.12.2 release.

Thanks! I still get an insanely long reset time though (minutes instead of seconds), while cgminer 3.12.2 is contemplating pages of these messages:

I believe you are not on new firmware? I strongly advise people wait till they have new firmware as the new cgminer code is optimised around it and vice versa.

[-ck]

I've finally posted an official version that is designed to make the most of the new firmware coming up, cgminer 3.12.1

Announce and details here:
https://bitcointalk.org/index.php?topic=28402.msg4989440#msg4989440

This should also fix the windows reliability issues for those poor souls mining with their BlowJobs on windows.

ckolivas: I'm assuming your units have the beta HF firmware flashed on them? It seems like per-die frequency control could be very useful. How much faster speeds are you getting with the new firmware + cgminer per-die control?

I don't get any higher hashrates as a baseline - that's still dependent on the amount I overclock it and is basically unchanged. The difference is I can maintain much closer to my maximum hashrates when it's hot and it's much quieter and uses less power with the fans lower when it's cool. Previously I had to overclock it less because it was just too hot here. So on a hot day I get about 15% more hashrate now, but on a cool day it's the same as it was previously.

EDIT: To give you an idea of what I mean by hot, today it's going 40 degrees C.

[CurcO]

Meh I screwed something up on 3.12.1 that would make cgminer just go idle eventually, so I've posted a hotfix 3.12.2 release.

Thanks! I still get an insanely long reset time though (minutes instead of seconds), while cgminer 3.12.2 is contemplating pages of these messages:

I believe you are not on new firmware? I strongly advise people wait till they have new firmware as the new cgminer code is optimised around it and vice versa.

HI Ckolivas
That is all we can do . Still what Gh/s are you getting at the 600 clock range ?