Do you have battery backup/ UPS already implemented? (sorry if it's been covered elsewhere)
Just asking because I can get Panamax/Furman at or below dealer cost (with warranty)
Topic: all finished - page 6. (Read 43452 times)
Thanks brother, keep us updated when you can. With all your GBs, by January you are going to be flush with gear and a Hosted Operation to be reckoned with.
Do you have battery backup/ UPS already implemented? (sorry if it's been covered elsewhere)
Just asking because I can get Panamax/Furman at or below dealer cost (with warranty)
Do you have battery backup/ UPS already implemented? (sorry if it's been covered elsewhere)
Just asking because I can get Panamax/Furman at or below dealer cost (with warranty)
Question about the 5th miner that's coming in.
Let's say there's no issues with this one, will the hashing power be split to make up for the defective machines, or will it be dedicated solely for those who paid for the fifth machine?
Let's say there's no issues with this one, will the hashing power be split to make up for the defective machines, or will it be dedicated solely for those who paid for the fifth machine?
It shouldn't be shared with the previous machines, they've been hashing (at reduced rate) but they HAVE BEEN HASHING and making profits for THEIR share holders, are they going to share their profits with the miner 5 owners?
Question about the 5th miner that's coming in.
Let's say there's no issues with this one, will the hashing power be split to make up for the defective machines, or will it be dedicated solely for those who paid for the fifth machine?
Let's say there's no issues with this one, will the hashing power be split to make up for the defective machines, or will it be dedicated solely for those who paid for the fifth machine?
120 GH per chip = 480 GH total
miner 2 = 360 GH
means 1 chip is dead
miner 3 = 240 GH
means 2 chips are dead
dat true???
miner 2 = 360 GH
means 1 chip is dead
miner 3 = 240 GH
means 2 chips are dead
dat true???
What day of the week are you planning payouts?
Some good work you have to do to get these running it seems.Good luck!
Miner 4 stats page is up for me now.
And this might bear reposting:
I have a sat that has been acting funny, and had the temp phenomena...
I pressed on the copper bars, and instantly saw the jump.
I placed a wedge at the top of the heatsink to add a tad more pressure on the asic
it now works great.
Thank you for sharing that.....seriously!
And this might bear reposting:
Anyone know why the voltages on our 3rd Jupi are higher than on the first two? I believe that as a result of the voltage being higher the temps are also higher. Also it is my understanding that if the Output Current is close to 0 than that die isn't hashing right? Also on this Jupiter I see a ton of these: "[time stamp] KnC: accepted by FPGA 1-21 works, but only 0 submitted"
I've tried .95, .96. .96.1 and .97 and .96 gives me the best performance so far, but at these voltages/temps. Also I did press gently on the copper bars of the heatsink and that seemed to have brought a couple die Output Current on par with the rest, but as you can see there is still a couple that are around 0. After downgrading to .96 this most recent time CGMiner restarts every 20 minutes, but the hash rate starts around 500-550 and drops to 350-380 before CGMiner restarts. You can see the stats here on Jupiter 3: http://54.243.221.120/
I've asked KnC for an RMA, but I'm hoping I can avoid that if there is a fix for this.
Any ideas?
YOU NAILED ITI've tried .95, .96. .96.1 and .97 and .96 gives me the best performance so far, but at these voltages/temps. Also I did press gently on the copper bars of the heatsink and that seemed to have brought a couple die Output Current on par with the rest, but as you can see there is still a couple that are around 0. After downgrading to .96 this most recent time CGMiner restarts every 20 minutes, but the hash rate starts around 500-550 and drops to 350-380 before CGMiner restarts. You can see the stats here on Jupiter 3: http://54.243.221.120/
I've asked KnC for an RMA, but I'm hoping I can avoid that if there is a fix for this.
Any ideas?
I have a sat that has been acting funny, and had the temp phenomena...
I pressed on the copper bars, and instantly saw the jump.
I placed a wedge at the top of the heatsink to add a tad more pressure on the asic
it now works great.
Thank you for sharing that.....seriously!
Thanks, Waldo, for all the job you are doing!
May all the problems be overcome and may all your wishes be accomplished spontaneously and without effort!
May all the problems be overcome and may all your wishes be accomplished spontaneously and without effort!
No worries, just letting you know. I'm sure you're plenty busy with the tweaking and troubleshooting.
We all (should) understand hashing comes before stats.
We all (should) understand hashing comes before stats.
I can confirm that miner #4 stat is NOT working for me either!
Miners 1-3 stat pages are working, just not #4 (for me, at least)
And this guy seems to be quite knowledgeable:
I've been tracking a similar line of evidence for the last couple of days through my experiments with BFGMiner and various firmware levels. My theory is that on my underperforming board (and probably many others' out there) the issue is cracked solder ball joints due to the shipment of the machines with the heatsinks attached (soy, among others, have surmised the same so I'm not taking full credit on this idea). All the jostling enroute flexed the boards causing the solder defects. The higher temperatures allow some thermal expansion of the solder which might temporarily "glue" back together the microfractures allowing better connectivity. The fact that the solder is also a bit softer at those temperatures may aid in that. I'm not an industrial electronics engineer so maybe I'm talking out of my ass here, but that's the best explanation I can come up with so far.
That also means that it *might* be possible to repair the boards with the (in)famous cook-the-pcb-in-the-oven trick.
But that cooking-it-in-the-oven thing would scare the bejeesus out of me, personally.
ps, even at the server it is showing improved hash rate....thanks phoenix1969.
I also, what I noticed the with the increased heat the output current has increased...which is what I suspect as a culprit for some miners, or rather a low output is indicative of a problem.
But now with the temp rise, what has happened, the chip with disabled cores is down to just 1 disabled...
I also, what I noticed the with the increased heat the output current has increased...which is what I suspect as a culprit for some miners, or rather a low output is indicative of a problem.
But now with the temp rise, what has happened, the chip with disabled cores is down to just 1 disabled...
I've been tracking a similar line of evidence for the last couple of days through my experiments with BFGMiner and various firmware levels. My theory is that on my underperforming board (and probably many others' out there) the issue is cracked solder ball joints due to the shipment of the machines with the heatsinks attached (soy, among others, have surmised the same so I'm not taking full credit on this idea). All the jostling enroute flexed the boards causing the solder defects. The higher temperatures allow some thermal expansion of the solder which might temporarily "glue" back together the microfractures allowing better connectivity. The fact that the solder is also a bit softer at those temperatures may aid in that. I'm not an industrial electronics engineer so maybe I'm talking out of my ass here, but that's the best explanation I can come up with so far.
That also means that it *might* be possible to repair the boards with the (in)famous cook-the-pcb-in-the-oven trick.
But that cooking-it-in-the-oven thing would scare the bejeesus out of me, personally.
*Note- I let the room heat up a bit (no fans, ac or exhaust) and noticed the hash rate went up about 10GH/s on each unit.. hrmm.
Phoenix and Soy posted that 55C hashed higher than 35C, temp-wise.Stats are back up and running.
Quote
I'm still getting this error message:
Error: Username 145yMDUyjscnNbefYzK9owt3q4nFb4zQLr) not found in database. Please try again later., as the stats server is probably just overloaded. If this issue persists for several hours, please report it to the pool operator.
Normal, or just me? (Someone other than Waldo feel free to chip in here, as he probably won't see that message since he will be logged in/cached)
get on get on the #kncminer chat
setup your backup pool on each machine for those inevitable DDOSs
I've not paid much attention to the enablecores process since I don't have a machine to play with. Luckily you have several so you can compare a working unit with a problem unit.
GOOD LUCK!
setup your backup pool on each machine for those inevitable DDOSs
I've not paid much attention to the enablecores process since I don't have a machine to play with. Luckily you have several so you can compare a working unit with a problem unit.
GOOD LUCK!
Sorry you're dealing with multiple issues, but we all appreciate your effort and if there is (somehow) anything you need from us, just say the word.
Any news on miner #5?
Hopefully they are all performers and you don't get a dud.
::knock on wood::
::knock on wood::
Guys, sorry for the confusion above- but like al.matic pointed out, it was just a # that was left there when testing the formula.
More good news, our next 3 (Miners 2, 3, 4) Jupiters:
More good news, our next 3 (Miners 2, 3, 4) Jupiters:
Code:
October 24, 2013
08:31
Long Beach, CA - USA Scheduled for delivery
October 24, 2013
09:29
Long Beach, CA - USA With delivery courier
That was just cruel...
yaaaaay !
Guys, sorry for the confusion above- but like al.matic pointed out, it was just a # that was left there when testing the formula.
More good news, our next 3 (Miners 2, 3, 4) Jupiters:
Figures that the last one (the one I'm on) isn't here yet More good news, our next 3 (Miners 2, 3, 4) Jupiters:
Code:
October 24, 2013
08:31
Long Beach, CA - USA Scheduled for delivery
October 24, 2013
09:29
Long Beach, CA - USA With delivery courier
Jump to: