ANTMINER S3+ Discussion and Support Thread

[TrevorS]

Hello. I have some info that may help regarding power supplies.

Corsair CX600M ____  Melted some  plugs at the PSU connection when overclocked S1's to 393.75. I changed the plugs to a higher quality and it worked. I will run an S3+ at 225.

Corsair CX600 ______Runs overlocked S1's all day long with no problems. Also will easily run an  S3+. Did not try overclocked S3+. Does not shut down easily from room temp.

Corsair CX500M _____Melted some plugs at the PSU connection running overclocked S1's. It will run an S3+ at 225. Did not try overclocked S3+.

Corsair CX500 ____ Will easily run overclocked S1's and S3+'s at 225.. They do shut down if room temp gets too hot but not all of them, just a few.

So for your money if you can keep the room cool, and winter is coming, the CX500's are the best deal. $50 shipped from Amazon or New Egg everyday. And they will run the new L1's.
Also I have 12 S1's all underclocked to 250 and I run 2 on each Corsair cx500. About 350 watts max is all it pulls and the 2 units hash combined is 250-280gh.

Edit.... The M or Modular power supplies are NO BUENO, no matter what the wattage because the plug connection  on the powers supply is a "weak spot" and creates resistance and heats up and melts the plug. No bueno.

FWIW -- I'm running CX750Ms using all four S3 PCI-E ports fed by two PCI-E cables (connectors closest the PSU) and two Molex cables (connectors closest the PSU) with dual Molex to PCI-E adapters.  An order for a used CX750M resulted in delivery of a CX750 (since returned).  I compared the two supplies on a single S3.  The CX750 has four individual PCI-E cables and so the comparison was between those four and my usual CX750M hookup.  The CX750M resulted in higher HASH numbers than the CX750 -- I'll stay with the Modular thanks !

[1714626627]

1714626627

[TrevorS]

Just gave a three star to an Amazon used PSU seller, but so far seemingly OK on S3s.  However, am wondering about Luke Jr's Eligius pool!  Only joined last week and first two payouts were a reasonable number of hours following my crossing the default threshold.  However, I'm now waiting several blocks in the payout queue with preceding total >90 BTC before my latest payout!  My question is how can a payout depend on significantly more than the currently completing block?  After 24 hours I'm still over a block behind.  Does that remind anyone else of a Ponzi scheme?  Why should multiple later blocks be required to pay off current blocks?

Try posting this in the Eligius thread. There are literally dozens of people who will gladly educate you in every arcane aspect of their payout methods. Lol. It's VERY confusing to say the least.

But without a doubt, Eligius is not a Ponzi scheme. They always keep plenty in reserve and make sure every block/payout is valid before they send out payment.

Just gave a three star to an Amazon used PSU seller, but so far seemingly OK on S3s.  However, am wondering about Luke Jr's Eligius pool!  Only joined last week and first two payouts were a reasonable number of hours following my crossing the default threshold.  However, am now waiting several blocks into the payout queue with preceding total >90 BTC before my latest payout!  My question is how can a payout depend on significantly more than the value of the currently discovering/verifying block?  After 24 hours I'm still over a block behind.  Does that remind anyone else of a Ponzi scheme?  Why should multiple later blocks be required to pay off current block earnings?

If u want your payouts asap dont use Eligius.

as person X in spot 10 waits for their payout you being in spot 20. spot 10's total keeps growing. so they keep taking away from the top and the leftovers trickle down to the next person. it is really annoying.
and THEN u must wait for your payout to mature in your wallet which is um I believe 100 blocks...

But without a doubt, Eligius is not a Ponzi scheme. They always keep plenty in reserve and make sure every block/payout is valid before they send out payment.

Eligius is a KNC scheme.
http://eligius.st/~wizkid057/newstats/userstats.php/1Nbq2XZaRsKknf5fcT2wTXvBS31PaUWSeX

Read more here http://forum.kncminer.com/forum/main-category/hardware/55746-strange-rma-experience

Thanks fellows, the unexpectedly lengthy delay on my third payout (not at all predicted by the page stats) just left me wondering if something was off.  If this is typical of the pool, that's fine, this is me learning !

PS. Wow!  That KNC influence is pretty impressive -- yeesh!

[TrevorS]

Interesting.  The problem hashing board now in my first S3 is working fine and very stable.  I just found there is a difference between my first well running S3 and the S3 that the problem board came out of, and that's is a different firmware on each.  I haven't found a way to determine while ssh'd in, e.g. opkg list | grep antMiner comes up a blank.  But, bruno033 pointed me to the firmware page and I see there the 0721.bin has a solid green light when running.  The first S3 from the mid-west has that.    When I saw that the S3 from Florida had a flashing green light when hashing I though I probably configured it differently than the first.  But it must mean the S3 I got from Florida has the 0711.bin firmware because the other later options are the 0811.bin and the 0826.bin, both of which will have the Advanced Frequency change option on the miner configuration page.  So, the questionable board is very stable at this point in the S3 having the 0721.bin firmware.  Time will tell if it remains at 441 overnight as the humidity rises, e.g. right now the rh is 30%.

soy

S3 GUI Status/Overview shows the firmware version.  2nd is Aug 7 and 3rd (S3+) is Aug 26.

[soy]

Interesting.  The problem hashing board now in my first S3 is working fine and very stable.  I just found there is a difference between my first well running S3 and the S3 that the problem board came out of, and that's is a different firmware on each.  I haven't found a way to determine while ssh'd in, e.g. opkg list | grep antMiner comes up a blank.  But, bruno033 pointed me to the firmware page and I see there the 0721.bin has a solid green light when running.  The first S3 from the mid-west has that.    When I saw that the S3 from Florida had a flashing green light when hashing I though I probably configured it differently than the first.  But it must mean the S3 I got from Florida has the 0711.bin firmware because the other later options are the 0811.bin and the 0826.bin, both of which will have the Advanced Frequency change option on the miner configuration page.  So, the questionable board is very stable at this point in the S3 having the 0721.bin firmware.  Time will tell if it remains at 441 overnight as the humidity rises, e.g. right now the rh is 30%.

soy

S3 GUI Status/Overview shows the firmware version.  2nd is Aug 7 and 3rd (S3+) is Aug 26.

Both S3+'s have the Aug 26 but both the S3's have OpenWrt Barrier Breaker r38031 / LuCI Trunk (svn-r9909) and although the two S3's have that identically they have different green LED functionality.

[TrevorS]

Interesting.  The problem hashing board now in my first S3 is working fine and very stable.  I just found there is a difference between my first well running S3 and the S3 that the problem board came out of, and that's is a different firmware on each.  I haven't found a way to determine while ssh'd in, e.g. opkg list | grep antMiner comes up a blank.  But, bruno033 pointed me to the firmware page and I see there the 0721.bin has a solid green light when running.  The first S3 from the mid-west has that.    When I saw that the S3 from Florida had a flashing green light when hashing I though I probably configured it differently than the first.  But it must mean the S3 I got from Florida has the 0711.bin firmware because the other later options are the 0811.bin and the 0826.bin, both of which will have the Advanced Frequency change option on the miner configuration page.  So, the questionable board is very stable at this point in the S3 having the 0721.bin firmware.  Time will tell if it remains at 441 overnight as the humidity rises, e.g. right now the rh is 30%.

soy

S3 GUI Status/Overview shows the firmware version.  2nd is Aug 7 and 3rd (S3+) is Aug 26.

Both S3+'s have the Aug 26 but both the S3's have OpenWrt Barrier Breaker r38031 / LuCI Trunk (svn-r9909) and although the two S3's have that identically they have different green LED functionality.

The "OpenWrt Barrier ..." FW is the OE supplied version (pre-installed on most of my used S3s), not sure when the break took place.  I switched to Aug 7 as I checked them out, and most recently to Aug 26 plus the 4.6.0 CGminer.  Don't know what to say regarding green LED behavior, can't say I've taken note of it except to verify the S3s were communicating.  In my home LAN experience, a normal LAN connection displays a frequently blinking green LED.

[soy]

Interesting.  The problem hashing board now in my first S3 is working fine and very stable.  I just found there is a difference between my first well running S3 and the S3 that the problem board came out of, and that's is a different firmware on each.  I haven't found a way to determine while ssh'd in, e.g. opkg list | grep antMiner comes up a blank.  But, bruno033 pointed me to the firmware page and I see there the 0721.bin has a solid green light when running.  The first S3 from the mid-west has that.    When I saw that the S3 from Florida had a flashing green light when hashing I though I probably configured it differently than the first.  But it must mean the S3 I got from Florida has the 0711.bin firmware because the other later options are the 0811.bin and the 0826.bin, both of which will have the Advanced Frequency change option on the miner configuration page.  So, the questionable board is very stable at this point in the S3 having the 0721.bin firmware.  Time will tell if it remains at 441 overnight as the humidity rises, e.g. right now the rh is 30%.

soy

Disappointment.  The problem board now in a good S3 this morning is down to 431.45GH/s after 22 hours.  Will swap boards to their originating S3's today and upgrade beyond the OpenWrt Barrier Breaker r38031 / LuCI Trunk (svn-r9909) firmware. 

