@HF Engineer:
I tried everything I could with my babyjet (the one only getting 250ghps and core 3 and 4 at very low temps)
-powersupply voltage > it's fine
-breaks on connectors > none visible
-any visible damage from the dangling around in chassis >none visible
-cgminer 3.12.3 > it works, but same low hashrate and temperatures also it seems like it fluctuates a lot (hashrate goes down further, all cores going to 60°C, like there is no work to do, but there is)
-I looked at debug log > nothing in there that points to a problem, as far as I can read it
-The board temp for the cores that are low temp is higher than that for core 1 + 2, even tho they prolly at a very low load (because of fan on one side?)
One thing I noticed was when running the RPi image 3.09hf2 and I enable the debug log, the hash rate about halves and core 3 actually has a lower temp than core 4 (which is usually by far the coldest)
Makes no sense to me.
I'm wondering when HF plans to push new firmware, do you know anything?
Also, how are they handling RMAs? Do I have to send in the board before they send me a new one?
Topic: HashFast BabyJet users thread - page 29. (Read 69024 times)
Quote
So I figured I'd have more overclocking leeway than 570. Any suggestions?
Try get your temp up to 70+ and test again, Phil said 70-80°C is the sweet spot for the silicone
Yeah, but at 550 clock my temps are the same (65-67) and I have no problems at all.
Quote
So I figured I'd have more overclocking leeway than 570. Any suggestions?
Try get your temp up to 70+ and test again, Phil said 70-80°C is the sweet spot for the silicone
Hi Phil,
I tried some very minor overclocking. Looks like there's only a smidge of leeway on my machine as it stands right now. Specifically, I went to 570 clock and everything was fine, but when going to 580 (also tried 600), I get the following errors, non-stop:
Note that since the last update-push from HF, bringing us back to cgminer 3.9.0h2, my system was very stable at stock clock. Hashing steadily just under 400GH/s at Eligius, with little variance. Never more than 3-4 degrees variance between the cores, miner only rebooted once in several days, etc...
So I figured I'd have more overclocking leeway than 570. Any suggestions?
Thanks.
I tried some very minor overclocking. Looks like there's only a smidge of leeway on my machine as it stands right now. Specifically, I went to 570 clock and everything was fine, but when going to 580 (also tried 600), I get the following errors, non-stop:
Note that since the last update-push from HF, bringing us back to cgminer 3.9.0h2, my system was very stable at stock clock. Hashing steadily just under 400GH/s at Eligius, with little variance. Never more than 3-4 degrees variance between the cores, miner only rebooted once in several days, etc...
So I figured I'd have more overclocking leeway than 570. Any suggestions?
Thanks.
I have firmware:735ccca5. I'm curious to see if anyone has a different version.
Same here 735ccca5
how can you tell the version?
I have firmware:735ccca5. I'm curious to see if anyone has a different version.
Same here 735ccca5
how can you tell the version?
My shipping box had a big hole in the side...Luckily there was no damage to the miner. All screws seem to be just fine, My front panel light doesn't work though.
There is a front panel light?
It's not a big problem if you don't have a power LED as long as your box is running, but it's fairly easy to connect them. There is a 8 pin connector near the rear of the BJ, which is actually 4 two-pin connectors stacked right next to each other.
Looks like this:
::::
The first one (left or rear most 2 pins) is the power LED, the next 2 are the activity LED, then the power button, and finally the reset switch. (Note the power button is not really used except for testing, as USB can remotely turn on/off your rig)
-Phil
I have firmware:735ccca5. I'm curious to see if anyone has a different version.
Same here 735ccca5
well i ended up getting it to work using a .conf
Anyways been testing it in increments of 5. So far its going well.
Clock Rate 10 min avg 1hour Max Temp V
550 390 390 83 0.79
555 393 414/5 83 0.79
560 430 422 83 0.79
Anyways been testing it in increments of 5. So far its going well.
Clock Rate 10 min avg 1hour Max Temp V
550 390 390 83 0.79
555 393 414/5 83 0.79
560 430 422 83 0.79
I have firmware:735ccca5. I'm curious to see if anyone has a different version.
@stan: if that is the case I doubt your core 4 has a problem 
Thank You
@stan: if that is the case I doubt your core 4 has a problem
Interesting, cause mine came damaged too, front door broken off + had to remount the base plate with the 6 screws I found in the chassis.
I wonder if there is maybe a mechanical weak point on a connector or similar that broke on our shipments cause our boards were basically dangling on the wires.
I wonder if there is maybe a mechanical weak point on a connector or similar that broke on our shipments cause our boards were basically dangling on the wires.
I had to remount the base plate and I had 4 loose screws in the case. One of the case's feet was also shattered. It was definitely dropped at some point.
Ahh that is terrible!
My shipping box had a big hole in the side...Luckily there was no damage to the miner. All screws seem to be just fine, My front panel light doesn't work though.
There is a front panel light?
Relating to Overclocking, do I need to use the RPI to overclock? I tried using -hfa-hash-clock 555 in cgminer and cgminer just starts up and shows me a list of all the commands. So i assume im doing something wrong.
-edit: seems i got it to work, anyway in cgminer to confirm i have it running at the new clock rate?
try --hfa-hash-clock not -hfa-hash-clock-edit: seems i got it to work, anyway in cgminer to confirm i have it running at the new clock rate?
That is actually what the list of commands tells you ;-)
I think he may be right. This happened to me and I just thought it was a fluke. Basically I was mining at Pool 1 and pool1 went down for like 5mins. During the 5mins my miner switched to pool2. pool 1 came back and it didnt switch back. Is their a time limit before it switches back/checks? For example 1 time per min or something
If there are backup pools, it won't go back to the first pool until that one has been up for over 5 minutes, as a "stability test". This prevents cgminer from trying to connect to pools that are limping along and dropping out every 2 or 3 minutes during DDoS and so on. It's very easy for your hashrates to dive under those circumstances if you reconnect immediately to a pool whenever it comes back up.Ooo okay, then it may have been that.
Relating to Overclocking, do I need to use the RPI to overclock? I tried using -hfa-hash-clock 555 in cgminer and cgminer just starts up and shows me a list of all the commands. So i assume im doing something wrong.
-edit: seems i got it to work, anyway in cgminer to confirm i have it running at the new clock rate?
Fyi I am using cgminer 3.11 on windows
I think he may be right. This happened to me and I just thought it was a fluke. Basically I was mining at Pool 1 and pool1 went down for like 5mins. During the 5mins my miner switched to pool2. pool 1 came back and it didnt switch back. Is their a time limit before it switches back/checks? For example 1 time per min or something
If there are backup pools, it won't go back to the first pool until that one has been up for over 5 minutes, as a "stability test". This prevents cgminer from trying to connect to pools that are limping along and dropping out every 2 or 3 minutes during DDoS and so on. It's very easy for your hashrates to dive under those circumstances if you reconnect immediately to a pool whenever it comes back up. Con,
Already found a bug, if the pool "goes away" it will never resume mining. Getting this:
The machine can access the pool, and DNS is fine, but cgminer gets stuck. Any way you can put something in to exit if pool isn't active (like it used to work)?
This is precisely why we don't recommend anyone run new code until it's vetted.
-Phil
Actually none of the pool management code has been touched in ages so if you think there's a bug there, it's been there since long before any hashfast sanctioned release. Are you saying it never tried to reconnect?Already found a bug, if the pool "goes away" it will never resume mining. Getting this:
Code:
[2014-02-07 16:44:34] Failed to getaddrinfo for stratum.mining.eligius.st:3334
[2014-02-07 16:44:34] Testing pool http://stratum.mining.eligius.st:3334
The machine can access the pool, and DNS is fine, but cgminer gets stuck. Any way you can put something in to exit if pool isn't active (like it used to work)?
This is precisely why we don't recommend anyone run new code until it's vetted.
-Phil
I think he may be right. This happened to me and I just thought it was a fluke. Basically I was mining at Pool 1 and pool1 went down for like 5mins. During the 5mins my miner switched to pool2. pool 1 came back and it didnt switch back. Is their a time limit before it switches back/checks? For example 1 time per min or something
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?
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?
left one stops right one starts, as far as I'm aware.
Jump to: