Oh my god
Bitcoin is crazyyyyyyyyyyyyyyyyy
yeah 1,030.00 USD on www.mtgox.com I looked up local time for Shanghai China it is 12:20am or some such Thursday..jeez....an't even daytime yet...wait till Thurs Eve China Time! Show chart Last:$1,040.00000 High:$1,044.00000 Low:$877.00 Vol:31578 BTC W.Avg:$959.04 MtGox a minute or so ago. |
|
|
|
Dead Die update
Got an RMA'd board back and it ran fine for a few days and a die died.. Turned off the fan, let it heat up to 82c and it came back on (switched to FW 94 from 98.1 beta for this)
let it cool with fan and run stable for 5 mins then switched it back to 98.1 and running fine.
so where is that tuning app KNC?? we need it
I also notice that heat helps recover the units full potential. Yes, which doesn't make sense. Heat pops electrons from impurities triggering activity on fet gates causing illogic. So, the heat must improve functionality via expansion or warping. Wonder if it's a characteristic of the super large IC. Wondered if there might be an expansion and contraction issue like with Dell laptop Nvidia gpus where the ball grid array develops opens. You'll not see me putting heat on a ~$1000 chip like I would to a laptop motheboard gpu and fortunately mine are fine. |
|
|
|
Buying this now with BTC locks you in at 850$/btc
if the BTC price crashes, you can get a refund
if the price stays the same, get the miner
you forgot to mention the third scenario: BTC at 2K$ by the time you get your Neptune... Still makes Money. sure, but a lot less then what you would have done if you kept your btc in your wallet. One should weight the 3 options and then decide. the fact is that probably a 3TH/s machine in April will produce 0.3BTC a day (30PH/s net hash rate). 12/0.3 = 40 day, but bear in mind that diff increase every 12 days or so buy an unknown factor... so, you're saying my Merc with an upgrade module will only be making .028btc/day next April. Bummer. And almost $10k is too rich for my blood. |
|
|
|
Hey I saw someone posted on the KNC site that the November Jupiters draw a lot more power. Does anyone knew if this is true? Could KNC tell us please since they are shipping they must have tested a few. Or could the first people receiving through up a draw number at the wall? It would be appreciated since I assume everyone ordered their PSU in advance and I used their recommendation of an 850W.
there are others on here that have more expertise that can chime in but to the best of my knowledge they draw more power because they are supposedly capbable of 650gh..now seeings how KNC often "under estimates" what is what on GH if it was me I'd get at least a 1200w unit simply because you just "know" someone down the line when it is prudent is gonna have a hack to 'overclock" knc units anyway that is my take on it..better safe then sorry Searing What does a typical electric heater draw? 1500 watts @ 120vac. |
|
|
|
|
From the article: "Maybe a European house can run six chips and a US house less chips,” he said, adding that chips would turn on automatically as more power became available to the box."
I wondered if something similar was going on with a poster who said his Saturns and Jupiter all had problems but didn't say anything as if there were this in the programming someone would have noticed and pointed it out.
|
|
|
|
Hello Jupiter Owners. (also other miners may pitch in as well)
Anyone got a Temperature reader/gun.
Any chance you could measure the Temperature of the PCI cables, seen another post for a Bitfury thingy where a PCI cable burnt out.
I have Just Measured mine, running at 28c, 30c , 35c , 40c. Measured where it connects to the Jupiter PCI-e extension cable.
Ambient Temp for the Room is 26c.
Cheers
C_C
Mine are similar, 34-36°C but it might be dependent on the firmware you are running, also with the Bitfury miners they can be overclocked and pull alot more volts than at stock which might push a borderline psu cable beyond its capabilities. When I made my first cables for my Merc I needed to splice a couple of PCI-E connectors, cut from video card test cable sold on ebay, to heavy wire that I would run to one or two power supplies. I bought a 15 amp extension cord and cut pieces. Figuring 15 amps should be heavy enough I found I could run the Merc on a single supply. The lines were a little long and I had the 12v line bunched and tied. I was running firmware 0.94 and drawing about 260 watts at the wall. I happened to place my hand on the bunched 15 amp capable wire and it was quite warm. I immediately put together a double 15 amp cable for the single module Merc and that was cool. When I added a second module I again used a double cable but it was less necessary as I was now running 0.98. Figure the one module was running 4x~50amps@.9v for 180watts, figure efficiency of the VRM in the high 80% so call them 88% efficient for 204½watts at 12volts plus there'd be something for the BBB and controller board which we'll discount, so 17amps@12volts - and it was a 15 amp extension cord. |
|
|
|
What I tried to underline is that:
a) I have no idea what caused my Saturns problems, my Jupiter running on the same line and same PSU type was not affected
b) The Saturns came with all boards affected by die #0 issue, (same as my Jupiter), they are running with die #0 off on 0.98
c) Both Saturns ran pretty well on 0.98.1 beta, one of them easily powering all dies, the other required more heat and was really hard to keep all dies powered on
d) Once 0.99 was released, i switched all my machines to it and for a day or two, they were running the same as on 0.98.1 beta
e) All of a sudden, both Saturns became affected with disabled cores, but in a different way: one of them simply has all cores disabled at startup (and keeps them like that) on 0.98.1 beta or official and 0.99. The other one starts normally, but after a while almost all cores on the same ASIC (coincidence?), the lower one on the web interface, gets disabled, only 0-5 cores remaining enabled on each die. Again, disabled cores are present on just one ASIC, the lower one in the web interface page.
This started at a day or 2 after 0.99 and the problem remained even after hard reset and affecting 0.98.1 as well, beta or official.
f) Both Saturns run normally (with their die #0 issue) on 0.98
My guess was that 0.99 FW somehow caused this issue, but it just persists now on 0.98.1 as well.
While upgrading my Saturn, I too ran into issues and now one of the new boards and one of the old boards are completely dead. All dies and cores report off. Enable cores doesn't work, all firmwares: nothing, plugged PCI-E straight into board: nothing. Most likely an RMA issue, and a PITA, to boot. Running their diagnostic shows all dies are idle. Don't want to risk 'heating' them up because I don't want to risk the electronics if I have to send it back anyways. I'm out of options unless anyone here has a method that brought back a dead board. My bertmod output is: Its pretty much the same for the two failing boards. Different ports make no difference. Mining Status CGMiner Status Running (pid=1654) Last Checked Mon Nov 25 22:50:14 UTC 2013 Avg. Hash Rate 0 Gh/s WU 0 Difficulty Accepted 0 HW Status ASIC slot #1 - ASIC slot #2 - ASIC slot #3 27.0 ℃ ASIC slot #4 - ASIC slot #5 - ASIC slot #6 - STATUS=S When=1385419799 Code=11 Msg=Summary Description=cgminer 3.8.1|SUMMARY Elapsed=210 MHS av=0.00 MHS 5s=0.00 Found Blocks=0 Getworks=14 Accepted=0 Rejected=0 Hardware Errors=0 Utility=0.00 Discarded=16 Stale=0 Get Failures=0 Local Work=275 Remote Failures=0 Network Blocks=2 Total MH=0.0000 Work Utility=0.00 Difficulty Accepted=0.00000000 Difficulty Rejected=0.00000000 Difficulty Stale=0.00000000 Best Share=0 Device Hardware%=0.0000 Device Rejected%=0.0000 Pool Rejected%=0.0000 Pool Stale%=0.0000| ASIC Board Info 2 Temperature sensor: 27.0 C Die ID Cores ON Cores OFF % 0 0 48 0 1 0 48 0 2 0 48 0 3 0 48 0 DC/DC ID ON/OFF Status Input Voltage Output Voltage Output Current 0 ON OK 12.1 V 0.769 V 0.188 A 1 No DC/DC detected 2 ON OK 12.2 V 0.786 V 0.312 A 3 No DC/DC detected 4 ON OK 12.1 V 0.742 V 0.25 A 5 No DC/DC detected 6 No DC/DC detected 7 ON OK 12.2 V 0.771 V 0.375 A Total DC/DC power output: 0 W Did you try swapping the ribbon cable between a working module and a failing module? Or removing the working module leaving all good cables in place. Remove the non-working module, take off the tower and inspect the heatsink compound and the board with a loupe or magnifying glass, then put it in place of the good module and try to fire up. |
|
|
|
The power line could be the problem indeed. As for PSU I'm using 2 X Enermax Maxrevo 1500W (gold), one powering the Jupiter, the other powering the 2 saturns. They have 4 12V rails available for PCI-e and I simply use one rail for each module.
My Jupiter runs just fine on 0.98.1 beta and it ran fine on 0.99 since release until today, when I found it running with all die #0 offline so i switched back to 0.98.1 beta. Just the 2 Saturns seems to have been affected. They still run "ok" with only die #0 offline on 0.98.
By the way, both PSU's are getting power from the same line.
By 4 rails for the PCI-E do you mean that not only are the individual 12v lines separate but that they have independent grounds? Independent grounding could cause difficulties. |
|
|
|
"I'm wondering the position in the miner of the modules with the die #0 issue."
All of them came with this issue. 4 broken boards in the Jupiter and 2 in each Saturn I own. Of course, KNC offered to RMA all 8 boards, but I passed so far because of the 0.98.1 beta FW that managed to make my Jupiter and one of the Saturns work with all dies on, while the other Saturn was a bit more difficult to keep stable at high temps, but still got periods of time with all 8 dies on, sometimes 7 and sometimes 6. Unfortunately, something happened after I used 0.99 on my Saturns, one of them has a complete dead ASIC showing all 48 cores off (bfgminer doesn't even shows that module), the other starts with all cores on, but also turns them all off after a while. That's only happening on 0.98.1 beta or 0.98.1 official or 0.99. Both machines runs "normally" with die #0 off on 0.98 though. Weird enough, 0.99 didn't affect my Jupiter though, which was happily hashing with all dies on (and most of the cores) until today, when somehow it turned all die #0 off, but I switched to 0.98.1 beta and after the usual 1h heating up modules, it now hashes again with all dies on.
Failures that pervasive I'd suspect your power supply choice and/or noise on your AC line. But still, to be comprehensive I'd take one of your Saturns, reduce it to a single module that runs perfectly, then swap that out for all the other modules labeling each and characterizing each. The records would help I would think. agreed...I'd be seriously looking at your power supply as a whole....not just the PSU. are you using a SINGLE rail PSU....not a multi?... did you remove the blu pci patchcords? is your miner on a separate circuit than other power -hungry home devices? did you try keeping the breeze off the vrm's? good luck. Having noticed a problem with add-on multi-speed fans and likely spike noise from their speed control, there may be something nearby. Faster switching is always happening. As switching speed increases the more vertical the rise and fall and this is desirable because it means less wasted power BUT an infinitely vertical rise or fall will produce infinite harmonics. Maybe a cheap wall dimmer. |
|
|
|
"I'm wondering the position in the miner of the modules with the die #0 issue."
All of them came with this issue. 4 broken boards in the Jupiter and 2 in each Saturn I own. Of course, KNC offered to RMA all 8 boards, but I passed so far because of the 0.98.1 beta FW that managed to make my Jupiter and one of the Saturns work with all dies on, while the other Saturn was a bit more difficult to keep stable at high temps, but still got periods of time with all 8 dies on, sometimes 7 and sometimes 6. Unfortunately, something happened after I used 0.99 on my Saturns, one of them has a complete dead ASIC showing all 48 cores off (bfgminer doesn't even shows that module), the other starts with all cores on, but also turns them all off after a while. That's only happening on 0.98.1 beta or 0.98.1 official or 0.99. Both machines runs "normally" with die #0 off on 0.98 though. Weird enough, 0.99 didn't affect my Jupiter though, which was happily hashing with all dies on (and most of the cores) until today, when somehow it turned all die #0 off, but I switched to 0.98.1 beta and after the usual 1h heating up modules, it now hashes again with all dies on.
Failures that pervasive I'd suspect your power supply choice and/or noise on your AC line. But still, to be comprehensive I'd take one of your Saturns, reduce it to a single module that runs perfectly, then swap that out for all the other modules labeling each and characterizing each. The records would help I would think. And don't move the ribbon cable with the module nor the blue power cable, stick with those that produce the 100% functional "Mercury" of one of your Saturns. |
|
|
|
 No details. Coming Soon TMWow! 20nm AND early 2014! That MUST be the "incoming news" announcement from 'orama. My big question would be: is KNC going to offer any kind of discounts for the late October delivery customers, the ones that suffered the big losses? I mean, I personally paid $131200 at current exchange rate for 1Th/s provided by an overheated Jupiter (running at full speed though under these high temps, otherwise all boards with die #0 issue) and 2 Saturns with all 4 boards with die #0 issue and forced to run under 0.98 because somehow 0.99 broke them and now I have one ASIC on each of them with all cores off on either 0.98.1 beta, 0.98.1 official or 0.99, but working just fine with 0.98 and dead die #0. My miners so far mined about $20500 at current exchange rate, so, yeah, ROI is out of question, just hoping to recover as much as possible from my investment and looking at KNC to see if they really care about their 1st batch customers as they proudly claimed once on their website! I'm wondering the position in the miner of the modules with the die #0 issue. Do the dies on the outboard fail more easily due to center air flow cooling the inside VRMs better than the outside VRMs so the outside VRMs heat the outer side of the ASIC more than the inner? And since both front fans rotate in the same direction, could the outside of the miner have greater airflow at the VRM level than the other? If so it would show failing dies, or dropped cores more on the side with the less cooled VRMs. |
|
|
|
No details. Coming Soon TMWow! 20nm AND early 2014! That MUST be the "incoming news" announcement from 'orama. anyone care to speculate on the other specs and prices? just for funI'll get us started, 2TH @ =< 0.5 watt per ghs and selling for $3999. or less  Power at the wall is an issue for us not prepared to upgrade our incoming service. |
|
|
|
I just saw that the controller as two 4 pin fan connectors for the box fans.  But the box fans have only 3 pin connectors. On a computer motherboard, a 4 pin connector allows the computer to control the fan speed to reach a targeted temperature. Could it be the same on a Jupiter/Saturn ? If yes, what is the target temperature ? Ah, I assumed the 4th pin was for speed feedback so as to allow a notification if the fan failed. |
|
|
|
Yeah but a lot of people believe price will drop, it's just a matter of when.
That's my brother-in-law's opinion but he's informed by an Oedipus complex. |
|
|
|
Remember there are seven billion people in the world, and only 12 million bitcoins.
Not everyone want Bitcoin, some want litecoin, primecoin etc.... I'm waiting for the govcoin or eurocoin  or uno-coin, UN crypto-currency. |
|
|
|
Heads-up for tomo BTW - incoming...
Day is almost over, what ya got? +1 On the page: Announcing Neptune our 20nm product for early 2014. Bitcoin Mining Hardware Search |
|
|
|
Ok the Noob , (thats me) got it working....
So i upgraded the modules and my saturn is hashing at a jupiter speed ...only one prob ...the front fans on casing have stopped working ...any idea why and solution ?
12v to the 4 pin molex is missing or needs a common ground. |
|
|
|
I am not sure this is the right place for this but this seems to be a catch all thread so here goes.
I have 2 late October Jupiters. One I was able to get to 550 with all cores running under 98.1 beta. The other has 2 cores on one board that will not work until 73C or 74C and as soon as they start the whole board shuts down (I assume thermal shutdown) so it only works at around 480.
I was living with that (not economically feasible to give up 480 hashes for 2 weeks to rma the thing just to maybe get another 60 or so).
Now the problem. I shut the full speed unit down for a few minutes to change locations and when I restarted it cgminer fails to start. The bone boots and I can tty into it. I can try to manually start cgminer and I get a "cgminer failed to start: Write Error".
I tried changing firmware. Cgminer will run on 98 but not on anything after and on 98 I have all die 0s dead.
Anyone have any clues?
TaggedYa
Put a voltmeter on your power supplys and check you have ~5v and ~12v. Also, I found my 4 pin molex could have been a little loose on the pins and closed the "tubes" a bit to fit more snugly on the board mounted 4 pin molex pins. |
|
|
|
Heads-up for tomo BTW - incoming...
is this kind of post considered useful? why not be a tad less 'cryptic' and you(r inbox) might not get abused so much... Also want to add, my ambient temps are 30C - 86F. so statements regarding VRMs needing heating and/or not liking cooling is NOT a fact covering ALL rigs/VRMs and even when they are hot(ter) they dont ALL fall back into line.... im sure ive mentioned this... As for 'wiggling' the heatsink aka 'cooling tower' - i think ill give that a miss. i personally dont want to hear 'warranty' is void due to negligence/abuse/possibly insane advice (though it might just work) Nobody said the temp issue covered "All rigs", and you still don't get what sharing info is about helping others in need, who ARE having problems.... and if you cared to read just a few posts more, before bashing O'rama, you would have seen that he spelled it out for those who can't "Read between the lines", but you still even missed it. What is your problem? Someone piss in your Cornflakes? I also stated clocking the heat-sink was a desperation move on my part, and that the temp thing was NOT a recommendation. It was a question!!! But.. it has helped others. There are two options when you have a board that isn't performing up to spec as I see it..... RMA it, or try to get it going yourself. Which one you try, is up to the owner... I'm an "Open book" in here, which is something I'm not used to... but if I can help someone, by golly..I'll do it....and share every conventional AND unconventional solutions I find. It is then up to you as the fellow KNC miner owner to make a decision based on how you feel about it. You would rather see everyone with a simple glitch on board do an RMA when they could possibly be fixed so simply? Not me... The temp issue is confusing. ASICs will have increased errors as heat increases since impurities will cause triggering of gates at random causing illogical conditions which themselves can cause more heat. If VRMs are running better hot than cool then I would think something is wrong, e.g. some open that closes with expansion due to heat, otherwise I don't see how heat can improve operation. |
|
|
|
|
I had mistakenly thought the new module was running cooler than the original in my Merc. Realizing the new module at 55°C might run better if cooled like the original running at 34°C and having two Antec 3 speed 120mm fans with 4 grills, I put one either side of the new module, just plugging into the 4 pin molex but that glitched and putty disconnected so I rebooted. Here I ran into trouble. The BBB couldn't get a connect. No bright white light, no red/green. It may have been the 3 speed switch on the fans. If those are SCRs perhaps the noise disturbed the BBB. I ended up running the two Antec fans from a nearby supply not associated with the Merc. Now it's back up and running all cores 37.5° and 34.5°C 285GH/s.
|
|
|
|
|
Show Posts