[LordTheron]

One of my S3 got bricked during firmware update, browser just crashed randomly. How do I fix it?

[moss]

My S3 is running virtually silent now. l replaced the stock fan at the front (the end with the network connector) with a Corsair SP120 fan blowing in and removed the rear fan entirely. The fan is running at 1920 rpm with 48/48 temps, ambient is 23C.. S3 is overclocked to 225. Maybe won't work so good in hotter countries but here in Uk with summer over should be okay for the next 6 months

The Corsair SP120 is a good fan for the inlet, but there's no way I would remove the outlet fan entirely.  I think that's just pushing things too much, hence the high temps.  With an SP120 inlet and something like a Thermalright TR-TY143 on the outlet (only £6.99 from Amazon UK), you'll get those temps down, whilst keeping things nice and quiet at the same time.

[Gws24]

The power supply (corsair rm850) I bought to run the 2 s3+ I ordered comes with 3x 8 pin to 6+2 pin pci-e cables and I obviously need 4. I do have an 6 pin to 6+2 pin pci-e cable from an old psu, can I use that as the 4th cable? As far as I can tell from the pinouts below it should work but i'm not sure.



edit: I mean connect the 6+2 pin on the psu side and the 6 pin on the s3 side?

[soy]

Interesting.  The problem hashing board now in my first S3 is working fine and very stable.  I just found there is a difference between my first well running S3 and the S3 that the problem board came out of, and that's is a different firmware on each.  I haven't found a way to determine while ssh'd in, e.g. opkg list | grep antMiner comes up a blank.  But, bruno033 pointed me to the firmware page and I see there the 0721.bin has a solid green light when running.  The first S3 from the mid-west has that.    When I saw that the S3 from Florida had a flashing green light when hashing I though I probably configured it differently than the first.  But it must mean the S3 I got from Florida has the 0711.bin firmware because the other later options are the 0811.bin and the 0826.bin, both of which will have the Advanced Frequency change option on the miner configuration page.  So, the questionable board is very stable at this point in the S3 having the 0721.bin firmware.  Time will tell if it remains at 441 overnight as the humidity rises, e.g. right now the rh is 30%.

soy

Disappointment.  The problem board now in a good S3 this morning is down to 431.45GH/s after 22 hours.  Will swap boards to their originating S3's today and upgrade beyond the OpenWrt Barrier Breaker r38031 / LuCI Trunk (svn-r9909) firmware.  

Just now have both S3's back up and running with their original boards.  The fast fan good board from the good S3, I should note the hashing boards had QC Passed stickers the later S3 from Florida didn't.  The good board with a fast fan from the good unit which brought its fast fan rate to the questionable unit when moved yesterday, I took apart and reapplied new thermal compound.  I found the temperature sensing IC to be in the center between the two rows of ASICs, an LM75A.  So running lines of compound along the top ASICs and again along the bottom but not the center wold tend to prevent the heatsink from cooling the device and result in faster fan rates.  The surface mount device below the fan connection and above the upper left ASIC is a 25.000 crystal.  This good board had excellent compound.  Only worked on one of the two as I've run out of compound.  Of the board I put back in the questionable unit, I cleaned the ASIC pins but ran out of cleaning fluid so reassembled with new paste.  The fan to the questionable board still remains relatively slow.  I'd like to see that higher.  I'll wait to see how these settle out then upgrade the firmware.

The good board from the good S3 not only had a QC sticker but also had handwriting on the right side of the board between the ASICs, an "A" and another "A" or perhaps one was an A1.  The questionable board had what looked like an "S" and a lower case "o".  These letters were vertical after the fashion of oriental script.

[Stratobitz]

Is there a fairly simple way to create a redirect stratum address, perhaps one that is on an internal computer on my network, that I could point multiple AntMiners to. 

The point being to easily change the mining pool address, worker, password, and difficulty, at just one place, and all miners would then switch to the new address?

Or if there is an easier way, is there a way to mass update settings on a multiple AntMiners all at once? 

Many thanks!

Strato

[soy]

Interesting.  The problem hashing board now in my first S3 is working fine and very stable.  I just found there is a difference between my first well running S3 and the S3 that the problem board came out of, and that's is a different firmware on each.  I haven't found a way to determine while ssh'd in, e.g. opkg list | grep antMiner comes up a blank.  But, bruno033 pointed me to the firmware page and I see there the 0721.bin has a solid green light when running.  The first S3 from the mid-west has that.    When I saw that the S3 from Florida had a flashing green light when hashing I though I probably configured it differently than the first.  But it must mean the S3 I got from Florida has the 0711.bin firmware because the other later options are the 0811.bin and the 0826.bin, both of which will have the Advanced Frequency change option on the miner configuration page.  So, the questionable board is very stable at this point in the S3 having the 0721.bin firmware.  Time will tell if it remains at 441 overnight as the humidity rises, e.g. right now the rh is 30%.

