ANTMINER S3+ Discussion and Support Thread

[takagari]

Most unit should be facing, the hashing PCB with 1 extra thin & short cable (NOT THE FAT DATA CABLE) to the control PCB is CHIAN 1

The PCB without the think cable is CHAIN 2

I would say double check the connections.

Power it off and let it sit for 5-10 minutes and power it back on, is another option that may work.

Else, hashing PCB or the port on control PCB could be bad, or the FAT Datacable.

Not so common but it does happen.

Edit: two part question

How do I know which blade is which, I seem to have two S3+ each with an offline or maybe dead blade, for now I'd like to put them together.

So take the top off, ethernet port facing me, looking down on it. is it 1 than 2, left to right, or 2 to 1?

Thank You!

Run the miner, the dead blade will be the one that's not hot.

Ah, good idea.
Is it common? maybe a lose cable to look for? or do blades drop out often?

Thank you

Oh, tried every angle of powering and powering off. lol. No joy, opening them up tomorrow.
Two S3's with downed blades.
and Two of them are not responding for the web interface, it starts to load than dies off, thoughts on that? it finds teh initial load page, than faults to no domain found?

[1715177863]

1715177863

[1715177863]

1715177863

[1715177863]

1715177863

[1715177863]

1715177863

[no141]

Most unit should be facing, the hashing PCB with 1 extra thin & short cable (NOT THE FAT DATA CABLE) to the control PCB is CHIAN 1

The PCB without the think cable is CHAIN 2

I would say double check the connections.

Power it off and let it sit for 5-10 minutes and power it back on, is another option that may work.

Else, hashing PCB or the port on control PCB could be bad, or the FAT Datacable.

Not so common but it does happen.

Edit: two part question

How do I know which blade is which, I seem to have two S3+ each with an offline or maybe dead blade, for now I'd like to put them together.

So take the top off, ethernet port facing me, looking down on it. is it 1 than 2, left to right, or 2 to 1?

Thank You!

Run the miner, the dead blade will be the one that's not hot.

Ah, good idea.
Is it common? maybe a lose cable to look for? or do blades drop out often?

Thank you

Oh, tried every angle of powering and powering off. lol. No joy, opening them up tomorrow.
Two S3's with downed blades.
and Two of them are not responding for the web interface, it starts to load than dies off, thoughts on that? it finds teh initial load page, than faults to no domain found?

On a low quality power supply, especially where the power lines get warm, it seems the blades do fail after a period of time. It doesn't seem permanent, as they run fine on a good power supply. Have you tried a different power supply or even two power supplies at once?

The web interface issue might be helped with a reflash or upgrade. As you can't use the web interface, you might have to find directions to update via an ssh session or maybe even ttp.

[MyRig]

web login or after the login to be no domain found, please try clearing all the cache files of the browser

[tave]

Hello
how i can turn off beeper in s3 (latest fw) when internet disconnected and miner not working?

Code:

Hostname	antMiner
Model	S3
Firmware Version	Fri Jan 9 20:41:34 CST 2015
Kernel Version	3.10.12
Local Time	Mon Mar 30 00:40:10 2015
Uptime	11h 14m 24s
Load Average	0.93, 0.85, 0.64

[soy]

Cold morning I decided to move another S3 into the living room and dial them both up to 237.5.  I brought #2 in, the problem S3 that I had increased the rear fan speed by opening the blue wire and tieing it to 12v.  Cgminer was showing quite a good speed on that fan.  That chain #2 however had the last ASIC showing an x.    I tried various methods like dialing down the power supply voltage to 11.95v, didn't help, restarting again with the voltage dialed up to 12.15v, still the x would appear. 

In early posts on this forum I said I had found that looking at the RJ45 connector the board on the right was chain #1 and left chain #2.  I forget how I figured that out then, never having only plugged in a single board.  Today I tried only a single board on an S3 and found some confusing results. 

Disconnecting the ribbon cable from the board on the left, the controller card got no power.  Only connecting the ribbon cable to the board on the left but not the right looking at the RJ45 connector end, the controller lit, the miner started and showed that hashing board, the one on the left, as chain #1. 

