HashFast BabyJet users thread

[sillywhim]

For all the people here that are running on something other than the RPI's, Here's the source code for cgminer 3.9.0h2 (same version we're currently using on the RPI).  This version has somewhat correct hashrate reporting, and has a few other things, such as the per-die voltage and temperature readout.  It seems to be the most stable during our testing.  One of our top Engineers is currently working with Con Kolivas right now to get some of these things improved.  Thanks Con!

cgminer 3.9.0h2 source (can be complied on most Linux distros): http://setup.hashfast.com/cgminer-3.9.0h2.tar.gz

I'd love reports back to see if this improves your mining performance/stability.  Again; please ignore the strings of HW errors, this should not be a problem.

-Phil

can't we be a little more professional and give out the MD5? Asking too much? (yea, I'm getting frustrated, can you tell.)

[CurcO]

I just got my BJ... the wait is finally over and I can go to the Doc to get my stomach hernia check ... , I'm on batch 2 , currently Hash rate is 450 -460 running core at 600... rev on board is 1.1

 HFA 0: 73C/.79V 73C/.79V 66C/.79V 66C/.79V 450.9G/451.3Gh/s | A:61339 R:4 HW:582 WU:11494.3/m

[HF-Engineer]

Au Contraire.

I downloaded your minepeon raspi image as soon as I learnt of it:

MinePeon Version
0.2.4.3hf8
Miner Version
cgminer3.9.0h

This has without a doubt, the "1969" date/time upon bootup problem and the daemon in part "ntpd -g" is not correcting the date/time as it should. I said to heck with it and wrote a small perl script that manually setup the time properly upon boot (I am too lazy to go treking thru arch linux hunting for whatevers, howevers.)

ntpd -g should correct things, but it doesn't. and because it doesn't, cgminer won't run. and because cgminer won't run then of course baby jet won't make any "noise". Initially this all puzzled me like I said in my post and I spent money and RMA requests in my initial attempt to "fix" it.

I downloaded the image about two days ago and maybe something changed in the meantime? If you could download your image yourself, load it on a mem card and then boot up off it, you will experience the year "1969" error, and not the more common/expected year "1970" reset. And how come ntpd -g doesn't correct a thing? Dunno why, you tell me?

Maybe I missed it, but what is the MD5 for your image? Remote outside chance that it got corrupted on its way to me here in Hawaii...

Did you restore from a backup?  If so, this could be an issue.  Just go to the GUI and set the timezone.  If you do this, it will set it both for the web interface (PHP) and the Linux system TZ.  Before version 4, the system TZ was left unset.  (Stock MinePeon behavior)

Here's the MD5 hash for each type:

Code:

ff8139e711ab584f6ca4c4aa6bd4d5f1  hashfast-minepeon-1.0.img.bz2
3bc53fb621683d54a623678400e42a81  hashfast-minepeon-1.0.zip
7a608a094809d1e55f964ae01ddfb090  hashfast-minepeon-1.0.img

We had a problem in early final stage at both factories, where the initial load of the SD was either outright wrong (standard MinePeon without HF customizations), or someone pulled the SD card out of the duplicator before it was finished and corrupted the filesystem.  Be sure if burning the image on your SD under linux that the sync command completes before yanking your card.

Keep in mind, many people here are not linux-experienced and have never visited a command shell.  This is why we provide a customized version of MinePeon so it would be turn-key ready to roll.  Our beta test results showed that many people were having trouble determining the IP address of their MinePeon systems, so this is why we came up with the http://setup.hashfast.com/ page that redirects them to the local IP.

Please if you could, try setting the TZ in the GUI's settings page and see if that updates your system TZ properly.  If it doesn't I'd love some help debugging it!

Thanks!

-Phil

[machinationus]

and again a miner that fails on p2pool 20% rejected shares
anybody tried with cgminer 3.11 is this getting better performance?

