ANTMINER S3+ Discussion and Support Thread

[mrpark]

I was directed here as maybe a quick fix for a problem. Please point me elsewhere if appropriate.

Just set up two s3 b9's with identical PSU's and ran fine for 4 days till I needed to change one of the configuration settings on both devices.

I changed the setting (password field for the first pool, actually getting used as a hashing control for a lower limit of payout acceptable) and then clicked the "Save&Apply". I monitored for a while and just got to wondering "did the setting actually take effect properly" as things didn't seem kosher, so I used the reboot option from the web page on both devices.

On reboot one would not display a good status LED (although the NIC LED's look good). Both the red and green LED's are dark, not even brief flashing (even though they did light till the NIC cycled). If I try to access it with the browser I get the initial page "LuCI - Lua Configuration Interface" but the auto link to the status overview eventually times out. It also doesn't generate heat (I have them side by side and there is a big difference in heat output between the working one and the failing one)

I tried leaving the failing one off for 20 minutes or so. That didn't help. I then swapped the PSU's on the theory that there wasn't enough electrical output on one PSU. That made no difference, working one with the other PSU still worked, failing one with the "working" PSU still failed.

Thoughts on what I could try that won't make it so I can't return it?

For those with S3's acting up, try to go back to the original image. Or, if its slow, try the S3+ firmware. These are nice miners, but they are not consistent. In order to get all miners going, either go backwards or forwards with the firmware. Just my 2 cents for you to try. Have you tried the S3+ firmware yet?

[1714648537]

1714648537

[1714648537]

1714648537

[1714648537]

1714648537

[1714648537]

1714648537

[1714648537]

1714648537

[philipma1957]

Ah, my problem S3 has been running 1d 16h and has slowed to 418.15.  Three hours ago it was 418.80.

I have been in an acrimonious email exchange with the reseller.  So, for me to ask him to submit the slow hashing blade for exchange would beg an extended delay.  To request an exchange from Bitmain would probably be met by an instruction to return the slow hashing board to the reseller.

I'm not certain it would be in my interest to return the hashing board.  If Bitmain would accept the board directly what is the estimated turn around time?  What is the estimated shipping from the US?  Answers to these questions would help inform my decision how to proceed.  Thanks.

soy

what is your freq setting for this unit?

   Some of these units only run well at freq 212.50   .  You may have one of them and all the work you did to fix it was a waste of time.   I have a pair of these they were batch 1.  I did everything possible with one of them and did nothing with the other.

   So I then set both to freq 212.50 and they have run rock steady around  430gh since July 25 or so.  Try using setting of 212.5 to see if you stay stable at 430 gh.

[maccool]

I was directed here as maybe a quick fix for a problem. Please point me elsewhere if appropriate.

Just set up two s3 b9's with identical PSU's and ran fine for 4 days till I needed to change one of the configuration settings on both devices.

I changed the setting (password field for the first pool, actually getting used as a hashing control for a lower limit of payout acceptable) and then clicked the "Save&Apply". I monitored for a while and just got to wondering "did the setting actually take effect properly" as things didn't seem kosher, so I used the reboot option from the web page on both devices.

On reboot one would not display a good status LED (although the NIC LED's look good). Both the red and green LED's are dark, not even brief flashing (even though they did light till the NIC cycled). If I try to access it with the browser I get the initial page "LuCI - Lua Configuration Interface" but the auto link to the status overview eventually times out. It also doesn't generate heat (I have them side by side and there is a big difference in heat output between the working one and the failing one)

I tried leaving the failing one off for 20 minutes or so. That didn't help. I then swapped the PSU's on the theory that there wasn't enough electrical output on one PSU. That made no difference, working one with the other PSU still worked, failing one with the "working" PSU still failed.

Thoughts on what I could try that won't make it so I can't return it?

For those with S3's acting up, try to go back to the original image. Or, if its slow, try the S3+ firmware. These are nice miners, but they are not consistent. In order to get all miners going, either go backwards or forwards with the firmware. Just my 2 cents for you to try. Have you tried the S3+ firmware yet?

Given the length of time since purchase, I'm hesitant. Like I said. I'd rather not do something that makes it impossible to return. If I brick it, then I'm stuck. Also, I can't get to the web page that has the flashing initiation, it'll take some hoop jumping to get it done. I'll wait and see what others have to say that might help and are less drastic. (An additional diagnostic that is more information would be great, even if the diagnostic really does then point at a firmware upgrade. I'd then be willing to go there.)

[mrpark]

I was directed here as maybe a quick fix for a problem. Please point me elsewhere if appropriate.

Just set up two s3 b9's with identical PSU's and ran fine for 4 days till I needed to change one of the configuration settings on both devices.

I changed the setting (password field for the first pool, actually getting used as a hashing control for a lower limit of payout acceptable) and then clicked the "Save&Apply". I monitored for a while and just got to wondering "did the setting actually take effect properly" as things didn't seem kosher, so I used the reboot option from the web page on both devices.

On reboot one would not display a good status LED (although the NIC LED's look good). Both the red and green LED's are dark, not even brief flashing (even though they did light till the NIC cycled). If I try to access it with the browser I get the initial page "LuCI - Lua Configuration Interface" but the auto link to the status overview eventually times out. It also doesn't generate heat (I have them side by side and there is a big difference in heat output between the working one and the failing one)

I tried leaving the failing one off for 20 minutes or so. That didn't help. I then swapped the PSU's on the theory that there wasn't enough electrical output on one PSU. That made no difference, working one with the other PSU still worked, failing one with the "working" PSU still failed.

Thoughts on what I could try that won't make it so I can't return it?

For those with S3's acting up, try to go back to the original image. Or, if its slow, try the S3+ firmware. These are nice miners, but they are not consistent. In order to get all miners going, either go backwards or forwards with the firmware. Just my 2 cents for you to try. Have you tried the S3+ firmware yet?

Given the length of time since purchase, I'm hesitant. Like I said. I'd rather not do something that makes it impossible to return. If I brick it, then I'm stuck. I'll wait and see what others have to say that might help and are less drastic. (An additional diagnostic that is more information would be great, even if the diagnostic really does then point at a firmware upgrade. I'd then be willing to go there.)

I doubt you will brick it, I have done many S3+ compatible firmware update, and I also went backwards. No issues. Email tech support, and if they ask if you should upgrade it, that way you can say you were just following their instructions.  I think there was a security issue with the original firmware.

[maccool]

I was directed here as maybe a quick fix for a problem. Please point me elsewhere if appropriate.

Just set up two s3 b9's with identical PSU's and ran fine for 4 days till I needed to change one of the configuration settings on both devices.

I changed the setting (password field for the first pool, actually getting used as a hashing control for a lower limit of payout acceptable) and then clicked the "Save&Apply". I monitored for a while and just got to wondering "did the setting actually take effect properly" as things didn't seem kosher, so I used the reboot option from the web page on both devices.

On reboot one would not display a good status LED (although the NIC LED's look good). Both the red and green LED's are dark, not even brief flashing (even though they did light till the NIC cycled). If I try to access it with the browser I get the initial page "LuCI - Lua Configuration Interface" but the auto link to the status overview eventually times out. It also doesn't generate heat (I have them side by side and there is a big difference in heat output between the working one and the failing one)

I tried leaving the failing one off for 20 minutes or so. That didn't help. I then swapped the PSU's on the theory that there wasn't enough electrical output on one PSU. That made no difference, working one with the other PSU still worked, failing one with the "working" PSU still failed.

Thoughts on what I could try that won't make it so I can't return it?

For those with S3's acting up, try to go back to the original image. Or, if its slow, try the S3+ firmware. These are nice miners, but they are not consistent. In order to get all miners going, either go backwards or forwards with the firmware. Just my 2 cents for you to try. Have you tried the S3+ firmware yet?

Given the length of time since purchase, I'm hesitant. Like I said. I'd rather not do something that makes it impossible to return. If I brick it, then I'm stuck. I'll wait and see what others have to say that might help and are less drastic. (An additional diagnostic that is more information would be great, even if the diagnostic really does then point at a firmware upgrade. I'd then be willing to go there.)

I doubt you will brick it, I have done many S3+ compatible firmware update, and I also went backwards. No issues. Email tech support, and if they ask if you should upgrade it, that way you can say you were just following their instructions.  I think there was a security issue with the original firmware.

I just tried an SSH access and the one device just times out the connection, the working one lets me log on as root. I think it's interesting that the first LuCI page comes up even though other pages and SSH don't work. At this point, without better diagnostics, I'd be inclined to let bitmain tell me what to do.

[akhensetukh]

I was directed here as maybe a quick fix for a problem. Please point me elsewhere if appropriate.

Just set up two s3 b9's with identical PSU's and ran fine for 4 days till I needed to change one of the configuration settings on both devices.

I changed the setting (password field for the first pool, actually getting used as a hashing control for a lower limit of payout acceptable) and then clicked the "Save&Apply". I monitored for a while and just got to wondering "did the setting actually take effect properly" as things didn't seem kosher, so I used the reboot option from the web page on both devices.

On reboot one would not display a good status LED (although the NIC LED's look good). Both the red and green LED's are dark, not even brief flashing (even though they did light till the NIC cycled). If I try to access it with the browser I get the initial page "LuCI - Lua Configuration Interface" but the auto link to the status overview eventually times out. It also doesn't generate heat (I have them side by side and there is a big difference in heat output between the working one and the failing one)

I tried leaving the failing one off for 20 minutes or so. That didn't help. I then swapped the PSU's on the theory that there wasn't enough electrical output on one PSU. That made no difference, working one with the other PSU still worked, failing one with the "working" PSU still failed.

Thoughts on what I could try that won't make it so I can't return it?

For those with S3's acting up, try to go back to the original image. Or, if its slow, try the S3+ firmware. These are nice miners, but they are not consistent. In order to get all miners going, either go backwards or forwards with the firmware. Just my 2 cents for you to try. Have you tried the S3+ firmware yet?

Given the length of time since purchase, I'm hesitant. Like I said. I'd rather not do something that makes it impossible to return. If I brick it, then I'm stuck. I'll wait and see what others have to say that might help and are less drastic. (An additional diagnostic that is more information would be great, even if the diagnostic really does then point at a firmware upgrade. I'd then be willing to go there.)

I doubt you will brick it, I have done many S3+ compatible firmware update, and I also went backwards. No issues. Email tech support, and if they ask if you should upgrade it, that way you can say you were just following their instructions.  I think there was a security issue with the original firmware.

I just tried an SSH access and the one device just times out the connection, the working one lets me log on as root. I think it's interesting that the first LuCI page comes up even though other pages and SSH don't work. At this point, without better diagnostics, I'd be inclined to let bitmain tell me what to do.

Trouble is that the downed miner won't bring up the HTTP interface, so there is no possibility at installing different firmware. Anyone know how to reset the device? We've tried the instructions for reset shown here, but no joy.

[mrpark]

I was directed here as maybe a quick fix for a problem. Please point me elsewhere if appropriate.

Just set up two s3 b9's with identical PSU's and ran fine for 4 days till I needed to change one of the configuration settings on both devices.

I changed the setting (password field for the first pool, actually getting used as a hashing control for a lower limit of payout acceptable) and then clicked the "Save&Apply". I monitored for a while and just got to wondering "did the setting actually take effect properly" as things didn't seem kosher, so I used the reboot option from the web page on both devices.

On reboot one would not display a good status LED (although the NIC LED's look good). Both the red and green LED's are dark, not even brief flashing (even though they did light till the NIC cycled). If I try to access it with the browser I get the initial page "LuCI - Lua Configuration Interface" but the auto link to the status overview eventually times out. It also doesn't generate heat (I have them side by side and there is a big difference in heat output between the working one and the failing one)

I tried leaving the failing one off for 20 minutes or so. That didn't help. I then swapped the PSU's on the theory that there wasn't enough electrical output on one PSU. That made no difference, working one with the other PSU still worked, failing one with the "working" PSU still failed.

Thoughts on what I could try that won't make it so I can't return it?

For those with S3's acting up, try to go back to the original image. Or, if its slow, try the S3+ firmware. These are nice miners, but they are not consistent. In order to get all miners going, either go backwards or forwards with the firmware. Just my 2 cents for you to try. Have you tried the S3+ firmware yet?

Given the length of time since purchase, I'm hesitant. Like I said. I'd rather not do something that makes it impossible to return. If I brick it, then I'm stuck. I'll wait and see what others have to say that might help and are less drastic. (An additional diagnostic that is more information would be great, even if the diagnostic really does then point at a firmware upgrade. I'd then be willing to go there.)

I doubt you will brick it, I have done many S3+ compatible firmware update, and I also went backwards. No issues. Email tech support, and if they ask if you should upgrade it, that way you can say you were just following their instructions.  I think there was a security issue with the original firmware.

I just tried an SSH access and the one device just times out the connection, the working one lets me log on as root. I think it's interesting that the first LuCI page comes up even though other pages and SSH don't work. At this point, without better diagnostics, I'd be inclined to let bitmain tell me what to do.

Trouble is that the downed miner won't bring up the HTTP interface, so there is no possibility at installing different firmware. Anyone know how to reset the device? We've tried the instructions for reset shown here, but no joy.

Can you ping it? If so try another browser? Default should be 192.168.1.99.

[soy]

Ah, my problem S3 has been running 1d 16h and has slowed to 418.15.  Three hours ago it was 418.80.

I have been in an acrimonious email exchange with the reseller.  So, for me to ask him to submit the slow hashing blade for exchange would beg an extended delay.  To request an exchange from Bitmain would probably be met by an instruction to return the slow hashing board to the reseller.

I'm not certain it would be in my interest to return the hashing board.  If Bitmain would accept the board directly what is the estimated turn around time?  What is the estimated shipping from the US?  Answers to these questions would help inform my decision how to proceed.  Thanks.

soy

I realise that you may have tried this, but one of my S3s is similar to yours and gets slower and slower, eventually ending up in the 300s, so when I can see that its average is going down towards 420 again, I reboot it.  On the first or second reboot, it starts hashing at around 460 or more, with good speed for hours until it gradually starts sinking again over the next day or so.  With this method, I keep it averaging 440 for most of the time, which I can't complain about.  Sorry if you already tried and discounted this!  

Yes, a cold boot restores relatively normal hashrates but there is a continual decline.  I'm hoping it will settle out at a hashrate that is a stable floor.  I had tried anticipating when it would hit 5% less than 441, knowing that end point, 418.5, if the plot tracked a capacitor charging track a single timeconstant predicted five timeconstants would have expired this afternoon.  It finished early because the cold boot was late afternoon and much of that first timeconstant the S3 was in a cooler environment so the prediction was long.

Does either of your fan speeds seem slow relative to temperature?

Rebooting will restore the hashing for a while I suppose and cost less than a return.  

[soy]

I was directed here as maybe a quick fix for a problem. Please point me elsewhere if appropriate.

Just set up two s3 b9's with identical PSU's and ran fine for 4 days till I needed to change one of the configuration settings on both devices.

I changed the setting (password field for the first pool, actually getting used as a hashing control for a lower limit of payout acceptable) and then clicked the "Save&Apply". I monitored for a while and just got to wondering "did the setting actually take effect properly" as things didn't seem kosher, so I used the reboot option from the web page on both devices.

On reboot one would not display a good status LED (although the NIC LED's look good). Both the red and green LED's are dark, not even brief flashing (even though they did light till the NIC cycled). If I try to access it with the browser I get the initial page "LuCI - Lua Configuration Interface" but the auto link to the status overview eventually times out. It also doesn't generate heat (I have them side by side and there is a big difference in heat output between the working one and the failing one)

I tried leaving the failing one off for 20 minutes or so. That didn't help. I then swapped the PSU's on the theory that there wasn't enough electrical output on one PSU. That made no difference, working one with the other PSU still worked, failing one with the "working" PSU still failed.

Thoughts on what I could try that won't make it so I can't return it?

Try disconnecting the power supply from the S3 while you leave it off for some period before you retry.

[soy]

I was directed here as maybe a quick fix for a problem. Please point me elsewhere if appropriate.

Just set up two s3 b9's with identical PSU's and ran fine for 4 days till I needed to change one of the configuration settings on both devices.

I changed the setting (password field for the first pool, actually getting used as a hashing control for a lower limit of payout acceptable) and then clicked the "Save&Apply". I monitored for a while and just got to wondering "did the setting actually take effect properly" as things didn't seem kosher, so I used the reboot option from the web page on both devices.

On reboot one would not display a good status LED (although the NIC LED's look good). Both the red and green LED's are dark, not even brief flashing (even though they did light till the NIC cycled). If I try to access it with the browser I get the initial page "LuCI - Lua Configuration Interface" but the auto link to the status overview eventually times out. It also doesn't generate heat (I have them side by side and there is a big difference in heat output between the working one and the failing one)

I tried leaving the failing one off for 20 minutes or so. That didn't help. I then swapped the PSU's on the theory that there wasn't enough electrical output on one PSU. That made no difference, working one with the other PSU still worked, failing one with the "working" PSU still failed.

Thoughts on what I could try that won't make it so I can't return it?

For those with S3's acting up, try to go back to the original image. Or, if its slow, try the S3+ firmware. These are nice miners, but they are not consistent. In order to get all miners going, either go backwards or forwards with the firmware. Just my 2 cents for you to try. Have you tried the S3+ firmware yet?

Given the length of time since purchase, I'm hesitant. Like I said. I'd rather not do something that makes it impossible to return. If I brick it, then I'm stuck. I'll wait and see what others have to say that might help and are less drastic. (An additional diagnostic that is more information would be great, even if the diagnostic really does then point at a firmware upgrade. I'd then be willing to go there.)

I doubt you will brick it, I have done many S3+ compatible firmware update, and I also went backwards. No issues. Email tech support, and if they ask if you should upgrade it, that way you can say you were just following their instructions.  I think there was a security issue with the original firmware.

I just tried an SSH access and the one device just times out the connection, the working one lets me log on as root. I think it's interesting that the first LuCI page comes up even though other pages and SSH don't work. At this point, without better diagnostics, I'd be inclined to let bitmain tell me what to do.

Trouble is that the downed miner won't bring up the HTTP interface, so there is no possibility at installing different firmware. Anyone know how to reset the device? We've tried the instructions for reset shown here, but no joy.

The reset button is a bit below the hole, not aligned well.  And I found on the S3 as well as a miner from another company that the reset doesn't work all that well.  What I try is holding it in for 30 seconds, then mashing it every few seconds for a while, then turning it off, letting it sit a  minute then rebooting while mashing the reset every few seconds a couple of times then letting it boot.

[soy]

I was directed here as maybe a quick fix for a problem. Please point me elsewhere if appropriate.

Just set up two s3 b9's with identical PSU's and ran fine for 4 days till I needed to change one of the configuration settings on both devices.

I changed the setting (password field for the first pool, actually getting used as a hashing control for a lower limit of payout acceptable) and then clicked the "Save&Apply". I monitored for a while and just got to wondering "did the setting actually take effect properly" as things didn't seem kosher, so I used the reboot option from the web page on both devices.

On reboot one would not display a good status LED (although the NIC LED's look good). Both the red and green LED's are dark, not even brief flashing (even though they did light till the NIC cycled). If I try to access it with the browser I get the initial page "LuCI - Lua Configuration Interface" but the auto link to the status overview eventually times out. It also doesn't generate heat (I have them side by side and there is a big difference in heat output between the working one and the failing one)

I tried leaving the failing one off for 20 minutes or so. That didn't help. I then swapped the PSU's on the theory that there wasn't enough electrical output on one PSU. That made no difference, working one with the other PSU still worked, failing one with the "working" PSU still failed.

Thoughts on what I could try that won't make it so I can't return it?

For those with S3's acting up, try to go back to the original image. Or, if its slow, try the S3+ firmware. These are nice miners, but they are not consistent. In order to get all miners going, either go backwards or forwards with the firmware. Just my 2 cents for you to try. Have you tried the S3+ firmware yet?

Given the length of time since purchase, I'm hesitant. Like I said. I'd rather not do something that makes it impossible to return. If I brick it, then I'm stuck. I'll wait and see what others have to say that might help and are less drastic. (An additional diagnostic that is more information would be great, even if the diagnostic really does then point at a firmware upgrade. I'd then be willing to go there.)

I doubt you will brick it, I have done many S3+ compatible firmware update, and I also went backwards. No issues. Email tech support, and if they ask if you should upgrade it, that way you can say you were just following their instructions.  I think there was a security issue with the original firmware.

I just tried an SSH access and the one device just times out the connection, the working one lets me log on as root. I think it's interesting that the first LuCI page comes up even though other pages and SSH don't work. At this point, without better diagnostics, I'd be inclined to let bitmain tell me what to do.

Trouble is that the downed miner won't bring up the HTTP interface, so there is no possibility at installing different firmware. Anyone know how to reset the device? We've tried the instructions for reset shown here, but no joy.

Can you ping it? If so try another browser? Default should be 192.168.1.99.

I've noticed that if I ssh into an S3 and command halt, unless I cold boot I can't get in.  The device will acknowledge a ping but port 80 seems closed.  And the halt command stops the cgminer-monitor so it doesn't restart at otherwise 3 minutes most.

[maccool]

I was directed here as maybe a quick fix for a problem. Please point me elsewhere if appropriate.

Just set up two s3 b9's with identical PSU's and ran fine for 4 days till I needed to change one of the configuration settings on both devices.

I changed the setting (password field for the first pool, actually getting used as a hashing control for a lower limit of payout acceptable) and then clicked the "Save&Apply". I monitored for a while and just got to wondering "did the setting actually take effect properly" as things didn't seem kosher, so I used the reboot option from the web page on both devices.

On reboot one would not display a good status LED (although the NIC LED's look good). Both the red and green LED's are dark, not even brief flashing (even though they did light till the NIC cycled). If I try to access it with the browser I get the initial page "LuCI - Lua Configuration Interface" but the auto link to the status overview eventually times out. It also doesn't generate heat (I have them side by side and there is a big difference in heat output between the working one and the failing one)

I tried leaving the failing one off for 20 minutes or so. That didn't help. I then swapped the PSU's on the theory that there wasn't enough electrical output on one PSU. That made no difference, working one with the other PSU still worked, failing one with the "working" PSU still failed.

Thoughts on what I could try that won't make it so I can't return it?

For those with S3's acting up, try to go back to the original image. Or, if its slow, try the S3+ firmware. These are nice miners, but they are not consistent. In order to get all miners going, either go backwards or forwards with the firmware. Just my 2 cents for you to try. Have you tried the S3+ firmware yet?

Given the length of time since purchase, I'm hesitant. Like I said. I'd rather not do something that makes it impossible to return. If I brick it, then I'm stuck. I'll wait and see what others have to say that might help and are less drastic. (An additional diagnostic that is more information would be great, even if the diagnostic really does then point at a firmware upgrade. I'd then be willing to go there.)

I doubt you will brick it, I have done many S3+ compatible firmware update, and I also went backwards. No issues. Email tech support, and if they ask if you should upgrade it, that way you can say you were just following their instructions.  I think there was a security issue with the original firmware.

I just tried an SSH access and the one device just times out the connection, the working one lets me log on as root. I think it's interesting that the first LuCI page comes up even though other pages and SSH don't work. At this point, without better diagnostics, I'd be inclined to let bitmain tell me what to do.

Trouble is that the downed miner won't bring up the HTTP interface, so there is no possibility at installing different firmware. Anyone know how to reset the device? We've tried the instructions for reset shown here, but no joy.

Can you ping it? If so try another browser? Default should be 192.168.1.99.

I've noticed that if I ssh into an S3 and command halt, unless I cold boot I can't get in.  The device will acknowledge a ping but port 80 seems closed.  And the halt command stops the cgminer-monitor so it doesn't restart at otherwise 3 minutes most.

Tried the suggestion of disconnecting PSU entirely (unplugged both sets of the 6 pins), still not working. Tried it with all 4 6-pin slots used (overclock), still not working. Went back to my original set up (one PSU, 2 sets of 6 pins like the working miner), restarted, and tried to ping it, no response to the ping (also my router doesn't note it like it does with the working miner)

[soy]

The fans give a speed indication output.  I don't know what kind, digital or analog.  The fan speed is controlled by pulse width modulation.  I don't see a corresponding hashing board temperature and fan speed though one goes up so does the other.  If I saw three miners having a 40° board temperature and all three have the same speed, I'd say there was a digital feedback loop but this is not the case.  So, one might assume that there is a ramp or curve that says when the temperature is A the fan speed supply voltage will be X, temp B gets voltage Y and temp C gets voltage Z.  The speed indication just giving an indication of change versus temperature to the user.

The bad hashing board having a declining hashrate and a declining temperature might indicate the fault is elsewhere except that even after a cold start, after significant cooling time such that hashing starts over 442 and works its way down over hours, shows a lower temperature and fan speed early on.  If that slower fan speed causes errors away from the temperature sensor, those ASICs may shut down engines and slow hashrate but not quickly effect temperature indication.

So the slow fan speed relative to temperature should be addressed.  The problem may be in the pulsed width voltage supply line.  A partial open, high resistance, in a plated thru hole, e.g. dull drill bit left fiber in the hole, the hole only partly plated.  So, that's where I'll look first when I troubleshoot.  I'll follow the pulsed with fan voltage first, then the ground and perhaps the speed indication pair, looking for something amiss.  But not today.

Way overly optimistic without a schematic.  I shut it down and inspected.  Inspected and check grounds.  I'd have liked to trace the fan lines but the multilayered board precluded that and without a schematic that's that.  The only thing I found amiss is between pins 1 and 20 of the ribbon cable connection - the green covering had been lifted between the two pins as if those pins had carried quite a bit of current at one time and heated that area.  So no joy.

I would imagine that might happen if someone tried powering the S3 putting connectors to only the one side and the other side tried to hash with current across the controller board.

[bspurloc]

can someone explain this to me? What is wrong with this picture? I am running the latest image.... Fans even hitting 12,400 RPM, pretty soon my S3 is going to be flying around the room!

I have one where the fan speed is reporting as way too high seeing how these fans max out at 3000 rpm. I just ignore it because sound comparisons are telling me the fan is not spinning that fast and is in fact spinning at the proper speeds....

It would be nice to see why they are reporting this. I would swap out some other fans and see if its a faulty fan sense but logic dictates its a software problem because if the fan was actually reporting that speed the s3 would NEVER adjust it higher when it gets hotter and I hear the faulty reading s3 changing its fans speeds when it gets a little hotter....

Side note on your pictures.... 50C 51C?? wow you running those way too hot...
the ones I have sitting just out in the open not in a server room are at 42c/40c. u live in a bakery?

Yes, I want them to run hot because I make eggs in the morning on pan on top of the miner, and cookies in the evenings I run these in my office, I have 17 of them plus other miners in a room with just one 6" vent. The degrees is about 95-100F, and there hasn't been any problems. Chips don't need to be that cold, they just need air over them to run. All the miners have been running fine, its just these funky readings and the fans do move faster, but I don't think they are REALLY going 12,000 RPM or they would be extremely loud.

are they all at 50C? the max speed on these is 3000rpm.
The real reason I cant be bothered with swapping a fan is I dont feel like taking those metal cages off and I think removing them requires you to unplug the power.  where if they were sitting out in the open I would try another fan asap! like the upgrade kit ones I did...
I tested a fan on one of those cuz the 2nd boards show no fans at all...

[moss]

Ah, my problem S3 has been running 1d 16h and has slowed to 418.15.  Three hours ago it was 418.80.

I have been in an acrimonious email exchange with the reseller.  So, for me to ask him to submit the slow hashing blade for exchange would beg an extended delay.  To request an exchange from Bitmain would probably be met by an instruction to return the slow hashing board to the reseller.

I'm not certain it would be in my interest to return the hashing board.  If Bitmain would accept the board directly what is the estimated turn around time?  What is the estimated shipping from the US?  Answers to these questions would help inform my decision how to proceed.  Thanks.

soy

I realise that you may have tried this, but one of my S3s is similar to yours and gets slower and slower, eventually ending up in the 300s, so when I can see that its average is going down towards 420 again, I reboot it.  On the first or second reboot, it starts hashing at around 460 or more, with good speed for hours until it gradually starts sinking again over the next day or so.  With this method, I keep it averaging 440 for most of the time, which I can't complain about.  Sorry if you already tried and discounted this!  

Yes, a cold boot restores relatively normal hashrates but there is a continual decline.  I'm hoping it will settle out at a hashrate that is a stable floor.  I had tried anticipating when it would hit 5% less than 441, knowing that end point, 418.5, if the plot tracked a capacitor charging track a single timeconstant predicted five timeconstants would have expired this afternoon.  It finished early because the cold boot was late afternoon and much of that first timeconstant the S3 was in a cooler environment so the prediction was long.

Does either of your fan speeds seem slow relative to temperature?

Rebooting will restore the hashing for a while I suppose and cost less than a return.  

My fan speeds are ok relative to temperature.  However, my temp is 1 to 2 deg higher than standard, because I don't use the original fans; the units are in my office and I couldn't stand the noise.  I think that rebooting has been the best strategy for me and as you say, it's cheaper than a return, with the delay associated with that, although I suppose that if you got a really good one back...  but who knows?  I'm just going to carry on rebooting mine. 

[soy]

Tried the suggestion of disconnecting PSU entirely (unplugged both sets of the 6 pins), still not working. Tried it with all 4 6-pin slots used (overclock), still not working. Went back to my original set up (one PSU, 2 sets of 6 pins like the working miner), restarted, and tried to ping it, no response to the ping (also my router doesn't note it like it does with the working miner)

Have you a linux machine, other than the miner, on the network?  First try nmap 192.168.1.* | more to see what is on the network.  The last line of the nmap output for antMiners will identify as Paragon Technologies or sometimes as Unknown.   If nmap doesn't find it and your subnet is something other than 192.168.1.0, then try running tcpdump and watching the traffic looking for an out-of-subnet IP transmitting.

[soy]

The fans give a speed indication output.  I don't know what kind, digital or analog.  The fan speed is controlled by pulse width modulation.  I don't see a corresponding hashing board temperature and fan speed though one goes up so does the other.  If I saw three miners having a 40° board temperature and all three have the same speed, I'd say there was a digital feedback loop but this is not the case.  So, one might assume that there is a ramp or curve that says when the temperature is A the fan speed supply voltage will be X, temp B gets voltage Y and temp C gets voltage Z.  The speed indication just giving an indication of change versus temperature to the user.

The bad hashing board having a declining hashrate and a declining temperature might indicate the fault is elsewhere except that even after a cold start, after significant cooling time such that hashing starts over 442 and works its way down over hours, shows a lower temperature and fan speed early on.  If that slower fan speed causes errors away from the temperature sensor, those ASICs may shut down engines and slow hashrate but not quickly effect temperature indication.

So the slow fan speed relative to temperature should be addressed.  The problem may be in the pulsed width voltage supply line.  A partial open, high resistance, in a plated thru hole, e.g. dull drill bit left fiber in the hole, the hole only partly plated.  So, that's where I'll look first when I troubleshoot.  I'll follow the pulsed with fan voltage first, then the ground and perhaps the speed indication pair, looking for something amiss.  But not today.

Way overly optimistic without a schematic.  I shut it down and inspected.  Inspected and check grounds.  I'd have liked to trace the fan lines but the multilayered board precluded that and without a schematic that's that.  The only thing I found amiss is between pins 1 and 20 of the ribbon cable connection - the green covering had been lifted between the two pins as if those pins had carried quite a bit of current at one time and heated that area.  So no joy.

I would imagine that might happen if someone tried powering the S3 putting connectors to only the one side and the other side tried to hash with current across the controller board.

Started falling along regular lines.  My first S3, the good unit from the mid-west not Florida, has a hashing board that always runs at over 3k.  No unusual noise.  Wish I had a strobe tach.  My next course of action is to put the fast fan board on the warmer side of the bad S3.  So, although the bad board has a slow running fan there may be some compensation tho if it's not a cooling issue....

[soy]

The fans give a speed indication output.  I don't know what kind, digital or analog.  The fan speed is controlled by pulse width modulation.  I don't see a corresponding hashing board temperature and fan speed though one goes up so does the other.  If I saw three miners having a 40° board temperature and all three have the same speed, I'd say there was a digital feedback loop but this is not the case.  So, one might assume that there is a ramp or curve that says when the temperature is A the fan speed supply voltage will be X, temp B gets voltage Y and temp C gets voltage Z.  The speed indication just giving an indication of change versus temperature to the user.

The bad hashing board having a declining hashrate and a declining temperature might indicate the fault is elsewhere except that even after a cold start, after significant cooling time such that hashing starts over 442 and works its way down over hours, shows a lower temperature and fan speed early on.  If that slower fan speed causes errors away from the temperature sensor, those ASICs may shut down engines and slow hashrate but not quickly effect temperature indication.

So the slow fan speed relative to temperature should be addressed.  The problem may be in the pulsed width voltage supply line.  A partial open, high resistance, in a plated thru hole, e.g. dull drill bit left fiber in the hole, the hole only partly plated.  So, that's where I'll look first when I troubleshoot.  I'll follow the pulsed with fan voltage first, then the ground and perhaps the speed indication pair, looking for something amiss.  But not today.

Way overly optimistic without a schematic.  I shut it down and inspected.  Inspected and check grounds.  I'd have liked to trace the fan lines but the multilayered board precluded that and without a schematic that's that.  The only thing I found amiss is between pins 1 and 20 of the ribbon cable connection - the green covering had been lifted between the two pins as if those pins had carried quite a bit of current at one time and heated that area.  So no joy.

I would imagine that might happen if someone tried powering the S3 putting connectors to only the one side and the other side tried to hash with current across the controller board.

Started falling along regular lines.  My first S3, the good unit from the mid-west not Florida, has a hashing board that always runs at over 3k.  No unusual noise.  Wish I had a strobe tach.  My next course of action is to put the fast fan board on the warmer side of the bad S3.  So, although the bad board has a slow running fan there may be some compensation tho if it's not a cooling issue....

It was falling quickly.  Shut it down, opened it up, made a change, do believe I fixed it.  It's been up 1h39m now, will get back later with stats and the fix.  Up 4 hours and looking good.  If still good later tomorrow I'll post.

[tripppn]

Maybe I'm just really lucky but I have never had a single problem with anything I've bought from Bitmain.  3 S1s and 6 S3s.  I am a pretty lucky guy though 

[moss]

Okay, after 10h44m the hashrate is 440.08.  That's fixed.

When I inspected the questionable S3 hashing board that had cropped to well below 418 the day before, I found that board surface between the last two pins on the right of the ribbon connector rear had raised green material.  That's pin 1 with the arrow and the pin immediately below it which I had called pin 20 but is possibly pin 2 being the adjacent conductor.  Touching the green material it came away easily and flaked free showing oxidized copper beneath.  Those two pins are common on the hashing board but the corresponding pins on the controller board are not.  They tested common on the hashing board with the ribbon removed.  Still, since it showed minor heat damage, the green material flaking off and the copper discoloration, I put a soldering iron on the pins then fired it up.  It was not a fix and the hashrate dropped quicker than usual.  Shutting it down and taking the top off, those pins were easily accessible so I soldered a quick jumper between the two pins with #28 wirewrap wire and closed.  It's been running ever since.

So, if you have an S3 that has a dropping hashrate, e.g. down to below 418GH/s in a few days, check the area of those two pins on the questionable board and if it shows indication of having heated from high current, try the jumper.  I believe this is a good fix.


soy

Well sorted mate.  Hope that has fixed it for you.  If you have a chance, could you post a small pic of the area containing the pins?  Also, could you remind me, looking from the ethernet end, which hashing board relates to which row on the web interface, please?  
Mine has averaged 440.27 since the last reboot, 13 hours ago and the temperature is the same for each board at 43.  If it stayed at that speed, I'd be very pleased, but in the past it's always started drifting down again at some point.  From reading your post, I think that I need to watch the temperatures when that happens and see if the one board starts running cooler than the other, indicating the lower hash.  I hadn't thought of doing that before, so thank you.