HashFast BabyJet users thread

[JointDoctor]

Holy shit, this is probably the most unstable miner i´ve ever seen.
More like a bad prototype to be honest. 

[DPoS]

you are the engineer.. why don't you build and release these scripts for your customers?

[cleartime]

Hi,
Thanks for your awesome work.
Could you please let me know which is the initial script if I want to add something in it?

[Melbustus]

Hi Phil,

Since the last update a few days ago, my miner has been rock solid, and with lower temps. I'm running a very consistent 423GH/s reported in the console (though less at Eligius; 12hr is ~396GH/s), with cores at 66-69. Screen says cgminer v3.9.0h2. This is running stock, off the RPi.

And thanks again for all the tech help. We really appreciate it. I think everyone here is super-pissed at Hashfast management in general (specifically John and Eduardo), but I like to think that most of us can target our anger to where it's deserved, and therefore keep it *out* of *this* thread. So I just wanted to say thanks for putting energy into this thread. It's been super helpful, and you've really been the sole bright-spot in the entire organization from what I've seen thusfar.


And a question about overclocking (understood that it voids warranty (which is surprisingly short and up soon anyways)): Are there other concerns besides temp to watch out for, as far as potential damage goes? Can I suck too much power through the board/chip without getting indication thereof via temperature? Anything else to look out for?

Thanks again!

[dentro]

Holy shit, this is probably the most unstable miner i´ve ever seen.
More like a bad prototype to be honest. 

the miner from knc was even worse! at the beginning their miner sucked more than 900 watts at startup and mined with 350 Gh/s. Then they released several firmware versions which solved the problems...

[-ck]

Also you have to prevent eligius pool to give the BJ an diff of 512, because the hashrate drops dramatically,
followed by many CRC Errors and then back to DIFF 256.

What an BS is this?

I believe this is a bug in the cgminer display. It doesn't just drop dramatically - it exact halves when the diff doubles.

I've watched it carefully through the stings when it does that - the Hashrate on Eligius itself doesn't seem to be affected, it's just the cgminer display. I'm not seeing CRC errors after switchover though. (3.11 on Windows).

Work difficulty is associated with a new stratum work update and so results from the previous stratum work update are still supposed to be accepted from the previous difficulty. Just because the pool has increased difficulty does not mean that work from the previous update is invalid at the old difficulty, as that's the difficulty that the mining software is still working on for that chunk of work. Please read the stratum protocol thread for extensive discussions we had about this. i.e. it is supposed to be normal for some lower difficulty shares to be accepted after the diff has risen.

[HF-Engineer]

you are the engineer.. why don't you build and release these scripts for your customers?

I already have.  If you use the RPI that was shipped with your BJ, it works.  I posted my test system for all to see on the last page, it works reliably 24/7.

If you want to run a custom system, then there's no way you can expect me to write custom scripts for you.  Would you really want me to take time off from working on the new firmware for something like this?

-Phil

[HF-Engineer]

Hi Phil,

Since the last update a few days ago, my miner has been rock solid, and with lower temps. I'm running a very consistent 423GH/s reported in the console (though less at Eligius; 12hr is ~396GH/s), with cores at 66-69. Screen says cgminer v3.9.0h2. This is running stock, off the RPi.

And thanks again for all the tech help. We really appreciate it. I think everyone here is super-pissed at Hashfast management in general (specifically John and Eduardo), but I like to think that most of us can target our anger to where it's deserved, and therefore keep it *out* of *this* thread. So I just wanted to say thanks for putting energy into this thread. It's been super helpful, and you've really been the sole bright-spot in the entire organization from what I've seen thusfar.


And a question about overclocking (understood that it voids warranty (which is surprisingly short and up soon anyways)): Are there other concerns besides temp to watch out for, as far as potential damage goes? Can I suck too much power through the board/chip without getting indication thereof via temperature? Anything else to look out for?

Thanks again!

Thanks Melbustus.  I can't specifically speak for management, but I can say that overall things are getting much better around here, and we are making even more progress on the engineering side that's going to make our systems much better soon!

The modules protect themselves, so it's unlikely you can do something via software that could damage them.  The on-board power supplies are likely the first limiting factor, as they will go into current limit and will drop the voltage if you attempt to draw too much current.  If the die temperature gets too high there is both a software and hardware current limit that should prevent you from overheating the silicon to the point of damage.  We will soon have a method to explore overclocking, and it will work on a per-die level.  It's being tested now.

I'll keep you posted and let everyone know as soon as there is anything interesting ready.

-Phil