I'm not seeing anything like these reject levels. Only when I first start p2pool and first connect the device. After a while diff rises, p2pool stops chewing up CPU and then it all calms down to very normal reject and DOA rates and good efficiency.

after 5 hours I still got >20% rejected shares on p2pool.
running cgminer 3.9 from the minepeon on rpi shipped with the bj

will give 3.12 or newer a shot on a linux host PC

maybe off topic but could it be the Flash Card?
I got 2 from Ebay both fake
Got 4 from Aliexpress all fake.
http://www.vconsole.com/Flash_Drive_Tester_v114.exe

[fubly]

snip

One of our top Engineers is currently working with Con Kolivas right now to get some of these things improved.  Thanks Con!

snip

-Phil

But not today, he is working today on fan speed!

Also somthing with the eligius pool is wrong. When I mine on eligius my cgminer shows hashrates 800 to 1 Th/s, on the pool I have only 440 Gh/s.
When I mine at ghash.io the pool and the cgminer is showing nearly the same hashrate of 440 to 500 Gh/s.

I´m running 3.11 and it works good. Now I want to compile your cgminer, but how?

Code:

config.status: error: cannot find input file: `Makefile.in'

[ninjarobot]

Came back from work today and noticed my BJ was dead again. *sigh*

I needed to hard-reset the Pi and hot-plug the USB cable before it came back. Take a look at my mining graphs and tell me I have a stable system.. (This is at normal clock speed)

I will give 3.11 another shot.

[tacotime]

For all the people here that are running on something other than the RPI's, Here's the source code for cgminer 3.9.0h2 (same version we're currently using on the RPI).  This version has somewhat correct hashrate reporting, and has a few other things, such as the per-die voltage and temperature readout.  It seems to be the most stable during our testing.  One of our top Engineers is currently working with Con Kolivas right now to get some of these things improved.  Thanks Con!

cgminer 3.9.0h2 source (can be complied on most Linux distros): http://setup.hashfast.com/cgminer-3.9.0h2.tar.gz

I'd love reports back to see if this improves your mining performance/stability.  Again; please ignore the strings of HW errors, this should not be a problem.

-Phil

Can we edit per die voltages in this version?

I'll make a note *not* to hotplug fans into the BJ when it's running too, as that caused a shutdown.  The third fan connector works fine, in any case.

[freddyfarnsworth]

Came back from work today and noticed my BJ was dead again. *sigh*

I needed to hard-reset the Pi and hot-plug the USB cable before it came back. Take a look at my mining graphs and tell me I have a stable system.. (This is at normal clock speed)

I will give 3.11 another shot.

Network provider is stable ? Dropped connection could spin it out - shutdown.
Just a variable no one mentioned yet.

DSL and wireless not so good for this stuff.

When I went to TWarner to ask about this, they asked "what are you doing" I told them 900k up 1500k down 24/7
They said it was allowed and not over or excessive. Some will cut you off if they see to much constant traffic.

[dbbit]

I found another minor bug (or may be the same one) on the 3.11 version of cgminer.

I'm on the Eligius pool - when the difficulty that the pool pushes down is 256, it will display double the hashrate. Once the difficulty goes up to 512, it will display the actual hashrate.

Not sure if this was fixed with the versions of cgminer that shows the actual hashrate at 256, or if we'll still see it halving the rate on higher difficulties?

[kikaha]

HashFast posts Raspberry Pi updated firmware on their blog.  I took a new SD card, followed their directions and pointed it back to my mining wallet.  After 1 hour, I cannot see any difference.  It would be better to be notified of new updates, and to have the choice of whether to take it or not, depending on what was changed.  This is what I do with Windows.  If it ain't broke, don't fix it!

http://hashfast.com/how-to-update-babyjets-raspberry-pi-sd-card-software/

We’ve updated the BabyJet’s Raspberry Pi SD card software to improve stability and hashing performance. Some BabyJets were shipped without this updated software.
 
Do you have the latest software?

If you connect to your MinePeon mining control panel’s web page and see the MinePeon version as “0.2.4.3hf8”, and your system is mining, you are running the correct and current version and do not need to perform any manual updates. This version is capable of receiving new updates automatically as soon as they are released. Be sure that you have not unchecked the “Enable Automatic Updates” in your settings tab of the mining control panel if you’d like to receive these updates.
If you have not seen a version number, are having difficulty getting your system working, or it seems to be running but you do not see it when you visit http://setup.hishfast.com/, you should follow the instructions below to get the correct current version of the SD card software image.
 
Raspberry Pi SD Card Update Instructions:

Please follow the instructions below to update your SD card yourself, it should only take a few minutes. Or, if you like, you can email us at [email protected] and we will mail you out a new SD card. Please include your order number.
1. If you are already running MinePeon, it’s important to first make a backup from the Settings tab (near the bottom). If you are unsure, and have not been able to log in to your control panel, you may skip this backup, and step #5.

2. Download the following SD card image:
Windows users: http://setup.hashfast.com/hashfast-minepeon-1.0.zip
Linux users: http://setup.hashfast.com/hashfast-minepeon-1.0.img.bz2

3. If running windows, we recommend the Win32DiskImager as a simple way to update your card: http://sourceforge.net/projects/win32diskimager/
This is faster and easier than other methods. Follow the steps in the Win32DiskImager documentation.
If you are running Linux, after downloading the image, you can simply type:
 bzcat hashfast-minepeon-1.0.img.bz2 | sudo dd bs=1M of=/dev/xxx && sync
(Where /dev/xxx is the device name of your SD card. If unsure, type “dmesg” after inserting your card.)

4. Re-install the SD card with the image in your Raspberry Pi. Verify you have followed all the setup instructions viewable on our quick-start web site at:
http://setup.hashfast.com/
Note that it may take up to 4 minutes or so to collect all the current updates and show up on the above web page.
Listen for the fans to start in your BabyJet, then you should be able to reload the above web site and find your system. If for some reason it you don’t see it report in after five minutes, re-verify you have followed the setup instructions including connection to a live internet router, and power-cycle the Raspberry Pi and try again.

5. Log into the web interface and restore your backed up MinePeon settings (if any). Note that the system will generate a new wallet when you first boot from the new SD image, and will begin mining using that wallet. It’s important to switch your mining settings using the “Pools” tab or restore your backup so that your mining proceeds end up in the right wallet!

If you don’t want your system checking in for updates with HashFast servers, you can disable this in the Settings tab, but we advise you to at least do it manually once in a while. We hope to have some new firmware and software soon. We also advise you to immediately set a password on MinePeon, especially if your machine is not behind a firewall.

We will be providing future updates automatically which we anticipate will increase the overall hashing performance of your system.

[HF-Engineer]

DEAD DEAD DEAD - this is what I see when I wake up this morning for the second day in a row, getting only about 12-18 hour uptime before my devices all go DEAD and cgminer does not restart itself, I have to manually restart.

I am having an issue with cgminer 3.12 on windows

Using 9 babyjets plugged into a 10 port usb hub, all are detected eventually, but it usually goes up into HFB 40 to HFB 50 so it takes about 4-5 disable/re-enable cycles per device on startup.

If I reboot cgminer, after the all DEAD status, then it works for just a few minutes before I start to see the miners drop again.

IDLE for more than 60 seconds - declaring SICK!
Attempting to restart

So hotplugging everything will give me another 12-18 hours (turn off and on USB hub), but this is crazy that I have to hard reboot so often.

I have the exact same issue with cgminer on windows. I had to switch back to the RPI to get reasonable uptime.

Windows cgminer gives a bit faster hashrate, but not worth it if it's down for hours a day.

There is a known problem with the USB stack on windows.  This is a cgminer known issue, which is why we recommend a linux-based mining solution and provide the RPI with every BJ.  The best you could do is make some sort of a script that restarts cgminer, or better yet windows itself, after mining stops or even just after 8 hours or so.

Hopefully once we get cgminer and the firnmware stable, we can look at possible windows solutions.  Windows in general is not a stable platform, which is why most servers on the internet don't use it.

-Phil

[HF-Engineer]

HashFast posts Raspberry Pi updated firmware on their blog.  I took a new SD card, followed their directions and pointed it back to my mining wallet.  After 1 hour, I cannot see any difference.  It would be better to be notified of new updates, and to have the choice of whether to take it or not, depending on what was changed.  This is what I do with Windows.  If it ain't broke, don't fix it!

I wanted them to do this based on the number of reports of the wrong versions, corrupted filesystems, etc.  This version has the firmware update capabilities built-in, and we are now testing new board firmware for release.  We need to make sure it's absolutely solid and that the automatic update procedure we'll push to your RPI's are not going to break anything.  If you are already running ok with our version of MinePeon (currently showing version 0.2.4.3hf8 or later), you DO NOT NEED TO DO ANYTHING!

If you are running anything else, you will not get the updates!  If you are running on something other than the RPI, I'll let you know when the updates are rolling out, and you can temporarily plug in your RPI so your units can get the updates.

There is a list of a ton of bugs that will be fixed in the upcoming firmware, so it'll be worth it!  Please be patient, we really want this to be solid and go off without any hitches.

Con Kolivas is also working with us on the beta firmware to enhance cgminer, and hopefully we'll be able to push that out at the same time.

I'll keep you posted!

-Phil

[tacotime]

There is a known problem with the USB stack on windows.  This is a cgminer known issue, which is why we recommend a linux-based mining solution and provide the RPI with every BJ.  The best you could do is make some sort of a script that restarts cgminer, or better yet windows itself, after mining stops or even just after 8 hours or so.

Hopefully once we get cgminer and the firnmware stable, we can look at possible windows solutions.  Windows in general is not a stable platform, which is why most servers on the internet don't use it.

-Phil

You can reboot it by script every 2h on windows like this with python:

Code:

import os, subprocess, time

while True:
      print("Starting cgminer...")
      p = subprocess.Popen("C:\\Users\\my-pc\\Desktop\\mycgminerfolder\\mine.bat")
      time.sleep(7200)
      print("Terminating cgminer...")
      p.terminate()
      time.sleep(5)

where mine.bat is what you use to launch it

I've been having zero stability issues so far, though.

[MinorMiner]

Quick question again.. what are the flags/ options for overclocking the Hashfast unit via the mine peon software?

[dbbit]

Hopefully once we get cgminer and the firnmware stable, we can look at possible windows solutions.  Windows in general is not a stable platform, which is why most servers on the internet don't use it.

I don't quite buy the "This is Windows's fault" argument. Bing.com runs on Windows Server 2012 and it's the 9th largest site in the world, and has the same stability as google.com.

But if you do in fact know of any specific issue in Windows that's causing any problems for you, please let me know those are and send the memory dumps - I live very close to Microsoft, and know enough people over there that can look at them for you.

Either way, I'm not looking for even bing.com level of reliability here. If the controller for the BabyJet is merely as stable as all of my other BitCoin / LiteCoin & AltCoin Windows based miners, and it can only run for 3 months before having to be rebooted, so be it. That's still VERY different than having the miner go down every day after 7 hours.


PS: I've now started running cgminer under cgwatcher. This helps. I bet (but don't know for sure) that the cgminer on the RPI probably has the exact same issues, and the watchdog process is just restarting it - same that cgwatcher does. Now that I'm running cgwatcher, my graphs on Eligius looks the exact same as it did on the RPI. Every couple of hours there is a steep down spike into the low 300's. I can now see on the PC it corresponds to cgwatcher restarting cgminer. I couldn't tell what it was doing on Minepeon, but I bet it did the same since the graphs look the same.

[ninjarobot]

Came back from work today and noticed my BJ was dead again. *sigh*

I needed to hard-reset the Pi and hot-plug the USB cable before it came back. Take a look at my mining graphs and tell me I have a stable system.. (This is at normal clock speed)

I will give 3.11 another shot.

Network provider is stable ? Dropped connection could spin it out - shutdown.
Just a variable no one mentioned yet.

DSL and wireless not so good for this stuff.

When I went to TWarner to ask about this, they asked "what are you doing" I told them 900k up 1500k down 24/7
They said it was allowed and not over or excessive. Some will cut you off if they see to much constant traffic.

I think my network connection is fine. I've been using another RPi minepeon setup with my 30 GH/s BFL little single since early July and never had any stability issues with it (apart from the SD card becoming corrupted every 3 months or so). In any case I switched to 3.11 as seems to be the most stable image for my BJ so far.

Clearly the BJ hardware/firmware is still somewhat half baked. In a sense we are all overpaying alpha testers with a hardware warranty of 10 days.. Even BFL was nice enough to provide lifetime warranty on their products.

[CurcO]

Quick question again.. what are the flags/ options for overclocking the Hashfast unit via the mine peon software?

--hfa-hash-clock <arg>

[Big Time Coin]

If you guys are using windows i recommend cgwatcher. it uses the API to restart cgminer when it sees dead or low hashrate.

hf-engineer please - need new firmware i will send coffee and dounuts!

CGWATCHER?  auto-restart when sick or dead miner detected?  BINGO!

Awesome thanks man. Using it now, seems like a feature rich program, much more helpful than all the "just use linux" suggestions.

Disappointed to read that there is a "windows usb stack issue" that is a "known issue" with cgminer I guess I may have to try messing around with the Rpis again, though they were very unreliable when I was using them.  And not as easy to log in to remotely through vpn.  3.11 crashes for me on windows when I try to start it.  Using 3.12.

[fubly]

Code:

Rejected c4b91fb5 Diff 333/256 HFB 1 pool 0 (high-hash)

HIGH HASH on eligius.st

on ghash.io only low-hash will rejected!!!

HI HF,

can you explain please! Why the handling on different pools are not equal.

thx

fubly

[fubly]

Code:

[2014-02-04 09:21:40] HFB 1: Bad CRC 0 vs 175, discarding packet
 [2014-02-04 09:21:40] HFB 1: Bad CRC 180 vs 126, discarding packet
 [2014-02-04 09:21:40] HFB 1: Bad CRC 180 vs 126, discarding packet
 [2014-02-04 09:21:40] HFB 1: Bad CRC 0 vs 254, discarding packet
 [2014-02-04 09:21:41] HFB 1: Bad CRC 180 vs 126, discarding packet
 [2014-02-04 09:21:41] HFB 1: Bad CRC 181 vs 16, discarding packet
 [2014-02-04 09:21:41] HFB 1: Bad CRC 180 vs 126, discarding packet
 [2014-02-04 09:21:41] HFB 1: Bad CRC 0 vs 254, discarding packet
 [2014-02-04 09:21:41] HFB 1: Bad CRC 180 vs 126, discarding packet
 [2014-02-04 09:21:41] HFB 1: Bad CRC 180 vs 126, discarding packet
 [2014-02-04 09:21:41] HFB 1: Bad CRC 0 vs 254, discarding packet
 [2014-02-04 09:21:42] HFB 1: Bad CRC 180 vs 126, discarding packet
 [2014-02-04 09:21:42] HFB 1: Bad CRC 180 vs 126, discarding packet
 [2014-02-04 09:21:42] HFB 1: Bad CRC 0 vs 254, discarding packet
 [2014-02-04 09:21:42] HFB 1: Bad CRC 180 vs 126, discarding packet
 [2014-02-04 09:21:42] HFB 1: Bad CRC 0 vs 175, discarding packet

Why happens this?