This confused the heck out of me and I of course need to know which board had the x.  Putting both boards in, the board on the left provides power to the controller and becomes chain #2 if there are two boards but is called chain #1 if only one board is present.  At least that's what I believe to be the case because with two boards in the miner, unplugging the fan controlled by the board on the left, that's the exhaust fan, and firing it up shows chain #2 fan as having 0 speed.

So, since the dragon chain was showing the last ASIC on chain #2 as x, and since the ASICs count starts near the fan connector, down, across, up, across, down, across, etc, the last ASIC was positioned at the top closest to the intake fan. 

I suspected that since I had the exhaust fan going full blast for weeks that perhaps the hard air had brought in some conductive debris that lodged on the fan side of the ASIC.

I cut down a 1" paint brush so instead of 1½" length bristles it has 3/4" bristles.  Taking off the outside heatsink of board #2 on the left, I cleaned off as much of the thermal paste from ASICs as I could then sprayed each with auto brake cleaner and used the paint brush to clean the pins and adjacent components as well as possible taking most care with the top ASIC closest to the fan.  Then after cleaning the heatsink and applying a small bit of thermal paste to each ASCI, I put the heatsink back in place and buttoned it up.

I started it off at 237.5M.  It's run 39 minutes and all ASICs look good but it's running slow, 412.45GH/s (avg).  Maybe it will improve, maybe it will run better at stock frequency, maybe it will run best at exactly 12v from the power supply, don't know.  But what I do see is that the x from the ASIC on top closest to the fan on that board is no longer an x.

[aarons6]

Hello
how i can turn off beeper in s3 (latest fw) when internet disconnected and miner not working?

Code:

Hostname	antMiner
Model	S3
Firmware Version	Fri Jan 9 20:41:34 CST 2015
Kernel Version	3.10.12
Local Time	Mon Mar 30 00:40:10 2015
Uptime	11h 14m 24s
Load Average	0.93, 0.85, 0.64

you cant.. what works is take the top off and put some duct tape over the speaker. you wont hear it anymore.

[adaseb]

How many of you have a S3 that have an "X" with some of the chips in the GUI panel. I noticed one of my S3+ started showing an "X" more and more. Usually restarting makes it go away but it returns after a few hours.

[no141]

How many of you have a S3 that have an "X" with some of the chips in the GUI panel. I noticed one of my S3+ started showing an "X" more and more. Usually restarting makes it go away but it returns after a few hours.

Sounds like you might need to take things apart, and clean the chips, then apply new paste and close her up. Also make sure the power lines aren't getting warm. I think it always has something to do with heat or not enough power.

[tave]

Hello
how i can turn off beeper in s3 (latest fw) when internet disconnected and miner not working?

Code:

Hostname	antMiner
Model	S3
Firmware Version	Fri Jan 9 20:41:34 CST 2015
Kernel Version	3.10.12
Local Time	Mon Mar 30 00:40:10 2015
Uptime	11h 14m 24s
Load Average	0.93, 0.85, 0.64

you cant.. what works is take the top off and put some duct tape over the speaker. you wont hear it anymore.

heem, but in  original firmware i see turn off beeper option, and it was ok.

- i cannot find speaker, can you show my with some photo?
thanks alot

[no141]

- i cannot find speaker, can you show my with some photo?
thanks alot

I would hope you don't need a photo. With the miner's cover off(it's held on with a bunch of little screws), you can see the top board. The speaker is the black round thing with the hole in the middle, next to the lan port, it's impossible to miss. If you went back to the first post of the thread, below is a pic I borrowed from there. You can see the speaker at the bottom, which is the top front(air intake) by the lan port.

[charles2k]

Which firmware for S3/S3+ is better?
October 13th
December 16th (now not available on Bitmain www)
December 19th (now not available on Bitmain www)
January 9th

What are the main difference between versions above?
Usually I use December 16th or 19th.
Your experiences?

[Darthswan]

Which firmware for S3/S3+ is better?
October 13th
December 16th (now not available on Bitmain www)
December 19th (now not available on Bitmain www)
January 9th

What are the main difference between versions above?
Usually I use December 16th or 19th.
Your experiences?

I have mine on the 16th or the 19th, can't remember.  I haven't had any problems.  I noticed my S3, act completely different than my S3+.

[soy]

Has anybody found a fix for falling hashrate on some S3's? 

The miners I bought from Bitmain directly don't fade in hashrate (two S3+'s, two C1's and an S5) and the first S3 I bought from Cryptocrane on Amazon has been great and arrived in an unopened box an doesn't fade.  The S3 I bought from Pines in Florida on Amazon has been ratty and arrived in an open box opened at the bottom and carelessly closed.  When I saw it functioned poorly I re-pasted but found that both hashboards had already been re-pasted (if the pasting technique found on the first S3 was the norm).  I do believe the hashboards on the S3 from Pines in Florida had been removed perhaps by grasping the PCIE connectors and indelicately forcing the hashboards off the heatsinks.

I cleared an x on chain 2 ASIC 16 yesterday by re-applying the thermal paste on the front after carefully cleaning with a brush and solvent.  That x does not reappear. 

Problem is the usual falling hashrate at stock frequency without x's or dashes appearing.

2hrs; 443.19; amb. temp. 72°; watts at the wall 387w
4hrs; 441.12; amb. temp. 67°; watts at the wall 361w
5hrs; 434.01; amb. temp. 65°; watts at the wall 358w
7hrs; 427.40; amb. temp. 63°; watts at the wall 360w

The falling temperatures as day passed into night should have improved operation and there was less wattage used indicating fewer logic errors from for instance impurities outputting electrons striking/firing transistor gates inappropriately but yet the hashrate fell.

When I was troubleshooting failed SMT boards, the senior tech and I disagreed often.  Aside from regional differences, I'm not native to this area, he had no real troubleshooting skills and was the only tech allowed to run the SMT machine.  We both would troubleshoot boards.  I understood most of the circuits (excluding massive LSI chips) and did troubleshoot at a chip level while he would slather liquid flux on the components that usually fail and reflow solder on many, many components - this while not trying to understand the circuit operation.  I would often get boards he had no luck with.

I suspect I may have to try his technique, at least on the upper exposed voltage regulator circuitry.  Just ordered some liquid flux.  If the problems are at the ASIC level, I can only expect to bake the boards with the ASICs exposed and the rest covered but I've no plans to do that anytime soon.  Has anyone tried this with these?

Thanks.

soy

[adaseb]

Has anybody found a fix for falling hashrate on some S3's? 

The miners I bought from Bitmain directly don't fade in hashrate (two S3+'s, two C1's and an S5) and the first S3 I bought from Cryptocrane on Amazon has been great and arrived in an unopened box an doesn't fade.  The S3 I bought from Pines in Florida on Amazon has been ratty and arrived in an open box opened at the bottom and carelessly closed.  When I saw it functioned poorly I re-pasted but found that both hashboards had already been re-pasted (if the pasting technique found on the first S3 was the norm).  I do believe the hashboards on the S3 from Pines in Florida had been removed perhaps by grasping the PCIE connectors and indelicately forcing the hashboards off the heatsinks.

I cleared an x on chain 2 ASIC 16 yesterday by re-applying the thermal paste on the front after carefully cleaning with a brush and solvent.  That x does not reappear. 

Problem is the usual falling hashrate at stock frequency without x's or dashes appearing.

2hrs; 443.19; amb. temp. 72°; watts at the wall 387w
4hrs; 441.12; amb. temp. 67°; watts at the wall 361w
5hrs; 434.01; amb. temp. 65°; watts at the wall 358w
7hrs; 427.40; amb. temp. 63°; watts at the wall 360w

The falling temperatures as day passed into night should have improved operation and there was less wattage used indicating fewer logic errors from for instance impurities outputting electrons striking/firing transistor gates inappropriately but yet the hashrate fell.

When I was troubleshooting failed SMT boards, the senior tech and I disagreed often.  Aside from regional differences, I'm not native to this area, he had no real troubleshooting skills and was the only tech allowed to run the SMT machine.  We both would troubleshoot boards.  I understood most of the circuits (excluding massive LSI chips) and did troubleshoot at a chip level while he would slather liquid flux on the components that usually fail and reflow solder on many, many components - this while not trying to understand the circuit operation.  I would often get boards he had no luck with.

I suspect I may have to try his technique, at least on the upper exposed voltage regulator circuitry.  Just ordered some liquid flux.  If the problems are at the ASIC level, I can only expect to bake the boards with the ASICs exposed and the rest covered but I've no plans to do that anytime soon.  Has anyone tried this with these?

Thanks.

soy

Just write a cron job so the miner will reboot every 2 hours.

[soy]

Has anybody found a fix for falling hashrate on some S3's?  

The miners I bought from Bitmain directly don't fade in hashrate (two S3+'s, two C1's and an S5) and the first S3 I bought from Cryptocrane on Amazon has been great and arrived in an unopened box an doesn't fade.  The S3 I bought from Pines in Florida on Amazon has been ratty and arrived in an open box opened at the bottom and carelessly closed.  When I saw it functioned poorly I re-pasted but found that both hashboards had already been re-pasted (if the pasting technique found on the first S3 was the norm).  I do believe the hashboards on the S3 from Pines in Florida had been removed perhaps by grasping the PCIE connectors and indelicately forcing the hashboards off the heatsinks.

I cleared an x on chain 2 ASIC 16 yesterday by re-applying the thermal paste on the front after carefully cleaning with a brush and solvent.  That x does not reappear.  

Problem is the usual falling hashrate at stock frequency without x's or dashes appearing.

2hrs; 443.19; amb. temp. 72°; watts at the wall 387w
4hrs; 441.12; amb. temp. 67°; watts at the wall 361w
5hrs; 434.01; amb. temp. 65°; watts at the wall 358w
7hrs; 427.40; amb. temp. 63°; watts at the wall 360w

The falling temperatures as day passed into night should have improved operation and there was less wattage used indicating fewer logic errors from for instance impurities outputting electrons striking/firing transistor gates inappropriately but yet the hashrate fell.

When I was troubleshooting failed SMT boards, the senior tech and I disagreed often.  Aside from regional differences, I'm not native to this area, he had no real troubleshooting skills and was the only tech allowed to run the SMT machine.  We both would troubleshoot boards.  I understood most of the circuits (excluding massive LSI chips) and did troubleshoot at a chip level while he would slather liquid flux on the components that usually fail and reflow solder on many, many components - this while not trying to understand the circuit operation.  I would often get boards he had no luck with.

I suspect I may have to try his technique, at least on the upper exposed voltage regulator circuitry.  Just ordered some liquid flux.  If the problems are at the ASIC level, I can only expect to bake the boards with the ASICs exposed and the rest covered but I've no plans to do that anytime soon.  Has anyone tried this with these?

Thanks.

soy

Just write a cron job so the miner will reboot every 2 hours.

I have it rebooting with a script found early in this thread but with some mods.  Still, it's not right and when the flux gets here I'll try and fix it if I'm not busy with something else.

Actually I don't have it rebooting but essentially this command is run" /etc/init.d/cgminer stop && sleep 2 && /etc/init.d/cgminer start ".  This doesn't work forever of course as something like errors build up.

I have it set to run cg.sh at 421GH/s. 

Also, we had a power outage in heavy rain sometime last night which probably explains the hashrate of 4.

I put it in last night.  It echos restart to a file.  In that file is:

ran cg.sh at 2015-03-30-04-30-04 because avg hashrate: 420
ran cg.sh at 2015-08-30-04-30-04 because avg hashrate: 4
ran cg.sh at 2015-03-30-16-30-04 because avg hashrate: 417

It runs every hour on the half hour.  I manually shut it down mid-day today to try a test: I stopped the cron 3 minute repetition because it restarts cgminer if cgminer is stopped but not sure when that 3 minutes times out relative to my needs - and I wantedto try hashing stopped for some additional minutes with the fan running to cool it down some, then after a timeout, restarted cgminer hoping it would show lower power usage and quicker return to a reasonable hashrate.  Had to go out so really didn't get handle if it's worth stopping hashing for some minutes versus just stopping and starting cgminer.

[aarons6]

Has anybody found a fix for falling hashrate on some S3's?  

The miners I bought from Bitmain directly don't fade in hashrate (two S3+'s, two C1's and an S5) and the first S3 I bought from Cryptocrane on Amazon has been great and arrived in an unopened box an doesn't fade.  The S3 I bought from Pines in Florida on Amazon has been ratty and arrived in an open box opened at the bottom and carelessly closed.  When I saw it functioned poorly I re-pasted but found that both hashboards had already been re-pasted (if the pasting technique found on the first S3 was the norm).  I do believe the hashboards on the S3 from Pines in Florida had been removed perhaps by grasping the PCIE connectors and indelicately forcing the hashboards off the heatsinks.

I cleared an x on chain 2 ASIC 16 yesterday by re-applying the thermal paste on the front after carefully cleaning with a brush and solvent.  That x does not reappear.  

Problem is the usual falling hashrate at stock frequency without x's or dashes appearing.

2hrs; 443.19; amb. temp. 72°; watts at the wall 387w
4hrs; 441.12; amb. temp. 67°; watts at the wall 361w
5hrs; 434.01; amb. temp. 65°; watts at the wall 358w
7hrs; 427.40; amb. temp. 63°; watts at the wall 360w

The falling temperatures as day passed into night should have improved operation and there was less wattage used indicating fewer logic errors from for instance impurities outputting electrons striking/firing transistor gates inappropriately but yet the hashrate fell.

When I was troubleshooting failed SMT boards, the senior tech and I disagreed often.  Aside from regional differences, I'm not native to this area, he had no real troubleshooting skills and was the only tech allowed to run the SMT machine.  We both would troubleshoot boards.  I understood most of the circuits (excluding massive LSI chips) and did troubleshoot at a chip level while he would slather liquid flux on the components that usually fail and reflow solder on many, many components - this while not trying to understand the circuit operation.  I would often get boards he had no luck with.

I suspect I may have to try his technique, at least on the upper exposed voltage regulator circuitry.  Just ordered some liquid flux.  If the problems are at the ASIC level, I can only expect to bake the boards with the ASICs exposed and the rest covered but I've no plans to do that anytime soon.  Has anyone tried this with these?

Thanks.

soy

Just write a cron job so the miner will reboot every 2 hours.

I have it rebooting with a script found early in this thread but with some mods.  Still, it's not right and when the flux gets here I'll try and fix it if I'm not busy with something else.

Actually I don't have it rebooting but essentially this command is run" /etc/init.d/cgminer stop && sleep 2 && /etc/init.d/cgminer start ".  This doesn't work forever of course as something like errors build up.

I have it set to run cg.sh at 421GH/s

I put it in last night.  It echos restart to a file.  In that file is:

ran cg.sh at 2015-03-30-04-30-04 because avg hashrate: 420
ran cg.sh at 2015-08-30-04-30-04 because avg hashrate: 4
ran cg.sh at 2015-03-30-16-30-04 because avg hashrate: 417

It runs every hour on the half hour.  I manually shut it down mid-day today to try a test: I stopped the cron 3 minute repetition because it restarts cgminer if cgminer is stopped but not sure when that 3 minutes times out relative to my needs - and I wantedto try hashing stopped for some additional minutes with the fan running to cool it down some, then after a timeout, restarted cgminer hoping it would show lower power usage and quicker return to a reasonable hashrate.  Had to go out so really didn't get handle if it's worth stopping hashing for some minutes versus just stopping and starting cgminer.

i dont want to be that guy but..

the time you are spending with the machine off and rebooting is probably doing you more harm in payouts then the slower hash speeds.

[soy]

Yes but I'm a retired technician and one does what one does.

[aarons6]

Yes but I'm a retired technician and one does what one does.

difficulty is going up and time is running out for the s3..
if it were me id set it to 225 or whatever speed and try to leave it running a constant as possible..

[pekatete]

Yes but I'm a retired technician and one does what one does.

Just my thinking this .... I believe the updated firmware ALSO updates the PIC firmware and it is this (the PIC firmware) that causes / results in the diminishing hashrate on the newer firmware. If you have a copy of the old firmware, I'd be tempted to extract that hex file from the old firmware and put it in the overlay directory then rebooting (of course, do backup the existing hex file before copying the older one, and that at your own risk!).

Also, repasting, when done, needs to be preceded by a thorough clean and removal of the old paste. Again, just my thinking, but I found that using slightly thicker thermal pads gave better results on the S3's I had than any (recomended) non conductive thermal paste I could lay my hands on.

[Mikestang]

Would someone be able to save me 400+ pages of this thread and point me to S3+ overclocking directions?  I'm assuming you have to ssh in like the S1?

Also, if there are any posts showing various frequencies and associated hash and error rates I'd appreciate seeing that as well.

Thank you.