[-ck]

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

No, the current p2pool code will always yield at best a 20% DOA rate for all asic based miners.

[SNIP]

Please stop perpetuating this myth. Only asicminer blades, which did not have a way to stop work in progress, were appalling for p2pool, along with MANY early firmwares for various ASIC devices, now long since history. High DOA with the hashfast devices at this stage is due to the work restart flush being disabled in early firmwares due to power issues to do with current drop down to minimal and then instantly back up to maximum. This has been smoothed out in newer firmwares, so the restart mechanism will be back, and hopefully it will be trivial for users to upgrade to the new firmware due out soon. I'm sorry to see that the early firmware was not ideal too, but I can see the forces at work that pushed hardware out - but that's not my domain.

[HF-Engineer]

Hi,
Thanks for your awesome work.
Could you please let me know which is the initial script if I want to add something in it?

In MinePeon, the shell script that calls cgminer is:
/opt/minepeon/etc/init.d/miner-start.sh

However, there is usually no need to alter any scripts (and we advise against it) as you can add parameters to the cgminer command line from the settings page in the web interface.  Also, If you do alter any scripts, it's possible that changes may be overwritten in an update.

-Phil

[xunknownx]

if im not running into any issues, should i still upgrade?  i got shipped with the early version of minepeon (non hashfast version) and i updated to cgminer 3.10.

im hesitant to upgrade because of downtime and i dont want to start causing issue?  are there any benefits for me in the newer version?

[tacotime]

Stability with these is HIGHLY related to ambient temperature... at -4 C ambient they're very stable, whereas at 22C ambient they crash a lot.  Not that it super matters, 3.11.0 cgminer restarts it whenever it crashes anyway.

24 hours stable hash rate so far.

[starsoccer9]

@HF Engineer,
So you can/will be pushing out software improvements to the physical chips/modules and so we should have a rpi handy to update it?

[Big Time Coin]

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

Question 1: Will you be pushing firmware updates without any manual component, meaning if I follow these instructions the firmware for my device will be updated without any warning and I will not even be notified?

Question 2: Will the updating of firmware occur for all devices that I have hooked up to a single Rpi?  Meaning if I have 10 babyjets all plugged into one USB hub which hub is plugged into my RPi will the firmware for all 10 devices be updated?

[joshv06]

I got my 12 BJ's with the latest firmware. I was wondering why so many people were having problems. I am averaging 390Gh/s each.

[dbbit]

Stability with these is HIGHLY related to ambient temperature... at -4 C ambient they're very stable, whereas at 22C ambient they crash a lot.  Not that it super matters, 3.11.0 cgminer restarts it whenever it crashes anyway.

24 hours stable hash rate so far.

What's your core temperatures when you run in -4 C ambient? My cores are under ideal (they're between 57C and 67 C) at even 15 C ambient.

[Morblias]

Eligius pool just went down for me and the RPi rebooted to switch to my backup pool. When Eligius came back up, the RPi rebooted again. Why is it rebooting vs just having cgminer switch to the other pool like it normally should?

[cleartime]

Hi,
Thanks for your awesome work.
Could you please let me know which is the initial script if I want to add something in it?

In MinePeon, the shell script that calls cgminer is:
/opt/minepeon/etc/init.d/miner-start.sh

However, there is usually no need to alter any scripts (and we advise against it) as you can add parameters to the cgminer command line from the settings page in the web interface.  Also, If you do alter any scripts, it's possible that changes may be overwritten in an update.

-Phil

Phil,
I just want to add a ssh revert tunnel for remote access the web page.

Thanks

[legendroute]

Sorry guys. I just got my BJ yesterday. But Raspberry Pi does not work in first shot, there is no display on the monitor at all, I even purchased a brand new monitor($200 wasted), and NIC port on switch is never on. I tried to contact them, there is no reply yet. While waiting for the reply. I would like to try mining on a linux box(xubuntu).

Can anybody kindly help me on how to install driver and start testing my BJ with cgminer? Which version of cgminer should I use and what parameters shall I pass to cgminer? Millions of thanks in advance!

Also there is a power button with two write LED on the two sides in front panel, but after I plunged in the power cord, there is no LED light indicating the power is on, is this normal?

[-ck]

Eligius pool just went down for me and the RPi rebooted to switch to my backup pool. When Eligius came back up, the RPi rebooted again. Why is it rebooting vs just having cgminer switch to the other pool like it normally should?

There is a watchdog in the BJ firmware that is trigger happy. Hopefully that will be fixed with newer firmware and cgminer version combinations.