soy

Disappointment.  The problem board now in a good S3 this morning is down to 431.45GH/s after 22 hours.  Will swap boards to their originating S3's today and upgrade beyond the OpenWrt Barrier Breaker r38031 / LuCI Trunk (svn-r9909) firmware.  

Just now have both S3's back up and running with their original boards.  The fast fan good board from the good S3, I should note the hashing boards had QC Passed stickers the later S3 from Florida didn't.  The good board with a fast fan from the good unit which brought its fast fan rate to the questionable unit when moved yesterday, I took apart and reapplied new thermal compound.  I found the temperature sensing IC to be in the center between the two rows of ASICs, an LM75A.  So running lines of compound along the top ASICs and again along the bottom but not the center wold tend to prevent the heatsink from cooling the device and result in faster fan rates.  The surface mount device below the fan connection and above the upper left ASIC is a 25.000 crystal.  This good board had excellent compound.  Only worked on one of the two as I've run out of compound.  Of the board I put back in the questionable unit, I cleaned the ASIC pins but ran out of cleaning fluid so reassembled with new paste.  The fan to the questionable board still remains relatively slow.  I'd like to see that higher.  I'll wait to see how these settle out then upgrade the firmware.

The good board from the good S3 not only had a QC sticker but also had handwriting on the right side of the board between the ASICs, an "A" and another "A" or perhaps one was an A1.  The questionable board had what looked like an "S" and a lower case "o".  These letters were vertical after the fashion of oriental script.

The good S3 came up to 441GH/s avg within an hour while the questionable S3 from Florida was only hitting 100GH/s.  Not one with a whole lot of patience, I decided to install the 0811.bin firmware on the questionable S3.  Did.  Then worried a bit as it was only doing 10GH/s avg for some time. I restarted cgminer (/etc/init.d/cgminer stop, /etc/init.d/cgminer start) and there was no apparent improvement.  Then I noticed there was no frequency listed on the status page so of course into the new Advanced tab on miner config, I specified the default and saved.  Up 6 minutes now and in the 400's GH/s.  Time will tell.

...Now over an hour and the S3 from Florida, having the 0811.bin firmware, seems to have settled out at 435.65GH/s.  What would explain this and its low fan speed is if an ASIC near the LM75A has some engines turned off - perhaps it had overheated at some point and damaged one.  I have noticed that the lower center ASICs under the LM75A tend to have drier thermal paste than other ASICs.  Center of the hashing board.  The curve of the inside heatsink fins and the direction of spin on the fans seems the reason one board, the top chain, gets hotter and has the faster fan speed.

If an ASIC near the LM75A is damaged and turns off engines, it gives the system an inaccurate assessment of the board's temperature.  ASICs toward either end working properly will be running hot.

...their logic that the lower hashing board should be on the cooler side made sense so it's been torn down again, end plates reversed, fans reversed, controller board moved to the other end, and reassembled.  Now coming up.





Florida, land of the floating chads.

[TrevorS]

One of my S3 got bricked during firmware update, browser just crashed randomly. How do I fix it?

What actually happened -- power failure during flash or something else?  If something else, then what and wired LAN or wireless LAN?

In any case, the only thing we can try without Bitmain intervention is resetting via the button to immediate right of the RJ-45 connector.  If it can't be reset, then the FW is damaged and needs technical assistance.

PS.  It's recommended never to use a wireless connection for flashing equipment.  Too much likelihood of dropouts.

[tonyec99]

  l took your advice and ordered the Thermalright TR-TY143...  Just out of interest I'd like to add that I think discussions about temperatures on this forum are a little over-hyped. 50C is a perfectly acceptable temperature for an asic to run at. Note that the menu shutdown temperature default is 80C. I worked for a computer manufacuturer and regularly changed ic's using hot-air guns where temperaturers attained hundreds of degrees C during the process and it never caused problems. You'd be surprised how much abuse ics can take. It's over-voltage kills them, not overheating.

[pekatete]

...  Then worried a bit as it was only doing 10GH/s avg for some time.

Reboot the S3 via SSH (not sure whether this works via the GUI).
If you noticed when this happened, it also had an uptime that started before you restarted cgminer. This happened to me (and I was able to replicate) after installing cgminer 4.6, but a reboot via SSH "clears" the  relic numbers. the downside to not having a clean slate for your circumstances is that you will not have accurate uptime hashing speed(s).

[chipxtreme]

Anyone using Enermax Platimax 1500W power supplies? Got one lying around gathering dust and currently use an EVGA 1000W, EVGA 1300W and SilverStone 1200W power supplies running 8 S3's. Was thinking of switching 4 to the Platimax to save a bit energy as the power bill is quite big here in UK.

[ZiG]

Is there a fairly simple way to create a redirect stratum address, perhaps one that is on an internal computer on my network, that I could point multiple AntMiners to.  

The point being to easily change the mining pool address, worker, password, and difficulty, at just one place, and all miners would then switch to the new address?

Or if there is an easier way, is there a way to mass update settings on a multiple AntMiners all at once?  

Many thanks!

Strato

Yeap...This is how BitMain is running their AntMiner's farm...

1...Run a Stratum Proxy .exe on a separate computer ...look at Slush pool for .exe file...
2...Let's assume that this computer with running proxy is @ 192.168.1.100 ...point all AntMiners at this address...
3...You done ...

ZiG  

[soy]

...  Then worried a bit as it was only doing 10GH/s avg for some time.

Reboot the S3 via SSH (not sure whether this works via the GUI).
If you noticed when this happened, it also had an uptime that started before you restarted cgminer. This happened to me (and I was able to replicate) after installing cgminer 4.6, but a reboot via SSH "clears" the  relic numbers. the downside to not having a clean slate for your circumstances is that you will not have accurate uptime hashing speed(s).

I agree but find that stopping/starting /etc/init.d/cgminer gets a clean time and doesn't cause the ssh to disconnect.

[soy]

Is there a fairly simple way to create a redirect stratum address, perhaps one that is on an internal computer on my network, that I could point multiple AntMiners to.  

The point being to easily change the mining pool address, worker, password, and difficulty, at just one place, and all miners would then switch to the new address?

Or if there is an easier way, is there a way to mass update settings on a multiple AntMiners all at once?  

Many thanks!

Strato

Yeap...This is how BitMain is running their AntMiner's farm...

1...Run a Stratum Proxy .exe on a separate computer ...look at Slush pool for .exe file...
2...Let's assume that this computer with running proxy is @ 192.168.1.100 ...point all AntMiners at this address...
3...You done ...

ZiG  

Have done this often but this is good only for changing to different IP addresses of the same pool, not for different pools as you run into a credential problemo and need to go into each cgminer or bfgminer and change credentials.

The miners that use the stratum have their credentials. 

I wonder if each antMiner has a stratum capability to act as a proxy for other machines.

[soy]

The good S3 came up to 441GH/s avg within an hour while the questionable S3 from Florida was only hitting 100GH/s.  Not one with a whole lot of patience, I decided to install the 0811.bin firmware on the questionable S3.  Did.  Then worried a bit as it was only doing 10GH/s avg for some time. I restarted cgminer (/etc/init.d/cgminer stop, /etc/init.d/cgminer start) and there was no apparent improvement.  Then I noticed there was no frequency listed on the status page so of course into the new Advanced tab on miner config, I specified the default and saved.  Up 6 minutes now and in the 400's GH/s.  Time will tell.

...Now over an hour and the S3 from Florida, having the 0811.bin firmware, seems to have settled out at 435.65GH/s.  What would explain this and its low fan speed is if an ASIC near the LM75A has some engines turned off - perhaps it had overheated at some point and damaged one.  I have noticed that the lower center ASICs under the LM75A tend to have drier thermal paste than other ASICs.  Center of the hashing board.  The curve of the inside heatsink fins and the direction of spin on the fans seems the reason one board, the top chain, gets hotter and has the faster fan speed.

If an ASIC near the LM75A is damaged and turns off engines, it gives the system an inaccurate assessment of the board's temperature.  ASICs toward either end working properly will be running hot.

...their logic that the lower hashing board should be on the cooler side made sense so it's been torn down again, end plates reversed, fans reversed, controller board moved to the other end, and reassembled.  Now coming up.





Florida, land of the floating chads.

Yes, this is better.  Before it barely got up to 435GH/s with the low hashing board on the right side when looking at the RJ45 connector end.  The right side is the top chain and generally has the higher temperature and faster fan.  In this case it had lower temperature and slower fan than the lower chain.  So, taking the end plates and their fans, swapping ends and moving the controller board, put it back the way it was shipped, the questionable board on the cooler side.  

Almost right away the average went above 441GH/s and has remained above 440GH/s for the last 3h 23m and is presently 442.04 tho the utility is only 15.  No hardware errors in that time.  It was started as the afternoon cooled.  It remains to be seen what happens tonight as the humidity increases.