Topic: HashFast BabyJet users thread - page 35. (Read 69024 times)

I don't know how to get a message to ckolivas, but I'm testing the current master branch of cgminer and one feature that was added is fan speed control (OP code 143).  However, I keep getting the error that OP_CODE 143 is unhandled.

Is it possible that I have an older revision of the board/firmware something that doesn't support controlling the fan speed using that op code?

How loud are they?

I was getting great performance when my 3 BJ's arrived. At least on two of them, there was one that seemed a bit flakey and seems to be getting worse. All 3 seem to be getting worse. One of them keeps shutting down and restarting grabbing a new ID each time. I posted a small capture from my monitor so that maybe if others have had this and fixed it they can help. This one that is flaky was delivered in poor condition, all but one screw was sliding around the inside of the box and 4 risers that prop the board up were also floating around. I though the board was damaged and it may be. Worst assembly I have ever seen and I used to build PC's. That point is mute if they all work but they don't.

Here is what I need help answering.
1. How do I get back to my 400+ GH performance. All three of these were pushing +-420GH.
2. Worse case scenario is how do I raise the clock speed to get up to the 400GH range? I was promised by Erin at Hashfast that it would not void the warranty but the delivery paperwork stated otherwise. I will have to deal with that warranty issue separately, I know.
3. I seem to be getting huge error rates, I think it is on the flaky board but not 100% sure that is the only place. 70% to 80% errors are common. Elgius reports I am only getting 900 to 950 GH/s AVG with 3 boards and I should be getting closer to 1200. Not good for profits. Any help would be appreciated. I hate to try and send a board back under warranty since I might be stuck for months. I still am waiting on my 3 upgrades, I would hat to be down to 2 processors if I can avoid it.

 [2014-02-05 10:15:06] HFA 21 HFHash usb write err:(-7) LIBUSB_ERROR_TIMEOUT                                                   
 [2014-02-05 10:15:06] HFA 21 attempted reset got err:(0) LIBUSB_SUCCESS                                                       
 [2014-02-05 10:15:07] Accepted 6b3cd65e Diff 611/512 HFA 1                                                                     
 [2014-02-05 10:15:08] HFA 21 HFHash usb write err:(-7) LIBUSB_ERROR_TIMEOUT                                                   
 [2014-02-05 10:15:08] HFA 21 HFGetHeader usb read err:(-4) LIBUSB_ERROR_NO_DEVICE                                             
 [2014-02-05 10:15:08] Accepted 4a23005d Diff 884/512 HFA 1                                                                     
 [2014-02-05 10:15:09] HFA 21 attempted reset got err:(-5) LIBUSB_ERROR_NOT_FOUND                                               
 [2014-02-05 10:15:10] Accepted 5c43a019 Diff 710/512 HFA 3                                                                     
 [2014-02-05 10:15:10] HFA 21: hfa_send_frame: USB Send error, ret -5 amount 64 vs. tx_length 64                               
 [2014-02-05 10:15:10] HFA21: send_packet: OP_USB_INIT USB Send error, ret -4 amount 0 vs. length 8                             
 [2014-02-05 10:15:10] HFA 21: Failed to reset after write failure, disabling                                                   
 [2014-02-05 10:15:11] HFA 21 failure, disabling!                                                                               
 [2014-02-05 10:15:11] HFA 21: hfa_send_frame: USB Send error, ret -4 amount 0 vs. tx_length 8                                 
 [2014-02-05 10:15:15] Accepted 1f29f70a Diff 2.1K/512 HFA 1                                                                   
 [2014-02-05 10:15:17] Accepted 1537e75f Diff 3.09K/512 HFA 1                                                                   
 [2014-02-05 10:15:21] Accepted 5bfd3c83 Diff 182K/512 HFA 3                                                                   
 [2014-02-05 10:15:22] Hotplug: Hashfast added HFA 22                                                                           
 [2014-02-05 10:15:25] Accepted 61ee0ec8 Diff 669/512 HFA 22                                                                   
 [2014-02-05 10:15:27] Accepted 7d126b85 Diff 524/512 HFA 22       

Any Windows binaries available?

No issues here with errors, there were connectivity problems with my one but since that's been fixed I'm getting ~0.2% errors on both.

48h stable on 2x Batch 2 BJs on Windows.  The internal watcher turns it off if there's a problem, cgminer 3.11.0 catches it and auto-hotplugs it back in if there is an issue.  Takes about 10s.

Additionally they no longer reboot themselves very much -- starting to wonder if there's a burn in period for the hardware, and then it works better after that.

Just curious, what core clock are you running this at? I ran mine at default (550) for a day and it got about 400GH/s, 0.37% rejects, and 1.83% errors and showed 360GH/s on eligius. Overnight I started it at 560 and it shows 412GH/s, 0.36% rejects, and 9.26% errors with 388GH/s showing on eligius. Should I be worried about 9.26% error rate? They run at 80C/80C/70C/72C right now.

Anybody from Batch 1 received the upgrade kit ? Seems that BabyJets for Batch 2 are already being shipped.

Awesome, Glad to hear it!  Is the original SD card we shipped actually a "no name" Micro SD inside an adapter with the Raspberry Pi logo on it?  We got those specifically because they are "official" RPI cards, so they'd be the most likely to work well, but it's turning out that they stink.  We'll test some different ones for the next batch.

BTW, any time you build a new image, the first time it boots, it makes a new bitcoin wallet (viewable on the "wallet" page of the web UI), and begins mining with that wallet.  Be sure if it made any BTC that you don't forget to collect it!  If you make a backup from the settings page, the wallet is also backed up and restored.  If you want to change to a new wallet or mining username, that's done on the "pools" page of the web UI.  If you ever restore from a previous backup, it puts all your original settings in, so it's a good idea to make a backup once you get things dialed in like you want.  (In case an SD card dies or something.)

-Phil

I just sent the email to support again with the subject. Thanks!

Hi Phil,
It seems that it is the issue of the SD card you shipped. I replaced that card with my sandisk which is working now.
I think the SD card you provided is too thin so that the pins do not contact properly in the slot in the RB Pi. My sandisk card is much thicker and after I plug it in, I can feel solid contact. Anyway, thank you for your help. I can see it's hashing at 415G/s but for your default BTC address, will switch to my address and see. 

Hi Phil,
After reload I can see 94meg partition with above files(But no config.txt~ and cmdline.txte). Still does not boot. Any Idea?

We've shipped tons of these things, and I have yet to see one with a bad NIC.  There have been plenty of bad SD cards though.  Note that a bad SD image will fail to initialize the NIC and there will be no ethernet lights or link.

Follow the reload instructions and then be sure you can see a 94meg partition with the following files:

If not, see if you can grab another SD card (2G min) and try the image there.   Seems like some people have had difficulty installing the image, so be sure to uncompress the image first and then use the proper method to write the card.  Tech support can send you one if you like, simply send an email with the subject "Replacement SD card request" as the subject.

-Phil

I made it a point to get in our the support queue now.  Send an email (do not call, this is not working well), and I'll see what I can do to make sure you get taken care of.

We also just hired new people specifically to deal with support, so please try again and be patient.  Most of the support queue is clogged full of things such as questions about shipments, MPP, etc.  Please title your request "BJ only doing 220 GH" and I see if I can dig it out.

-Phil

Thank you Phil. Actually I did what the instruction says. The issue is that the LED indicator of the port on my switch does not even show the internet connection is every enabled on RB Pi. So I think it has no chance to download any uploads. Are you sure the reload can fix the NIC issue? Anyway, I am trying, will update soon. Thanks again!

Answer 1: Yes, we will push the firmware and software updates whenever they are ready.  If you do not want to accept them, you can uncheck the "Enable HashFast updates" box on the settings page of your RPI's web interface and then at your choosing perform a manual update.

Answer 2: We don't advise running that many units on only one RPI, it's likely a bit too much load for the little guy!

We are going to test the update mechanism to be sure it will update everything reliably and won't break anything, though I don't think we'll test any more than 3 systems on one RPI.  Worst-case is you might have to unplug some units and restart the RPI a few times with only a few units connected.

Our goal is to get you the most uptime possible, so we're going to tune the update process to be a smooth as possible and require no hassles if we can help it.

-Phil

That's what I advise for the time being.  We will be releasing an update utility as soon as possible for those not running on a RPI, but RPI users will be first to get the updates until that occurs.

-Phil

You need to run as root or give access to your "tie" login. Con has outlined this in his readme.

https://github.com/ckolivas/cgminer/blob/master/ASIC-README

You will not be able to receive any updates using the default version of MinePeon, and also you'll soon find it's relatively unreliable.  If it dies for any reason, it often fails to restart.  Our version keeps trying if something stops, and it has a RPI's hardware watchdog enabled.

-Phil