[Setup & Troubleshoot] Bitmain AntMiner S1 180GH/S miner

[Visesrion]

It's certainly an inadequate power supply. Seen this issue a couple of times. New power supply time, make sure it can deliver the needed amperage too. Alternatively, if you've got them lying around, use one power supply for each blade as an interim measure.

Any certain choice for the power supply that will work 100% sure ?

[jedimstr]

It's certainly an inadequate power supply. Seen this issue a couple of times. New power supply time, make sure it can deliver the needed amperage too. Alternatively, if you've got them lying around, use one power supply for each blade as an interim measure.

Any certain choice for the power supply that will work 100% sure ?

Make sure the power supply has enough amps on a single rail going to the PCIe connectors.
The 750W one is probably failing because it's splitting too much amps between multiple rails and not enough is going to the PCIe connectors.

Alternatively, you can get a cheap Server PSU and connect PCIe wires directly to the 12+v and Ground slots. 

I get my server power supplies and power adapters from http://www.gigampz.com/index.html
Cheaper and more powerful than regular PC PSU on the 12v rail.  I've been running two S1's for each gigampz modified HP Server PSU (1000w on 230v).  I highly highly recommend them.

[Raptor2213]

It's certainly an inadequate power supply. Seen this issue a couple of times. New power supply time, make sure it can deliver the needed amperage too. Alternatively, if you've got them lying around, use one power supply for each blade as an interim measure.

Any certain choice for the power supply that will work 100% sure ?

Any single-rail 600+ watt PSU that's 80 Plus certified should work for a single miner.  I personally use the EVGA 1000W P2.  If done right, this one can power 2-3.

[Biodom]

One of the recent batch (ordered at the first recent sales day) S1 works for 5 min, then disconnects, then in a few seconds beeps, then reconnects.
This cycle repeats all day long. What could be the cause?
i tried to reboot multiple times, switched off power supply, then back on-no cure. I have a feeling that I have a rare faulty unit. Thanks for any suggestion.

[klondike_bar]

One of the recent batch (ordered at the first recent sales day) S1 works for 5 min, then disconnects, then in a few seconds beeps, then reconnects.
This cycle repeats all day long. What could be the cause?
i tried to reboot multiple times, switched off power supply, then back on-no cure. I have a feeling that I have a rare faulty unit. Thanks for any suggestion.

70% likely its your power supply. after 3min or so the antminer is at full speed and after a minute or two of this your PSU is finally overloaded and switches off. a lot of power supplies will attempt to restart themselves when this happens

[klondike_bar]

So I got one client with an extrange case with his S1 miner.

He connects the miner with 2 pci connectors and it tries to start working, but after few seconds the power supply simply powers off.

If he simply powers up the blade with that holds the ethernet connector it works fine, but if he just tries to power up the other the power supply powers off again. The power supplly is a nox urano vs 750W. He also tried to put something on the 5V rail just instead the power supply was not balanced, but it doesn't work neither.

What can it be ?

a) The power supply
b) Broken board
c) other ?

Thanks in advance for any help 

his power supply might have multiple 12V rails. (lets assume 2 rails, each capable of ~320W).  If he uses both pci-e connectors that run off a single rail, the 360W+ draw of the antminer pops the PSU current protection.

[Biodom]

One of the recent batch (ordered at the first recent sales day) S1 works for 5 min, then disconnects, then in a few seconds beeps, then reconnects.
This cycle repeats all day long. What could be the cause?
i tried to reboot multiple times, switched off power supply, then back on-no cure. I have a feeling that I have a rare faulty unit. Thanks for any suggestion.

70% likely its your power supply. after 3min or so the antminer is at full speed and after a minute or two of this your PSU is finally overloaded and switches off. a lot of power supplies will attempt to restart themselves when this happens

Interesting...I am running this S1 on corsair CX500M, not overclocked, so it should be able to handle it. A faulty power supply unit? I will swith powersupply and see what happens. Big thanks!

[Raptor2213]

One of the recent batch (ordered at the first recent sales day) S1 works for 5 min, then disconnects, then in a few seconds beeps, then reconnects.
This cycle repeats all day long. What could be the cause?
i tried to reboot multiple times, switched off power supply, then back on-no cure. I have a feeling that I have a rare faulty unit. Thanks for any suggestion.

70% likely its your power supply. after 3min or so the antminer is at full speed and after a minute or two of this your PSU is finally overloaded and switches off. a lot of power supplies will attempt to restart themselves when this happens

Interesting...I am running this S1 on corsair CX500M, not overclocked, so it should be able to handle it. A faulty power supply unit? I will swith powersupply and see what happens. Big thanks!

Could also try powering only a single blade to check.

[Biodom]

One of the recent batch (ordered at the first recent sales day) S1 works for 5 min, then disconnects, then in a few seconds beeps, then reconnects.
This cycle repeats all day long. What could be the cause?
i tried to reboot multiple times, switched off power supply, then back on-no cure. I have a feeling that I have a rare faulty unit. Thanks for any suggestion.

70% likely its your power supply. after 3min or so the antminer is at full speed and after a minute or two of this your PSU is finally overloaded and switches off. a lot of power supplies will attempt to restart themselves when this happens

My problem is apparently solved (fingers crossed).

It was, actually, quite interesting. A combination of two factors:
1. this particular miner has a bit slower fan speed at higher temperatures. In my previous machines, they go to 2700-2800 rpm when temperatures rise to ~49-50, but the problematic unit stays at ~2100-2300 rpm.
2. The construction of the unit changed just a bit. On my March units, PWM fan cords hang by the side, but now they decided to tuck them inside of a plastic rail in front of the fan (I don't know how to post non website pictures here), which restricts the airflow toward the top left of the unit somewhat (when facing the fan from the exhaust direction).

As a result of both factors, on this particular unit, the airflow toward the inside (top part, where circuits are) of the unit was significantly restricted with chips located there being very hot on touch. I used a medium size Vornado fan, directing additional air flow toward the "hot" zone. No more disconnects overnight. Happy hashing!

[topminingcontracts]

One of the recent batch (ordered at the first recent sales day) S1 works for 5 min, then disconnects, then in a few seconds beeps, then reconnects.
This cycle repeats all day long. What could be the cause?
i tried to reboot multiple times, switched off power supply, then back on-no cure. I have a feeling that I have a rare faulty unit. Thanks for any suggestion.

70% likely its your power supply. after 3min or so the antminer is at full speed and after a minute or two of this your PSU is finally overloaded and switches off. a lot of power supplies will attempt to restart themselves when this happens

My problem is apparently solved (fingers crossed).

It was, actually, quite interesting. A combination of two factors:
1. this particular miner has a bit slower fan speed at higher temperatures. In my previous machines, they go to 2700-2800 rpm when temperatures rise to ~49-50, but the problematic unit stays at ~2100-2300 rpm.
2. The construction of the unit changed just a bit. On my March units, PWM fan cords hang by the side, but now they decided to tuck them inside of a plastic rail in from of the fan (I don't know how to post non website pictures here), which restricts the airflow toward the top left of the unit somewhat (when facing the fan from the exhaust direction).

As a result of both factors, on this particular unit, the airflow toward the inside (top part, where circuits are) of the unit was significantly restricted with chips located there being very hot on touch. I used a medium size Vornado fan, directing additional air flow toward the "hot" zone. No more disconnects overnight. Happy hashing!

My opinion is summer is coming and many miners will need to find a way to keep the miners as cools as possible with no doubt over 78 problems will start.

Regards

Juan

[brush242]

My opinion is summer is coming and many miners will need to find a way to keep the miners as cools as possible with no doubt over 78 problems will start.

Is that the reigning consensus? No higher than 78°C?

Mine barely crack 39°C now, overclocked to 393(?). Bit I'm sure that will change as it gets hotter in DC.

[bspurloc]

One of the recent batch (ordered at the first recent sales day) S1 works for 5 min, then disconnects, then in a few seconds beeps, then reconnects.
This cycle repeats all day long. What could be the cause?
i tried to reboot multiple times, switched off power supply, then back on-no cure. I have a feeling that I have a rare faulty unit. Thanks for any suggestion.

70% likely its your power supply. after 3min or so the antminer is at full speed and after a minute or two of this your PSU is finally overloaded and switches off. a lot of power supplies will attempt to restart themselves when this happens

My problem is apparently solved (fingers crossed).

It was, actually, quite interesting. A combination of two factors:
1. this particular miner has a bit slower fan speed at higher temperatures. In my previous machines, they go to 2700-2800 rpm when temperatures rise to ~49-50, but the problematic unit stays at ~2100-2300 rpm.
2. The construction of the unit changed just a bit. On my March units, PWM fan cords hang by the side, but now they decided to tuck them inside of a plastic rail in from of the fan (I don't know how to post non website pictures here), which restricts the airflow toward the top left of the unit somewhat (when facing the fan from the exhaust direction).

As a result of both factors, on this particular unit, the airflow toward the inside (top part, where circuits are) of the unit was significantly restricted with chips located there being very hot on touch. I used a medium size Vornado fan, directing additional air flow toward the "hot" zone. No more disconnects overnight. Happy hashing!

I've found all 11-12/2013 S1 models have fans that dont go higher than 2100 rpm. I replace them with fans out of Dell 390/380/t3400 etc... that fan is the one on all the units that go to 2800 rpm. the pins on the dell fans need to be moved to match the S1 fan pin 1 Blue/Yellow/Red/black/empty
I put 2 of these fans on and my units sit at 41-42 in a server room 43-45 out of server room

[Trends]

High-Efficiency 30-A Synchronous Buck Converter (ASIC Power supply) has Thermal Shutdown
TPS53355 monitors the temperature of itself. If the temperature exceeds the threshold value (typically 145°C),
TPS53355 is shut off. When the temperature falls about 10°C below the threshold value, the device will turn back
on. This is a non-latch protection.

[allinvain]

Anyone encountered an odd issue where all units stop hashing after several days (this happened to me before but now it occurred after 6 days of nonstop hashing)? I use 3 pool with ghash.io as the primary and it seems like the units switch over to the secondary and tertiary backup but never go back to the primary. Even if there was a brief issue with the primary pool they should all eventually retry the primary.

This would not be such a big deal but what is happening is that after some time they units stop hashing even on the backup pools - ie I see no increased share count on any of the pools. The hashrate counter looks like it maintains the same average. It's as if it's hashing into thin air.

The fix is to reboot the units, then they go back to hashing as normal.

All my units are running the Dec 26 firmware except one which is running the Fed 04 one, but it is doing the same thing.

I think this is a firmware bug, but I just wanted to hear if anyone else out there is experiencing the same thing.

[PatMan]

No issues here with mine, maybe a case of the redirect MITM attack? (I use p2pool - so safe )

Peace  

[klondike_bar]

so I had a miner show up today with one of its capactiors knocked out of whack. (The right-most, slightly smaller capacitor in the row of three found above/between each 'segment' of the PCB)

When I power on the unit, the green hashing light is and stays lit up (the secondary board isnt, as is normal). once hashing it flickers as usual.

the software will recognize only some of the chips at startup - anything from 2 to all 32. (right now it registers 16 and i can deal with that). the x'd chips are from all 4 segments.


The capacitor came off cleanly, and I hope to get it soldered back on first thing next week by someone with a bit more talent for the iron than I have. (id likely desolder a nearby component by accident). Right now I get 135GH with stock clocks (ie: 45GH for the working 16 chips)

[CosaNostra]

Having the same issue with ghash.io, not sure about other pools. Antminer's interface is showing regular hashrate, but not the pool ((( The problem appeared recently -- week or so. Anyone having this sort of issue with other pools?

Anyone encountered an odd issue where all units stop hashing after several days (this happened to me before but now it occurred after 6 days of nonstop hashing)? I use 3 pool with ghash.io as the primary and it seems like the units switch over to the secondary and tertiary backup but never go back to the primary. Even if there was a brief issue with the primary pool they should all eventually retry the primary.

This would not be such a big deal but what is happening is that after some time they units stop hashing even on the backup pools - ie I see no increased share count on any of the pools. The hashrate counter looks like it maintains the same average. It's as if it's hashing into thin air.

The fix is to reboot the units, then they go back to hashing as normal.

All my units are running the Dec 26 firmware except one which is running the Fed 04 one, but it is doing the same thing.

I think this is a firmware bug, but I just wanted to hear if anyone else out there is experiencing the same thing.

[Raptor2213]

Having the same issue with ghash.io, not sure about other pools. Antminer's interface is showing regular hashrate, but not the pool ((( The problem appeared recently -- week or so. Anyone having this sort of issue with other pools?

Anyone encountered an odd issue where all units stop hashing after several days (this happened to me before but now it occurred after 6 days of nonstop hashing)? I use 3 pool with ghash.io as the primary and it seems like the units switch over to the secondary and tertiary backup but never go back to the primary. Even if there was a brief issue with the primary pool they should all eventually retry the primary.

This would not be such a big deal but what is happening is that after some time they units stop hashing even on the backup pools - ie I see no increased share count on any of the pools. The hashrate counter looks like it maintains the same average. It's as if it's hashing into thin air.

The fix is to reboot the units, then they go back to hashing as normal.

All my units are running the Dec 26 firmware except one which is running the Fed 04 one, but it is doing the same thing.

I think this is a firmware bug, but I just wanted to hear if anyone else out there is experiencing the same thing.

I'm running Feb 2014 Firmware with cgminer 4.2.2a on ghash.io.  No issues.  Might try updating your cgminer.

[caution]

Anyone encountered an odd issue where all units stop hashing after several days (this happened to me before but now it occurred after 6 days of nonstop hashing)? I use 3 pool with ghash.io as the primary and it seems like the units switch over to the secondary and tertiary backup but never go back to the primary. Even if there was a brief issue with the primary pool they should all eventually retry the primary.

This would not be such a big deal but what is happening is that after some time they units stop hashing even on the backup pools - ie I see no increased share count on any of the pools. The hashrate counter looks like it maintains the same average. It's as if it's hashing into thin air.

The fix is to reboot the units, then they go back to hashing as normal.

All my units are running the Dec 26 firmware except one which is running the Fed 04 one, but it is doing the same thing.

I think this is a firmware bug, but I just wanted to hear if anyone else out there is experiencing the same thing.

Having the same issue with ghash.io, not sure about other pools. Antminer's interface is showing regular hashrate, but not the pool ((( The problem appeared recently -- week or so. Anyone having this sort of issue with other pools?

I'm having the same problem, units are hashing away normally but when checking on ghash it shows no work being done.  None of the failovers are showing work being done either, after rebooting the units start showing up on ghash.  I've lost too many days to this...going to try using a different pool as primary, see if ghash is the cause.

[kano]

Updated AntS1 cgminer binary to 4.3.2a
The binary and README are in my cgminer-binaries git here:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS1  <-- Follow this link to get the new binary

Read the README on the screen there for how to replace the /usr/bin/cgminer binary in your AntS1 with the new one.

Thus it includes a client.reconnect patch:
"minimise the risk of the man-in-the-middle attack of redirecting you to a different pool"

This, as usual, includes the cgminer patch for the luci web display.

There's info in the README to update the luci code if LSTime is showing incorrectly after the update
(most newer AntS1's)

I've also documented steps to update the cgminer-monitor to restart cgminer if Elapsed Time is greater than 4 weeks.
This usually means the clock has messed up on the AntS1.
If you do mine for 4 weeks non-stop, it's simply a cgminer restart so no problem.

My source for this version is here:
https://github.com/kanoi/cgminer/tree/ants1-4.3.2a-85fcf0c

This binary includes all cgminer changes up to 4.3.2 and forward after that up to:
https://github.com/ckolivas/cgminer/commit/686d648f15d6c70f252c411242ecd7edc7294f90