Phil
BJ is clocked at 600 the 4th die is running a tad cooler then the others. It was running for 24 hrs before cgminer restarted. Do I have a problem I need to be concerned about?
RasPi came with a cracked sd card housing. Replaced it and the up time is better but I do get a lot of stale shares on the pool. The 600 clock has stabilized the hashrate for the most part. 141824 erroneous shares in the past 24 hrs.
Thanks Stan
cgminer version 3.9.0h2 - Started: [2014-02-07 23:54:38]
--------------------------------------------------------------------------------
(5s):424.9G (avg):456.7Gh/s | A:192512 R:2560 HW:330 WU:6463.5/m
ST: 2 SS: 0 NB: 4 LW: 197416 GF: 0 RF: 0
Connected to diff 256 with stratum as user.worker1
Block: 7a047ad0... Diff:2.62G Started: [00:16:26] Best share: 101K
--------------------------------------------------------------------------------
[P]ool management Settings Display options [Q]uit
HFA 0: 79C/.79V 80C/.79V 75C/.79V 72C/.79V 472.8G/459.2Gh/s | A:192256 R:2560 HW:330 WU: 6499.1/m
Topic: HashFast BabyJet users thread - page 30. (Read 69024 times)
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?
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.
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.
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.
@edgie: Ah, I'm not alone. Does your cgminer 3.09hf2 also show double the actual hashrate with diff < 512?
Yes.
....not sure. I'll open her up tomorrow and let you know.
EDIT:
I just looked at one of the pictures that I took when my BJ arrived. The case was damaged in shipping. ....any who... Mine is Rev. 1.1.
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
@edgie: Ah, I'm not alone. Does your cgminer 3.09hf2 also show double the actual hashrate with diff < 512?
Yes.
@edgie: Ah, I'm not alone. Does your cgminer 3.09hf2 also show double the actual hashrate with diff < 512?
Yes.
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
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
@Phil
you probably the best thing that happened to us hashfast users and I (and I bet others) would show my/their appreciation in coins if you post an address...
Regarding firmware / RMA, I pretty much had the same line of thought, to try new firmware first before going through the hassle of RMAing the board. So count me in if there is a release to test.
thanks
@edgie: Ah, I'm not alone. Does your cgminer 3.09hf2 also show double the actual hashrate with diff < 512?
you probably the best thing that happened to us hashfast users and I (and I bet others) would show my/their appreciation in coins if you post an address...
Regarding firmware / RMA, I pretty much had the same line of thought, to try new firmware first before going through the hassle of RMAing the board. So count me in if there is a release to test.
thanks
@edgie: Ah, I'm not alone. Does your cgminer 3.09hf2 also show double the actual hashrate with diff < 512?
@HF Engineer:
if you got a spare minute, do you have an idea what could cause this on my babyjet:
(note the low temps on the right)
Pool (eligius) reports only ~@250ghps from this babyjet. RPi image with cgminer 3.09hf2.
No errors in log, HW value low.
Checked screws, thermal paste, fans etc.
Much appreciated!
It appears that one die and maybe part of another is not hashing. This could definitely be firmware related, so let's wait until we can get you some new firmware out and see if we can get the idle cores back in action. if you got a spare minute, do you have an idea what could cause this on my babyjet:
Code:
HFA 1: 77C/0.80V 73C/0.79V 66C/0.79V 51C/.82V
Pool (eligius) reports only ~@250ghps from this babyjet. RPi image with cgminer 3.09hf2.
No errors in log, HW value low.
Checked screws, thermal paste, fans etc.
Much appreciated!
If not, I'll do all I can to see you get a RMA.
-Phil
I have the same issue. Should I send an email to Hashfast? I am afraid that my warranty will run out before the new firmware is released.
@HF Engineer:
if you got a spare minute, do you have an idea what could cause this on my babyjet:
(note the low temps on the right)
Pool (eligius) reports only ~@250ghps from this babyjet. RPi image with cgminer 3.09hf2.
No errors in log, HW value low.
Checked screws, thermal paste, fans etc.
Much appreciated!
It appears that one die and maybe part of another is not hashing. This could definitely be firmware related, so let's wait until we can get you some new firmware out and see if we can get the idle cores back in action. if you got a spare minute, do you have an idea what could cause this on my babyjet:
Code:
HFA 1: 77C/0.80V 73C/0.79V 66C/0.79V 51C/.82V
Pool (eligius) reports only ~@250ghps from this babyjet. RPi image with cgminer 3.09hf2.
No errors in log, HW value low.
Checked screws, thermal paste, fans etc.
Much appreciated!
If not, I'll do all I can to see you get a RMA.
-Phil
Meh I screwed something up on 3.12.1 that would make cgminer just go idle eventually, so I've posted a hotfix 3.12.23.12.3 release.
There are good days and bad days 
@HF Engineer:
if you got a spare minute, do you have an idea what could cause this on my babyjet:
(note the low temps on the right)
Pool (eligius) reports only ~@250ghps from this babyjet. RPi image with cgminer 3.09hf2.
No errors in log, HW value low.
Checked screws, thermal paste, fans etc.
Much appreciated!
if you got a spare minute, do you have an idea what could cause this on my babyjet:
Code:
HFA 1: 77C/0.80V 73C/0.79V 66C/0.79V 51C/.82V
Pool (eligius) reports only ~@250ghps from this babyjet. RPi image with cgminer 3.09hf2.
No errors in log, HW value low.
Checked screws, thermal paste, fans etc.
Much appreciated!
Meh I screwed something up on 3.12.1 that would make cgminer just go idle eventually, so I've posted a hotfix 3.12.2 release.
Con is doing great work, but development is hard, and bugs are inevitable, so this is why we want to thoroughly test everything before we recommend an upgrade.Still, if you want the best uptime and hashrate, as reported at the pool, you should be running our well vetted 3.9.0h2 version:
Here's the source code: http://setup.hashfast.com/cgminer-3.9.0h2.tar.gz
(MD5: fdef15ae73b180deef74bc51df482eb0)
If you are using our recommended RPI image, this is automatically what you are running.
As of about 15 minutes ago, I'm currently testing a release candidate on my public test system at:
http://setup.hashfast.com/rpi/
Watch the hashrate reported at the pool. If it stays good, I'll push it out everyone that wants it:
http://eligius.st/~wizkid057/newstats/userstats.php/17ao2fT7gbnnKYpMd7x29E8p4oGdE87Ahd
-Phil
Makes me think that we all need the new Firmware from HF which has been announced to be "delivered soon" , Kinda depressing since Cgminer 3.12.1 has the code for using the Firmware however we wait and wait, its been 7 days and counting 
The firmware is being tested and worked on. We absolutely don't want to give to stuff that breaks your gear or LOWERS your hashrate!Please bear with us. It's not like we're sitting around doing nothing. The protocol guide is open-sourced, and we are going to actually open-source everything as soon as we can. Con's cgminer is also open-source. Feel free to write your own code anytime you like, and make look easy!
There are KNOWN BUGS with what are are testing now that we are working though. There are bugs in what you are running now too, but at least they keep hashing instead of dying off. What would you rather have?
-Phil
mgio,
well that was my first thought so I looked at HW very early on, it doesn't seem excessively high:
after a couple mins @585mhz.
well that was my first thought so I looked at HW very early on, it doesn't seem excessively high:
Code:
A:8704 R:0 HW:17 WU:4175.2/m
after a couple mins @585mhz.
That looks very low. After a few minuntes my errors are up to the hundreds of thousands.
The WU number is low, though, which makes sense since that is directly proportional to your hashrate. Maybe you have some defective cores that aren't spewing out errors but just aren't working.
On the other hand if there is so many defective cores, why did it pass the burn-in at hashfast (if there was any)
Oh man, I wonder how long it will even take them to reply on my first message, let alone exchange the board.
I know that the BlowJob I got did not get a BurnIn, hence when I open the RPI their was nothing in the wallet so go figure . Great Q/C
mgio,
well that was my first thought so I looked at HW very early on, it doesn't seem excessively high:
after a couple mins @585mhz.
well that was my first thought so I looked at HW very early on, it doesn't seem excessively high:
Code:
A:8704 R:0 HW:17 WU:4175.2/m
after a couple mins @585mhz.
That looks very low. After a few minuntes my errors are up to the hundreds of thousands.
The WU number is low, though, which makes sense since that is directly proportional to your hashrate. Maybe you have some defective cores that aren't spewing out errors but just aren't working.
On the other hand if there is so many defective cores, why did it pass the burn-in at hashfast (if there was any)
Oh man, I wonder how long it will even take them to reply on my first message, let alone exchange the board.
I believe you are not on new firmware? I strongly advise people wait till they have new firmware as the new cgminer code is optimised around it and vice versa.
Thanks! I'm back on 3.11 now and my recovery time is back to around 5 seconds.
Has the new Firmware been pushed out to anyone yet? (Apart from you?)
I'm not running on the RPI right now, so I won't get the Firmware update automatically.
Jump to: