Quote
That's the same as the one I just posted, but I only posted the firmware, not the tools.
Thanks for the info. And for probably making them release something at last (?)
Topic: HashFast BabyJet users thread - page 15. (Read 69008 times)
Thanks for the info. And for probably making them release something at last (?)
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
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.
How much power are you drawing at 687?
It fluctuates from 555-580
Did anybody else receive an E-Mail from hashfast with a 0.4 RC? Is this the same 0.4 posted earlier by ckolivas, or the newer one posted by ck just before? Or even newer 0.4?
That's the same as the one I just posted, but I only posted the firmware, not the tools.
Did anybody else receive an E-Mail from hashfast with a 0.4 RC? Is this the same 0.4 posted earlier by ckolivas, or the newer one posted by ck just before? Or even newer 0.4?
Quote
A Hashfast firmware update version 0.4 final release candidate is now
available. This exact binary will most likely will be announced and
distributed as the official release in the coming days.
As you may have been experiencing issues that may be fixed by this
update, we are providing you with early access. Please find the
attached gzip binary for Linux systems.
This has been tested on 32 and 64 bit Ubuntu as well as Raspberry PI ArchLinux.
We ask that you only apply this to systems with critical performance
issues at this time. We also ask that you do not distribute or post
this package elsewhere.
In the coming days we expect to begin offering a one-click upgrade
through our custom Raspberry PI MinePeon image. Right now we also do
have an option for updating via a special dedicated Raspberry Pi image
for those customers who are not set up with a Linux environment.
Please let us know your experience with this package so we can provide
feedback to our developers.
Thanks for your patience,
Avram C
Hashfast Technical Support.
available. This exact binary will most likely will be announced and
distributed as the official release in the coming days.
As you may have been experiencing issues that may be fixed by this
update, we are providing you with early access. Please find the
attached gzip binary for Linux systems.
This has been tested on 32 and 64 bit Ubuntu as well as Raspberry PI ArchLinux.
We ask that you only apply this to systems with critical performance
issues at this time. We also ask that you do not distribute or post
this package elsewhere.
In the coming days we expect to begin offering a one-click upgrade
through our custom Raspberry PI MinePeon image. Right now we also do
have an option for updating via a special dedicated Raspberry Pi image
for those customers who are not set up with a Linux environment.
Please let us know your experience with this package so we can provide
feedback to our developers.
Thanks for your patience,
Avram C
Hashfast Technical Support.
Quote
How much power are you drawing at 687?
I don't know (nor care) and my figure wouldn't be of any interest cause I only got 3 dies working. 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
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.
How much power are you drawing at 687?
This link now contains a newer firmware for those who have tried the previous one:
http://ck.kolivas.org/apps/cgminer/temp/uc3.cropped.hfu
Found and debugged some more issues in cgminer and it should be much better with multiple devices attached at once in git, so I'm just trying to fine tune that before the 4.0.1 release.
http://ck.kolivas.org/apps/cgminer/temp/uc3.cropped.hfu
Found and debugged some more issues in cgminer and it should be much better with multiple devices attached at once in git, so I'm just trying to fine tune that before the 4.0.1 release.
Q: How many programmers does it take to change a light bulb?
A: None. It's a hardware problem.
lol!
I installed the FW 0.4 on my babyjet. Upgrade procedure was painless, really.
Findings:
-I still only have 3 working dies
-BFGMiner works like before
-CGMiner doesn't find a device anymore (tried 3.11, 3.12.3 and 4.0 w/ zadig)
Hashrate seems actually a bit lower than 0.2. Might try that 0.3 release tomorrow.
Findings:
-I still only have 3 working dies
-BFGMiner works like before
-CGMiner doesn't find a device anymore (tried 3.11, 3.12.3 and 4.0 w/ zadig)
Hashrate seems actually a bit lower than 0.2. Might try that 0.3 release tomorrow.
From what I've read, FW 0.4 doesn't play nice with HW 1.1, so I haven't upgraded. The latest CGminer git has the HFA-FAIL-DROP. I compiled it this morning. CGminer says it is on the wrong USB ID/Vendor and can't get a name. The BabyJet doesn't even click on/off when CGminer starts up.
Here are the lines from the debug file...
HFA: Failed to receive OP_NAME response[11;21H3[11;64H1d6b:000[13;21H3] RES: Hashfast (6:10) lock=0[K
HFA looking for HFA 297c:0001 but found 1d6b:0001 instead[22;1H[K[23;24HNo devices detected
If device is not seen after upgrading fw, one solution would be to look the id/vendor string with lsusb and/or use latest udev 01-cgminer.rules.
I installed the FW 0.4 on my babyjet. Upgrade procedure was painless, really.
Findings:
-I still only have 3 working dies
-BFGMiner works like before
-CGMiner doesn't find a device anymore (tried 3.11, 3.12.3 and 4.0 w/ zadig)
Hashrate seems actually a bit lower than 0.2. Might try that 0.3 release tomorrow.
Findings:
-I still only have 3 working dies
-BFGMiner works like before
-CGMiner doesn't find a device anymore (tried 3.11, 3.12.3 and 4.0 w/ zadig)
Hashrate seems actually a bit lower than 0.2. Might try that 0.3 release tomorrow.
Has anybody had any luck with the latest cgminer git pull? Mine doesn't even show anything is connected...
RPi is a joke, like Ckolivas said why run thousands of $$$ in equipment on a $ 40 device,(use a bit of logic) get a real hw like a netbook ,laptop, desktop, which ever with a linux distro like debian, CentOS , Fedora or Ubunutu . The RPi is just not meant to used this purpose , aka controller the SD card which is quite slow to begin , also has a limited amount of writes which always leads to failure .
I've been using my Pi as an ASIC controller since June 2013. It has been rock solid. Just make sure you use a high-quality USB power supply. I do agree that the SD card 'limited writes' is an issue. Roughly every 3 months I need to replace my SD card or at the very least re-format and re-flash it with a fresh image.
ill link here to the same article i did in the megabigpower bitfury thread on setting up your pi to run off a flash drive as the main storage and only using/tapping/touching the SDcard for bootup.
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=44177
if youve got any questions hit me up and i can help. been using a pi in this config for past month as controller for my rig listed below. not a hiccup,dropped share, conn problem etc. rock solid
RPi is a joke, like Ckolivas said why run thousands of $$$ in equipment on a $ 40 device,(use a bit of logic) get a real hw like a netbook ,laptop, desktop, which ever with a linux distro like debian, CentOS , Fedora or Ubunutu . The RPi is just not meant to used this purpose , aka controller the SD card which is quite slow to begin , also has a limited amount of writes which always leads to failure .
I've been using my Pi as an ASIC controller since June 2013. It has been rock solid. Just make sure you use a high-quality USB power supply. I do agree that the SD card 'limited writes' is an issue. Roughly every 3 months I need to replace my SD card or at the very least re-format and re-flash it with a fresh image.
RPi is a joke, like Ckolivas said why run thousands of $$$ in equipment on a $ 40 device,(use a bit of logic) get a real hw like a netbook ,laptop, desktop, which ever with a linux distro like debian, CentOS , Fedora or Ubunutu . The RPi is just not meant to used this purpose , aka controller the SD card which is quite slow to begin , also has a limited amount of writes which always leads to failure .
Frankly, I was stunned when I pulled the Pi out of the box... If you read the instructions, it says that the Pi is mounted on the case--is that what the holes on the back are for? RPi even has an engineer making YouTube videos explaining the differences between the video cards, explaining that the newer one isn't as good. He went on to say they've had a sudden surge in returns (something like 20%?) So, he was explaining what the lights are for...
Hi,
My BJ was working fine about 25 days, and starting from today, raspberry pi keeps restarting every minutes, so in reality it stopped working. I don't know what caused the reboot, hardware, cgminer or the pi it's self. From the monitor, it can be any time, even last second it's hashing and received and accepted share, then suddenly rebooted.
Has anybody have the same issue. How should I diagnose this issue? Thank you very much for the help!
My BJ was working fine about 25 days, and starting from today, raspberry pi keeps restarting every minutes, so in reality it stopped working. I don't know what caused the reboot, hardware, cgminer or the pi it's self. From the monitor, it can be any time, even last second it's hashing and received and accepted share, then suddenly rebooted.
Has anybody have the same issue. How should I diagnose this issue? Thank you very much for the help!
RPi is a joke, like Ckolivas said why run thousands of $$$ in equipment on a $ 40 device,(use a bit of logic) get a real hw like a netbook ,laptop, desktop, which ever with a linux distro like debian, CentOS , Fedora or Ubunutu . The RPi is just not meant to used this purpose , aka controller the SD card which is quite slow to begin , also has a limited amount of writes which always leads to failure .
Hi,
My BJ was working fine about 25 days, and starting from today, raspberry pi keeps restarting every minutes, so in reality it stopped working. I don't know what caused the reboot, hardware, cgminer or the pi it's self. From the monitor, it can be any time, even last second it's hashing and received and accepted share, then suddenly rebooted.
Has anybody have the same issue. How should I diagnose this issue? Thank you very much for the help!
My BJ was working fine about 25 days, and starting from today, raspberry pi keeps restarting every minutes, so in reality it stopped working. I don't know what caused the reboot, hardware, cgminer or the pi it's self. From the monitor, it can be any time, even last second it's hashing and received and accepted share, then suddenly rebooted.
Has anybody have the same issue. How should I diagnose this issue? Thank you very much for the help!
Mine started doing that after 10 days, shortly after the update push & rollback. With mine, the SD reader just flaked-out. HashFast sent me a new SD card, I booted my pi, it got as far as the screen where MinePeon connects t the Internet, and it re-booted. I spent five days playing with it. I was able to load Raspian a couple of times from NOOB, only to have the SD card reader not work when it rebooted. It took me a while to figure out that the command prompt that I was seeing was BusyBox--the pi's embedded OS. Then, one day, the pi read the new SD card and cgminer appeared on the screen. It rebooted in the time it took me to get to my computer and log-on to setup.hashfast.com or the pi's IP address.
I told tech support about it ten days ago. Yesterday, they Emailed me. Some people on this thread simply got a better USB cable, bigger power supply, or both. My pi is quite happy to run on my old Dell laptop.
Oh! Check the indicator lights. The red one is for power. The single green one beside it is for the SD card. Check those out.
Hope that helps,
You can use bfgminer with --cmd-dead to restart bfgminer when it dies
I would need to take some time to figure out what needs to go in the command, and I can't overclock it...
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.
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
Did you try to set that to 0?
No, I haven't--Isn't it a 4.0.1 feature? Today, I've been playing with Python and the HF FW Installer. It requires Python 3.3.
I'll try setting it in a bit. It's been running at 600 MHz for most of the day. If it drops below 550, I just restart cgminer and it starts all over again. Today, it's finally hashing 420 GH/s @600 MHz, even with all of the hotplug restarts.
Hi,
My BJ was working fine about 25 days, and starting from today, raspberry pi keeps restarting every minutes, so in reality it stopped working. I don't know what caused the reboot, hardware, cgminer or the pi it's self. From the monitor, it can be any time, even last second it's hashing and received and accepted share, then suddenly rebooted.
Has anybody have the same issue. How should I diagnose this issue? Thank you very much for the help!
My BJ was working fine about 25 days, and starting from today, raspberry pi keeps restarting every minutes, so in reality it stopped working. I don't know what caused the reboot, hardware, cgminer or the pi it's self. From the monitor, it can be any time, even last second it's hashing and received and accepted share, then suddenly rebooted.
Has anybody have the same issue. How should I diagnose this issue? Thank you very much for the help!
Jump to: