KnCMiner Jupiter Tuning/Cooling

So as I mentioned before in a different post, I managed to get my hands on a KnCMiner Jupiter (November) a couple a months ago in the local area. It just needed a decent dusting/cleaning and it started chugging along at ~650 G/h no problem. As I wasn’t super familiar with Jupiters then, I was happy with that speed, especially since all I had was a ASIC Miner Erupter Cube (30 G/h) at the time. Well I am not the type to just let things be, so naturally I started looking how to overclock the Jupiter, as you can potentially take it up to about 940 G/h i found out! Additionally, I just very recently had another Jupiter (October) fall in my lap for a really good price, and I will cover its tuning as well. What follows is what I have learned and my little stint with immersive cooling (it was messy!).

Immersive Mineral Oil Cooling

Well first off, why immersive cooling? Well in short, as I was tuning my Jupiter’s, I found that I had more issues with keeping the VRMs cool, than keeping the ASIC chip cool. So instead of having a bazillion fans going, why not just dip them in mineral oil. I did enough research online, and it seemed the simplest/best and cheapest method to obtain what I needed to do for cooling the VRMs. I decided to try on my October version, since I wouldn't feel too bad if I broke it somehow, since I got it for such a cheap price. Well, here we go!

I went with the simplest setup possible, with the cheapest (surprise!) parts possible as well. Why break the bank on something that may not work out anyways, right? Here is what hardware I went with…

1.  Glass Aquarium (duh!):  I found a size that allows the 4 modules to sit side-by-side each other and just enough room behind them to wire them all up.

2.  Mineral oil: I basically wiped out the stock they had at the BX, which was 13 of 16oz bottles. It was an off-brand, just basic mineral oil.

3.  A Swiftech pump (MCP655):  I found this in the local area well by chance.  It saved me some waiting  time if I had to order it. There was one issue when I got it though, and it had no barbs! I didn’t know that until I went to go pick it up and it was pretty much useless without the barbs. I ended up taking the pump anyways and I luckily managed to find 3/8 inch barb adapters in the local area (@SunSea) that would screw into it no issue. Score!

4.  Corsair 120mm Radiator:  I had a Corsair H60 water-cooled system which I actually hooked up to one of the modules in my November (by the way the H60 hooks up ok, but I had to jerry-rig the bracket, but it worked), since it was getting really hot for some reason compared to the other modules. I ended up removing it off the module and I stripped the radiator off it for this job. Again, this saved me from the time waiting if I had to order radiator.

5. Random Hardware:  I got plenty a c-clamps for the tubing, hardware to mount the beagle board (no need to immerse it), and the clips to route the tubes around the aquarium. I also got some standard motherboard standoff screws/holders which I installed on the modules, just to keep the modules from sitting directly on the glass at the bottom of the aquarium, and to create some space for the oil to flow. Finally, I got two super small fans to sit immersed in the mineral oil to agitate the mineral oil, and help get the temps even throughout the aquarium.

6. Clear tubing: found off-base and went with 9mm I.D., as the hardware I have uses 3/8 I.D. fittings, so that was the closest size I could find. The tubing hooked up no problem.

7. Aquarium Temp Indicator:  I got this actually after the fact, as I didn’t think it was that important to monitor the oil temps, since I can see the ASIC’s temps in the web interface.  Well running the miner in mineral oil for a bit, the mineral oil gets really hot (I will explain in a bit), and I wanted to see actually how hot it got, as I didn’t want my cheap aquarium to spring a leak of super-hot mineral oil! Also, be mindful of the temperature range of the indicator you may get, as the one I got had a limit up 50 Celsius (aquarium use), so I don’t know how accurate/useful it was really going to be anyways.

 

Well I think that sums up everything I got and now it was time to slap it all together. I removed the 4 modules for the October chassis and gave them a good washing in my kitchen sink. Yes my kitchen sink. I washed them with water and Simple Green, and I had an old tooth brush to have some scrubbing action as well. I didn’t want to put in dirty modules in the mineral oil, so not to contaminate it. I then fired up my oven to 175 F degrees and put the 4 modules in there to dry, chips facing down to get some drip drying action too. I definitely don’t want water floating around in the mineral oil, which would be bad! After all that, the boards came out looking brand new actually, and worked just fine.

 

I did a dry fit with everything and even ran the miners for a bit and everything ran just fine. But it was at this juncture that I made a tactical error on when to put the mineral oil in. Even though I listed the Radiator/Pump/Tubing in the hardware list above, I did not actually have that stuff at this point, because I figured I didn’t need them. My plan was to immerse the module cards only, and to leave the heat sink/fans hooked up to help disperse the heat. It made sense to me at the time, but I guess I need to retake a thermodynamics class, because it didn’t really work out. I figured the oil in contact with all the heat sink parts would be enough to take the heat out of the mineral oil and the ASICs. Wrong! Well I made that fateful decision, and poured the mineral oil in and fired it up. It ran/mined just fine, but after some time, the oil got super-hot (felt it on the aquarium glass) and the ASICs temps were creeping up little by little, eventually getting in the 80 Celsius range, with no sign of stopping. Mineral oil has great heat capacity, but with no way to get it out of the system fast enough (my plan sucked), it just got hotter and hotter. Now I will admit that everywhere on the Internet, it said you have to use a pump/radiator system to get the heat out of the mineral oil, but I just didn’t have any of that stuff at the time; and I wanted to do this NOW! Well, guess what, trying to jerry-rig a pump/radiator system with the mineral oil already in the aquarium is messy to say the least, and impossible to do in reality. Before I tried that, the whole setup looked clean, neat, and pretty cool. But after the frustration of trying to install the pump/radiator, the aquarium turned into a gooey, smudged finger prints everwhere, and a complete messy failure of efforts.

The biggest issue I had was getting the damn pump to work (sorry I am getting mad just thinking about again!) with the mineral oil and to get everything flowing. I basically had the pump hanging over the edge of the aquarium, and everything plumbed up fine, but you have to prime the pump that way, I couldn’t get it to “suck” basically. Mineral oil has a higher viscosity than water, so the pump (a water pump by design) has to work extra hard because of that aspect, and top off the fact the pump has to work against gravity didn’t help either. Eventually, I managed to “prime the pump”, which was a complete mess on my part, but the pump just didn’t have to enough ummph to move the mineral oil fast enough, even  when I adjusted the pump speed. Actually, I couldn’t run the pump at full speed, as it would shut itself off after a couple of seconds, probably due struggling with the mineral oil viscosity and the plenty of air I probable inject in the system as well.

So where did this leave me? Well, firstly it left me with a mess and basically a waste effort. I literally wanted to throw the aquarium, mineral oil and all, out the window! But I didn’t of course, but I did drain everything, and re-cleaned the module cards so I can put them back in the Jupiter chassis. However, through this ordeal, I did learn some things that I would like to pass on to any seeking to do the same thing.

1.  The radiator I had was too small for the amount of heat the cards would have been making anyway, and wouldn’t have dissipated the heat fast enough, especially for the 650-ish watts total going into the mineral oil. The low flow rate from the pump wouldn’t have helped either.  I knew this going in, but I wanted to complete a proof-of-concept first, and if it worked out, I would have ordered a bigger radiator then. I was hoping to reach some kind of temperature equilibrium between the stock heat sinks/fans and the pump/radiator install at some point, just hopefully not at a too high temp and just for long enough for a larger radiator to be installed. Well that didn’t happen.

2.  I was using the pump wrong. It is a water pump by design, so the manual says not to immerse it. Well, that makes sense for water base systems, but I am using mineral oil and it is non-conductive, so why not? I didn’t notice before, but other mineral oil cooled systems systems I have seen online (Puget Systems) immerse the pumps in the mineral oil. After trying to prime the pump in my messed up way, that would have been soooooo much easier, and I might have actually had a working system right now. However, since I didn’t immerse it, I still have the pump placed wrong, as it was on the top of the aquarium. It should have been at the lowest point of the system, so gravity would have helped it along, but I didn’t want it that way as I wanted it attached to the aquarium. But that wouldn’t have worked either, has the pump’s outlet port threads developed a slow leak (I couldn’t stop it) that I didn’t notice that until the very end of me messing with everything. It was basically the “straw that broke the camel’s back”, and I scrapped the whole thing in a fit of frustration.

3. Obviously the modules needed the mineral oil cleaned off them, and that was a pain in the ass. It took many of washing/scrubbing, simple green, and dish washing soap to get much of it off. However, I have to point out something that was vexing me while was trying to tune the cards later. Even though I cleaned the modules really well and dried them in my oven, there was still PLENTY on mineral oil stuck under the actual ASICs themselves. I noticed something was wrong after the ASICs heated up while they were mining, and they would create massive amounts of hardware errors and stop working. I freaked out for some time, as I thought I mess the cards up, but I noticed that there was mineral oil leeching out from a small hole in the corner on the ASICs. All of them where doing this to some extent, and that ended up being my problem. I figure it was the mineral oil/soaps residues trapped under the ASIC’s, and shorting out pins there. To fix it, I took the cards out again, hung them using the module's mounting hole from the opposite corner from the small hole in the ASICs in the oven, so gravity would do it thing. I fired the oven up to 175 F degrees again and I let those cards cook for a long time (hours), and low and behold, mineral oil came oozing out after they got hot enough. I was actually really surprised by the amount of mineral oil that was coming out, and it made me think those ASICs chips are hollow or something on the bottom side. I think two of the modules are more or less drained out, but even now two modules are still leeching mineral oil once they warm up from mining from that small hole. I have been using a q-tip to dab the mineral oil up every so often, but the mining software hasn’t been throwing massive hardware errors like before, so I am not too worried about it.

Finally, as I move into the tuning section of this page, I didn’t completely toss out the idea of doing mineral cooling just yet. After I calmed down the next day, I relooked at everything I have done and I figured out how to do it better with what I got. I did throw out the mineral oil in the aquarium, which I should have saved for what I was trying to do next. I basically got a large enough container to submerge the pump in the mineral oil I had left and made a closed loop with the radiator discharging right back into the container. It was a test to see if the pump would work submerse in mineral oil, and guess what, it did! This way saves me having to prime the pump, but the flow is still kind of slow, and it still cuts out if I try to jack up its speed; but it works! I even ran it overnight to make sure. Sooo where does this leave me now? Well I may or may not try to use this setup again (different aquarium), but probably on the November miner, as its VRMs need the cooling more than the October does at this point. I will talk more about the new setup I am thinking about after the tuning section next.

 

Jupiter Nov/Oct Tuning

Ok, now the part most are probably waiting for anyways. Cranking up your Jupiter’s for MAX performance! I will start with the October, as it is a little “simpler” to tune. I do want to note, that your Jupiter’s performance will definitely vary, has there seems to some variance of hardware out there. I count myself pretty lucky, as both of my Jupiter’s are second hand, but I don’t have any major issues with them at this point. I think that is primarily due to the both the prior owners telling they never overclocked them, riggghhtt… They said they just plugged them in and forgot about them, until it became unprofitable for them to run them, and now they are mine =).

Ok, starting with the October, I have 4 modules total, that have the 4 VRMs install on each modules, and I have the 4 port beagle board. I also loaded up firmware v1.01-BERTMOD edition/version. You will need this to help you see in detail what your modules are doing. Like I said, I didn’t have any issues with this one, as it was configure to default values when I got it, and it mined just fine around 520 G/h-ish. I also want to note that it came with two Antec 650watt PSUs from the owner, so I had 2 modules per PSU. I make note of that because, as you OC these miners, your power usage goes up as well, and you can surpass the capabilities of your PSU if you are not careful. This happen with my November, as the PSU would shut off when I OC’d too much, but I fixed that with adding a second PSU.

 

One more thing, I did a lot of searching on hardware errors and FPGA messages these miners can have, and I believe they are related, in regards to tuning. Depending if you use CGminer or BFGminer, these errors are referenced a little different when you are observing them in the SSH terminal screen. CGminer uses messages like “hardware errors” and “FPGA submitted…blah blah” to communicate issues. BFGMiner uses “hwerrs” for hardware errors, but I don’t know what it uses for the FPGA errrors messages, and I think it doesn’t actually send messages out for that like CGMiner does. Oh yea, you have to enable SSH first before you can do effective tuning. Once you enable SSH in the “Services” tab in the web interface, get a SSH frontend (like Putty) and direct it to your miners IP address. Once you login, type in “screen -r”, and hit enter. If your miner has been running already for a bit, it should be pull the CGMiner/BFGMiner screens and show you whats going on. If you just restarted/turned on the miner, it will take a few minutes for the CGMiner/BFGminer software to actually start running, and for you to actually be able to login and see their results.

 

Next, the technicals on the modules. Each ASIC is made up of 192 cores, so that comes out to 768 cores total of processing units between all four. That then comes out to about 650 M/h-ish per core on the October. These cores are the bread and butter of the miner, and these are the things you affecting when your OC’ing or adjusting VRM voltages on the modules. So with that said, most of my issues have been with dealing with bad cores, or at least with my October. Moving forward, please understand that CGminer/BFGminer will shut down faulty cores on their own(after 10 HW errors in a row), but will turn them on again after some time. This will cause your hardware fault counter to creep up, which seems to contribute to your Jupiter losing hash power over time. It has been noted on the Interweb that the FPGA errors have that negative effect as well, and my goal in all this was to maximize speed while eliminating HW/FPGA errors, which in turn will raise your average hash rate up overall.

Ok, the first step of the Jupiter Mining Club is…we don’t talk about Jupiter Mining Club! Haha j/k…ok the real first step is getting your miner’s heat under control. I am also assuming your PSUs have extra capacity to cope with the larger power draw due to OC'ing already, which naturally will make more heat in turn. You can search the Interweb on the many ways of cooling these miners, like taking the cover off, rerouting the air channels inside, or immerse them in mineral oil! =) Just FYI, heat has been noted to cause those FPGA errors by other Jupiter owners. Anyways, whatever the route you go, make sure your ASICs stay out of the 80 C degree range at least and also make sure your VRMs are getting air too, as those will shut off if you OC too much; as that forces more power though them. I actually bought small RAM chip coolers that adhere to the top of VRMs and that helped some, but you still need to get air over them. Once you have your heat situation under control, we can now move on to the actually tuning of the ASICs.

If you don’t use BFGminer on you miner currently, you are going to have to for these next steps, as it will make it waaaaaay easier to tune your ASICs. You can find the option in the “Mining” tab in the web interface. The reason for this is that BFGminer can control the individual cores and it also lists the hardware errors per ASIC as well, both will help you narrow down bad cores.

Alright, go ahead connect to a stable and reliable mining pool and then SSH in to your miner and bring up BFGminer’s screen. If you are lucky, you will see zero hardware errors at this point, since you should be at the default configuration for your miner. However, if you are getting hardware errors, you should see them in the status window of BFGminer. Make note of the ones that pop up in the running status log, you will need that info later, but keep in mind you might have to wait a few minutes to see what cores BFGminer disables. Then open to the “Advance” tab in the miner’s web interface. There you will see your ASIC temps and how much current/power is going through your VRMs. There is a temperature column for the VRMs there as well, but it is blank on my miner, but I am not sure if that is the way it is supposed on Octobers. So you should have the Advance tab open and the SSH window open, so you can see both, so let’s get to tuning!

The first step is setting a base line for your ASICs, and you can do this one module at a time, or on all four at the same time. You don’t necessary need to physically disconnect the modules from the beagle board, but I recommend just focusing on one module at a time. First, if the ASIC doesn’t have any hardware errors, then you can start adjusting the frequency/voltage on each of the ASIC’s die. Luckily you can see the recommend limits on OC’ing for both the October and November version right there in the top of the "Advance" tab window. I would say those are you ideal goals, but not every module is capable of getting OC’d to those levels, sorry.

 

Now it is worth explaining the format of the hardware errors BFGminer throws before we move on. You will see something like “3dx disabled” when that core gives to many hardware errors. The “3” designates is what ASIC module it is (0-3 = 1-4, referring to the number of modules installed), the “dx” designates what core among the 4 dies (768 cores total, remember?) that is having the issue. This is useful to know when you are tweaking the VRMs of the individual dies. The core designators use only alpha characters. So for example, “1aa” would mean ASIC module #2 (meaning phyical #2 connection on the beagle board), core 0, and “1ab”, would mean ASIC module 1, core 1, and so on and so forth. Once you hit “1az”, it would flip over to “1ba”, all the way to "1hj". Remember that each die has 192 cores, and each ASIC have 4 dies on them, so now you can use those error designators to figure out what die the has core in question.

Ok with that out of the way, make notes of all the hardware (HW) errors you are having and start with the first module that is throwing hardware errors. I would then go to the “Advance” tab in the web interface and set that module’s frequency to 400MHz and you can leave the voltages in the default level, which I think is -0.1099v…Click the “Apply Changes” button at the bottom of the page. That will disconnect your BFGminer screen in the SSH terminal window. Wait 45 seconds-ish and try reconnecting to the SSH frontend to the BFGminer screen. If it won’t connect, try again in a few seconds, as BFGminer didn’t restart completely yet. Hopefully, if you had HW errors before, they should be all gone on that module. If not, you might have some bad cores. If you have truly bad cores, no matter what frequency or voltage you set, they will always generate errors. If you are “lucky” they will generate enough errors and be automatically shut down by BFGminer (BFG), and you can just easily annotate the core designator that gets flagged. You can also hit "d", and then "z" to zero out all the stats in BFGminer, which will also clear out all the prior HW errors for you. You will use this a lot as you tune, to easily see if what you are doing is working. Additionally, You then have to manually shut the core down in BFGminer for it not to be enabled again, potential slowing your miner down with the heehawing of being turned off and on again by BFG as it mines. To turn off/on the cores manually in BFG, hit the “m” key and then hit the “/” key. You will be prompted for the core designator. For example, if you have “3dx”, you will have to enter “KNC 3dx” and it will bring that specific core’s info up in a section just under the main status window of BFGminer. It took me forever to figure out to put the “KNC” in front, because if you don’t, BFGminer will freak out and say a million times that that core is not found. So, I just now saved you some headaches =). Also, you can scroll through every core using the up/down keys after you hit "m", which is useful if you have HW errors scattered across your dies, but not enough for BFGminer to actually shut them down and identify the core for you. So once you see the info on that specific core, you are going to look at the right side of the BFGminer window, and it will list that individual core’s HW errors. If you “lucky” again, your total HW error rate in the main BFG window for the module in question and the individual core’s HW error rate will be the same. This means that this single core is causing all your HW errors on that ASIC, and you can shut it down in BFGminer manually to take it out of the equation. After you do that for all your bad cores, you can now start ramping up the frequency in whatever steps you want, just make sure to recheck for HW errors each time. I would also wait a few minutes as the miner warms up again after each restart, as that might expose more HW errors. This whole process will take TIME, you can’t rush this, as you are trying to stamp out all HW errors. Expect at least a couple hours to get through all your modules properly. So as you get higher in frequency, and HW errors start popping up again, you can try adjusting the voltage levels on the dies in question to see if you can get rid of them. With the October miner, the ideal voltage level for the dies is -0.1099v and going higher not only saves you power/heat, it might even fix your errors. But be cautious going UP to zero volts, as you run the risk of having the VRMs shutting down on you and having the dies/ASIC in question being disabled. I think the highest I can go is -0.0293v on any particular die in my October, before that exact thing happens. Just remember you are trying to stamp out HW errors by adjusting the voltage, and you should have success doing so as you increase the frequency to the max mentioned for the October’s at the top of the “Advance” page. If you are lucky, by using these steps, you can disable bad cores, and adjust the voltages as needed, to get to the highest frequency possible, with ZERO HW errors. Please note, if you restart BFGminer for any reason, you have to disable your bad cores again, so you can keep their HW errors from hiding others that might pop up. Also, don’t fret about having to disable a couple of cores at higher frequencies, as the lost hash power for a couple of cores out of 768 will be a moot point over the combined hash power of the working cores churning at high speed.

 

So using this process, I ended up getting two modules completely HW error free and slightly OC’d. I tried to do more OC’ing on them, but it was the maxing out the associated VRMs and they were getting to hot and shutting off, so I scaled it back a little bit to get stable speed and keep the VRMs on. However, I couldn’t clear the other two modules HW errors completely, which is a little disappointing. But I managed to massage those modules die’s voltages to get barely a trickle of HW errors on both modules. The additional compromise on those was I couldn’t OC them much beyond stock either without driving up the HW errors. I am not sure what is causing the random HW errors on those two ASICs, but it isn’t affecting my October’s overall hashing speed anyways. As it stands my October is chugging along at a solid 620 G/h with all this tuning, and only the overheating VRMs limiting the OC’ing of the other two “good” ASICs further.

Now for my November Jupiter miner. I have the 4 module version, and the all the modules have 8 VRMs each, and I have the v1.01-BERTMOD firmware on this one as well. I used the same process above of course, but the Novembers are more forgiving on the OC’ing aspect. BUT there is one important difference between the two when it comes to tuning. The Novembers start out at 0.0V, and you work your way down from that point while tuning, until you start hitting HW errors of course. The Octobers start at a way less voltage than 0.0V and the closer you get to 0.0V, you will run into problems. I don't know why the difference in operating voltages between the Novembers and Octobers, but I am guessing it has to do with the different VRMs each use. Anyways, the nice thing about my November, is that I got all 4 modules to have ZERO HW errors! That is great, considering it has a single die that can't go past 775 Mhz for some reason, without taking a shit on itself instantly. I have it chugging along at around 920 G/h when Westhash.com cooperates, and I think I can hit the 1 T/h mark with proper cooling. I can almost smell the mineral oil again! =) My major challenge with this one is the heat it makes! It is probably cranking out 1000 watts between the two 750watt PSUs I have running it if you add it all up at least, and I had to adjust down some dies' frequencies just to keep the ASICs under 80 C degrees and the VRMs from overheating. This is because this unit is in an external room from my house, which basically puts running at the ambient air temperature outside, and it is hot here still. The room it is in is normally at 40 C degrees because of the heat it pumps out. Well, it is out there because of the fan noise it makes and the heat coming out of it, and so there is no place for it inside the house because of those factors. I am really looking forward to it cooling down here, as I am sure I can OC it some more once that happens, and maybe hit 1 T/h.

Well that is pretty much what I got going on with my Jupiters. Hopefully you could follow my instructions and get the most you can out of your Jupiters. Feel very to comment to correct any gross errors and to ask for clarification.

 

Conclusion

 

I have some final commentary on all of this and some discussion on my next move. First, be careful with OC'ing these units (especially the November), as the power usage increase significantly. Since I got all mine second hand, I am not sure if I could do any warranty repairs if either of the Jupiter's crap out/burn up on me, since I don't have any purchase receipt. Also, I had one of the 6-pin power cables burn up on me in my November miner, as I was an idiot on how I hookup it up to my PSU. Long story short, I used a molex to pci-e 6 pin power adapter to power one of my November's modules. Needless to say after I OC'd the module in question, the 200+ watts going through that adapter lasted a week I think before it burned up, melting the connector end of module power cable with it! Luckily, it was the end that hooked up to the adapter in question, so the damage was minimal. I have to hook my PSU direct to the module now, which is no big deal, and if anything is actually better. It limits the chances of that same kind of problem happening again.

Next, about the mineral oil cooling conundrum I am in. While I am a little jaded over my October mineral cooling FAILURE, I think I am going to re-attack it with my November. As I said earlier, the November had the most the gain at this point I think, as the VRMs heating issues are holding me back at this point. I really want to hit that 1 T/h mark =). I think I can hit it by doing the mineral oil cooling, but I have to do it right this time.

 

As I was shopping for a aquarium originally, I found a cube shape one that would completely immerse the 4 modules, but I decided against it because of whatever reason then. Well my plan now is to connect the corners of the 4 modules cards together and make a cube of hashing POWER! In the center of the modules, I will have the pump, and I will have my radiator hanging off the side of the aquarium, to keep the tubing as short as possible. I just know that the November cranks out 1000+ watts and that little 120mm radiator is no match for that, but it would look cool as hell I think. There are radiators that would work, but they have room for nine 120mm fans, just to give you an idea how big they are! Really, I will probably do the October again in mineral oil, has I need to find a home for it in the house. I can't put outside with the November, because that is only on 15amp rated receptacle, and even though that receptacle is on a 20 amp (2400 watt) circuit (see my GPU mining post), I don't want to chance a fire. The other thing I need to research is if I have the right pump for the job. There are other Swiftech pumps that may have higher flow and what not I can use. What should I do??? ..........eh, what's that you say?, "Mineral oil it man!"....ok you had me at "min.."! To be continued...

***UPDATED 15SEP14***

...and I am back! So yea, I got my cube of power set up, no waiting here! As you read, I had pretty much everything I needed already, I just needed a cube shaped aquarium to try my new plan. There was a perfect sized one off-base and I got, along with more mineral oil...I wiped out the BX's stock again, sorry!

So how did it go? Well first off, it was a way more "clean" endeavor than last time. I knew-ish what I was doing, so it was just a matter of getting everything hooked up. Did it work? NOPE! dammit !!!! aaaahhhhh! BUT this time I know why, and in short, I am not going to try this again....ever!

I am going to sum it up like this...

1.  The whole pump/radiator setup works, but I need more flow and a bigger radiator to truly keep the mineral oil temps in check. I couldn't run the rig for long, as the ASICs would overheat and turn off, making my PSUs shut off too. I actually hooked up my pump/radiator to just flow water as a test, and surprisingly the pump worked great at max speed (it didn't shut itself off). It just won't work at max speed immersed in mineral oil and I have no idea why, and I don't care to find out at this point.

2.  Hot spots will kill you fool, or your ASIC at least! I think this is basically the MAIN reason why mineral oil cooling is not working at this point and it will never will.  The miner would boot up and start mining, but after a few seconds it would freeze/crash basically. What was happening was the ASICs were basically going from hot to SUPER hot in seconds and the modules shut them down, which it is designed to do. I found some good websites that talk about this issue and I am not going to try to summarize it all here, just read this sites and save yourself the headache you will get trying this mineral oil cooling thing. It basically has to do with the fact the ASICs have all their little pins on the back side of them and the oil can't flow around there that well, so the heat just builds and builds. Surprisingly air is great in that regard, as it can flow under the ASICs just fine. Just read the links below and understand now that you are NOT better than physics, and the same thing that happened to me, will HAPPEN to you! =)

So as it stands, my modules are in my oven now cooking, and the mineral oil is leeching out of them as I type this. If the modules were designed differently, like have their back sealed to the board, kinds like SMD type circuits, then the mineral oil thing might actually work fine with proper flow of the mineral oil. But they aren't designed that way, they were designed for air cooling, so there is no point of going this route. I wish I knew that before though! Well does anyone out there need some aquariums? they are lightly used, but slippery as hell! =)

Moving forward I figure I can go some crazy water block cooling route for the ASICs, but I would need to do it for the for the VRMs too, as those are the ones that are really limiting me from OC'ing more. I least I could reuse the pump/radiator still. I wish I could say it was "fun", but I did learn a lot, and hopefully you can crank out some more giga hashes out of your Jupiters too.

Links:

LIQUID SUBMERSION - a few helpful learned facts

What would be the best pump/rad for mineral oil pc

***UPDATED 23NOV14***

Ok, this may be the last update to this page as I think squeezed as much performance out of my Jupiter's than I can at this point. However, after I wrote this, my priorities changed to saving power, as opposed to all out performance, and here is why. I had before both Jupiter's in different rooms, which also meant they were on different electrical circuits. I knew I couldn't have them both on a 15amp socket when they were overclocked since that would of burned out the socket, so I but one in a room in the house (Oct). Everything was fine, I just got tired of having that room in the house way warmer than the rest of house and the fan noise got to me. So I decided that BOTH have to be outside! Well, having both at stock speeds, they would have been fine both plugged into the 15amp plug, but I would have lost about 400 G/h doing that (no bueno!). So I didn't complete opposite of what I did in this write-up, and tried to be the most power efficient I could, while still overclocking the Jupiter's.

This was pretty straight forward actually, you just do the opposite of my instructions above, but here is what I did in general.

I put both at stock voltages/speeds. I then took a baseline with my wattmeter and aimed to keep both pulling no more than 1800 watts off the socket (15amps @ 120v). I did this by dropping the die voltages to the lowest level they would go, before they starting throwing hardware errors. Once that happened, I would then back off the die voltage a step, and then adjust the die frequencies up one step. I would observe for hardware errors, and if there were none, I would move up the die frequencies one more step. Surprisingly, I was able to move up the frequency steps some ways, without having to move the die voltages up to much. However, there comes a point where your next frequency steps take a couple of steps of die voltage increases to run with no hardware errors. Basically the efficiency factor starts going down, and you are getting less overall speed for the amount of increased power consumption by the Jupiter's, which wasn't my goal.

So, after hours of tuning my Jupiters, I managed to get them consuming just a hair over 1800 watts total, with a new overall speed of about 1400 G/h. That is just about 150 G/h less than I had them before, but they run with even less hardware errors, and even less heat to boot! I feel this is a ok compromise on profit (a dollar and some change less a day), for having them out of sight out and out of mind now. Well, if I end up getting more hardware in the future (which I am sure), I need to figure out where am I going to put it all now since that circuit the Jupiter's are on is maxed out...