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

[wolf_miner]

Hi, after CGMINER update LST data is correct in Miner status interface?

W_M

[Raptor2213]

Hi, after CGMINER update LST data is correct in Miner status interface?

W_M

No, it's a known bug.  Kano posted on this a few pages back.

[brush242]

mine is running steady at 200ghs.
Added an extra fan, cut 2 cables per fan, the control cables so they run at 100%
Added plexi, turned it upside down. somehow this took away 3°C
Running smooth @ 39&40°C

As usual, I am not a thermodynamicist, but when I first saw these things I thought, "Damn it, that curve should go the other way." Having said that, wouldn't it be better to flip it, and NOT put plexi on the top? Or possibly, flip it, don't put plexi on the top or bottom, and just rest two fans blowing upward on the new "top" of it?

Did you cut both the yellow and the red cables for the fan?

Thanks!

[samsonn25]

mine is running steady at 200ghs.
Added an extra fan, cut 2 cables per fan, the control cables so they run at 100%
Added plexi, turned it upside down. somehow this took away 3°C
Running smooth @ 39&40°C

As usual, I am not a thermodynamicist, but when I first saw these things I thought, "Damn it, that curve should go the other way." Having said that, wouldn't it be better to flip it, and NOT put plexi on the top? Or possibly, flip it, don't put plexi on the top or bottom, and just rest two fans blowing upward on the new "top" of it?

Did you cut both the yellow and the red cables for the fan?

Thanks!

A little hard to put upside down to plug power and ethernet wires when you have multiple units. But I found sideways and stacked on each other space efficient.

[wolf_miner]

Tanks Raptor2213, I have tryed the solution posted on the git but don't work for me.

Code:

 The easy fix for this - provided on the bitcointalk forum by artpego,
is to edit /usr/lib/lua/luci/controller/cgminer.lua to undo the change
commented out in there. Around line 287, look for:
  --lst_date = os.date("%c", lst)
  lst_date = lst
and change it back to:
  lst_date = os.date("%c", lst)
  --lst_date = lst

W_M

[brush242]

As usual, I am not a thermodynamicist, but when I first saw these things I thought, "Damn it, that curve should go the other way." Having said that, wouldn't it be better to flip it, and NOT put plexi on the top? Or possibly, flip it, don't put plexi on the top or bottom, and just rest two fans blowing upward on the new "top" of it?

Did you cut both the yellow and the red cables for the fan?

A little hard to put upside down to plug power and ethernet wires when you have multiple units. But I found sideways and stacked on each other space efficient.

Well, sure, of course. Do you find that the upper blade runs significantly hotter than the lower? I would assume all that radiant heat rising from the lower blade would make a difference. Do the fans handle it well?

[InvalidSnack]

has anyone used public/private keys to access the ants ?  

I am always prompted for the password after setting up keys.

bump... anyone using ssh and pub/priv keys?

I didn't want to be that guy who posts "yep and no problems on my end..."  (adding nothing to the discussion/troubleshooting, etc)

But since you're asking if people are using them, yes, I am.  Four units, and I sat here for a few minutes just now trying to recall if I did anything weird or unusual -- vs setting up ssh to server, or to a Raspberry Pi / router / embedded system / etc.  And I honestly can't think of anything I did differently.  It was just as hard/easy as setting up ssh into my Kindle.

I'm not trying to dismiss you, I just can't think of anything required (beyond just general knowledge of how to use ssh in general) for you to avoid this kind of problem.  (With respect to the person who posted on the previous page that "pubkey authentication usually asks for a password also," ignore what he said.  The whole point of using a public/private keypair here would be to *avoid* having to type your password, otherwise it would just be a really silly way to waste time and overcomplicate the login process.)

So I'm going to take the shotgun approach and reply with every possible way to fix every possible thing that might be causing this issue -- and by "every" I mean "all the ones that come off the top of my head, at the moment, and seem remotely likely."  So YMMV, as in all things.

So, I don't mean to talk down to you at all, but I obviously can't know your particular skillset -- so forgive me for asking, but do you actually use ssh all that much?  Have you set up ssh with private key authentication before, say to connect to your home server/router?  Or is this pretty much the first time you've tried to set something like this up?   (And if it's not the first time, then what did you do in the past -- and what are you doing differently this time?)

Yes, a server can be set up to ask for passwords, pubkeys, and/or it can accept both.  But the ants are set up the normal/sane way -- passwords are accepted, but you can provide your public key info if you'd prefer to skip the password prompt.  The ant will not (unless you have changed the configuration of the actual sshd *server* running on your ant from its default config) ask you to give it a password after a successful public key authentication attempt.  

So that means a password prompt is *generally* a sign that you've failed provide valid login data -- which generally ends up being caused by one of the following:

• 1. the public key is fine, but the username is wrong (very common)
• 2. the public key data is not correctly installed on the server (also common)
• 3. the public key on the server does not match the private key you're trying to authenticate with  (less common)

Let's take them in the order listed above:

• 1. Let's say your username on your local machine is "ruth."  If you try to ssh into the ant like this:
  
  ssh ant0 # where ant0 is your ant's IP or hostname
  
  ...then you're going to get denied access (because you supplied no username, and ssh assumes you want to login as ruth).  Sometimes you'll get a password prompt, because you're essentially trying to log in with a password/key that doesn't correspond to a given user...so it naturally asks you for a password that DOES work. Other times you'll just flat out get denied access; it just depends on how the server is set up.
  
  You're providing authentication/key data for the "root" user.  So let's explicitly tell the server we want to use your key but with a different username:
  
  ssh root@ant0  # the "root@" tells ssh to override the default, which is to try to log in to the ANT using the username for your local computer.
  
  That's a *really* common error, and if that fixes it, then there you go.  (You can type "man ssh" in linux for info on the ~/.ssh/config file, which you can use to override this behavior -- ie, you can tell it "whenever I log into ant0, assume I want to login as 'root' and not my regular username."  If you set that up, you'll be able to just do "ssh ant0" and it will work correctly.)
  
  
• 2. It's possible you borked the cut-and-paste; hey, we all do it from time to time.  Just go to the Admin console, find that SSH key section, go ahead and delete everything out of there and hit save+apply.  Now, with a fresh (empty box), go open up (assuming you're using linux; otherwise you can google the instructions for doing this in Putty) your public key data, which is stored in /home/yourUserName/.ssh/id_SOMETHING.pub
  
  The file name has changed once or twice, and it also depends on if you're using RSA or something different -- but since I set up my ssh with an RSA keypair, my public key data is /home/myUsernmae/.ssh/id_rsa.pub   (Note, there is another file called "id_rsa" -- without the ".pub."  Do not use this; it's your PRIVATE key, and if you try to paste that into the Luci config page on the antminer, it's going to just seem like garbage data to the server...and you'll get a password prompt.)   Copy the contents of that id_rsa.pub (or whatever your file may be called) and paste all of it into the box in the Luci config.  It should be one very big long line of text.  (If it wraps in the Luci configuration textbox, that's fine -- just make sure you're not copying the key in there with a bunch of whitespace or newlines in the middle of your key.)  
  
  Hit Save+apply, and it should restart sshd/dropbear and allow you to login immediately.  If the problem persists, it's possible the ssh daemon was not reloaded correctly; you can try cycling the power and see if that helps.  Then just login as before:
  
  ssh root@ant0
  
  And it should work; IF NOT, then it's possible you're pasting garbage into the antminer because you're starting out with garbage.  (Ie, your private/public key might be corrupt in some way -- or in some weird incompatible format that dropbear doesn't understand.)  If you think this might be the case, generate a new keypair -- stick with RSA and all the default settings; dropbear doesn't support every algorithm out there, IIRC.  
  
  If you need info on how to regenerate your keypair ... google is your friend because that's beyond the scope of this reply. :)
  
  Finally,
  
  
• 3. If you have more than one public/private keypair -- say you have one from your work machine, that you copied and brought home and put in your .ssh directory, as well as the default keypair you generated when you first installed the ssh client -- then it's possible you're trying to authenticate with the RIGHT username but the WRONG key; which is just like typing your password incorrectly, hence the antminer asking you to re-enter your password.  (It prompts you for your password, because "Please retype your public key again:" would be a somewhat lengthy/obnoxious demand.  That's why it reverts to just asking the standard vanilla password.)
  
  So let's assume i have two keys in my ~/.ssh directory (again, this is Linux -- if you run windows, check Putty's help pages for info on where you get public/private keypair info).   In fact, that's actually the case for me --  I have an older ssh key I used a long time ago when I was managing a number of systems from my android phone.  I archived/copied that over to my ~/.ssh directory when I upgraded my phone -- so it lives in there along side my default (regular) system key.  So in my ~/.ssh directory, I have:  
  
  phone_rsa.pub
  phone_rsa
  id_rsa.pub
  id_rsa
  
  The first two are there because I placed them there when I copied /archived off my phone, so there's no naming convention being followed there, just whatever I happened to call them at the time.  The second two keys make up the pub-priv keypair created by my local system and they are used by default, unless I specify something different.  
  
  So imagine if I copied my phone_rsa.pub key into the Luci/antminer interface and hit "save."  Great, now I can log in via my phone.  But what if I wanted to log in from my laptop as well?  That's fine, I've got the keypair in my ~/.ssh/ directory (as shown above), so I should have everything I need to get access.  However, if I tried to login from my current system like this:
  
  ssh root@ant0
  
  It would fail, because phone_rsa.pub is on the server (ie, the antminer) but I'm supplying id_rsa (the WRONG local private key) by default.  The solution is to explicitly tell ssh I want to use phone_rsa:
  
  ssh -i ~/.ssh/phone_rsa root@ant0 # tells the ssh client to log in as user root and authenticate with the phone_rsa keypair
  
  And if that looks like a lot of typing, well, yeah...you're right.  Probably just easier to type in your password!  But, remember you can fix this in a couple of ways:  either (1) put your default public key in the Luci config screen and quit trying to log in with the wrong key, or (2) you can check out the man page for ssh and set up your ~/.ssh/config file (discussed earlier) and tell it which keypair you want to use when logging in to that particular host (ant0).  And while you're at it, you can tell it to assume your username is "root"  -- at which point we can finally log into ant0 as follows, and it will work as expected:
  
  ssh ant0 # works fine with the correct username (root) and keyfile defaults overridden in ~/.ssh/config file
  

And hopefully, once you've read through all of that you've either:

1. Found the problem and fixed it!  (Problem solved.)  Or,
2. Lost all patience and decided it's too complicated and not worth the effort, you'll just use passwords.  (Problem solved.)

I hope this has helped a little -- and maybe you're a little bit closer to #1 than #2 (giving up and using passwords) when all is said and done.  Good luck!

(Apologies for the long post, everyone.)

[samsonn25]

As usual, I am not a thermodynamicist, but when I first saw these things I thought, "Damn it, that curve should go the other way." Having said that, wouldn't it be better to flip it, and NOT put plexi on the top? Or possibly, flip it, don't put plexi on the top or bottom, and just rest two fans blowing upward on the new "top" of it?

Did you cut both the yellow and the red cables for the fan?

A little hard to put upside down to plug power and ethernet wires when you have multiple units. But I found sideways and stacked on each other space efficient.

Well, sure, of course. Do you find that the upper blade runs significantly hotter than the lower? I would assume all that radiant heat rising from the lower blade would make a difference. Do the fans handle it well?

No heat problems as they run stock frequency.  The stock fans are 125-130 cfm fans, quite stronger than most aftermarket case fans the same size.

[jjiimm_64]

And hopefully, once you've read through all of that you've either:

1. Found the problem and fixed it!  (Problem solved.)  Or,
2. Lost all patience and decided it's too complicated and not worth the effort, you'll just use passwords.  (Problem solved.)

I hope this has helped a little -- and maybe you're a little bit closer to #1 than #2 (giving up and using passwords) when all is said and done.  Good luck!

(Apologies for the long post, everyone.)

Thank you very much for your input.. 

I have used keys and set up keys before, cant say I am an expert, but I've used them..

1. used puttygen to create the pair
2. put the public key into authorized_keys
3. set putty to use either pageant, or directly to the local priv key file..

still getting prompted.

I will start from scratch and try again.


I really want this to work, because I need to scp files to all ants..... especially /etc/init.d/cgminer .  the start script is not allowing a switch pools command via rpc without this change.

 

[jimrome]

And hopefully, once you've read through all of that you've either:

1. Found the problem and fixed it!  (Problem solved.)  Or,
2. Lost all patience and decided it's too complicated and not worth the effort, you'll just use passwords.  (Problem solved.)

I hope this has helped a little -- and maybe you're a little bit closer to #1 than #2 (giving up and using passwords) when all is said and done.  Good luck!

(Apologies for the long post, everyone.)

Thank you very much for your input.. 

I have used keys and set up keys before, cant say I am an expert, but I've used them..

1. used puttygen to create the pair
2. put the public key into authorized_keys
3. set putty to use either pageant, or directly to the local priv key file..

still getting prompted.

I will start from scratch and try again.


I really want this to work, because I need to scp files to all ants..... especially /etc/init.d/cgminer .  the start script is not allowing a switch pools command via rpc without this change.

 

key files are in a different location that a standard linux distro: look in /etc/dropbear for ssh files e.g.

Code:

root@antminer-6:~# ls -alt /etc/dropbear/
-rw-r--r--    1 root     root          1214 Apr 10 09:02 authorized_keys
drwxr-xr-x    1 root     root             0 Feb 21 14:17 .
-rw-------    1 root     root           459 Dec  1 20:28 dropbear_dss_host_key
-rw-------    1 root     root           427 Dec  1 20:28 dropbear_rsa_host_key
drwxrwxr-x    1 root     root             0 Dec  1 20:28 ..
root@antminer-6:~#

[jjiimm_64]

key files are in a different location that a standard linux distro: look in /etc/dropbear for ssh files e.g.

Code:

root@antminer-6:~# ls -alt /etc/dropbear/
-rw-r--r--    1 root     root          1214 Apr 10 09:02 authorized_keys
drwxr-xr-x    1 root     root             0 Feb 21 14:17 .
-rw-------    1 root     root           459 Dec  1 20:28 dropbear_dss_host_key
-rw-------    1 root     root           427 Dec  1 20:28 dropbear_rsa_host_key
drwxrwxr-x    1 root     root             0 Dec  1 20:28 ..
root@antminer-6:~#

this is a handy bit of info..

thank you

[brush242]

As usual, I am not a thermodynamicist, but when I first saw these things I thought, "Damn it, that curve should go the other way." Having said that, wouldn't it be better to flip it, and NOT put plexi on the top? Or possibly, flip it, don't put plexi on the top or bottom, and just rest two fans blowing upward on the new "top" of it?

Did you cut both the yellow and the red cables for the fan?

A little hard to put upside down to plug power and ethernet wires when you have multiple units. But I found sideways and stacked on each other space efficient.

Well, sure, of course. Do you find that the upper blade runs significantly hotter than the lower? I would assume all that radiant heat rising from the lower blade would make a difference. Do the fans handle it well?

No heat problems as they run stock frequency.  The stock fans are 125-130 cfm fans, quite stronger than most aftermarket case fans the same size.

May I ask why you run stock frequency?

[samsonn25]

As usual, I am not a thermodynamicist, but when I first saw these things I thought, "Damn it, that curve should go the other way." Having said that, wouldn't it be better to flip it, and NOT put plexi on the top? Or possibly, flip it, don't put plexi on the top or bottom, and just rest two fans blowing upward on the new "top" of it?

Did you cut both the yellow and the red cables for the fan?

A little hard to put upside down to plug power and ethernet wires when you have multiple units. But I found sideways and stacked on each other space efficient.

Well, sure, of course. Do you find that the upper blade runs significantly hotter than the lower? I would assume all that radiant heat rising from the lower blade would make a difference. Do the fans handle it well?

No heat problems as they run stock frequency.  The stock fans are 125-130 cfm fans, quite stronger than most aftermarket case fans the same size.

May I ask why you run stock frequency?

1.  It is more efficient to run at that frequency. 

2.  Less heat, more longevity for the chips.

2.  I had 6 miners in one room on a 20amp breaker and that was the max, over clocking would have yielded less hashrate at that power limit.  With unlimited power you can over clock for more hashrate but chips are less efficient.  For example another 10% increase in hashrate would need 20-25% more energy, etc.  15% over clock would need 35-40% more energy.

[smooth]

2.  I had 6 miners in one room on a 20amp breaker and that was the max, over clocking would have yielded less hashrate at that power limit.  With unlimited power you can over clock for more hashrate but chips are less efficient.  For example another 10% increase in hashrate would need 20-25% more energy, etc.  15% over clock would need 35-40% more energy.

Be careful friend. 6 stock S1s on a 20 amp is too much, in theory at least.

[samsonn25]

2.  I had 6 miners in one room on a 20amp breaker and that was the max, over clocking would have yielded less hashrate at that power limit.  With unlimited power you can over clock for more hashrate but chips are less efficient.  For example another 10% increase in hashrate would need 20-25% more energy, etc.  15% over clock would need 35-40% more energy.

Be careful friend. 6 stock S1s on a 20 amp is too much, in theory at least.

I know the 1920 watt is the safe 80% limit of the 2400 watt rating for 20amp but you know there is always wiggle room.  Had 3 platinum psus and We specially ran a new connection to the breaker with the correct 12 guage wires not just changing the fuse from 15 to 20.

[BoogieMan82]

The system/software field will never update.  I asked this question a few pages back.  You can verify the version by typing a command in the SSH shell.  cgminer -V, I think.

PERFECT!!! , This was my error. I can see the it.

cgminer 4.2.2a

Thank you very much.
Regards.
Antuam

I'm glad that someone got to you! 

[theglock]

hey sushi! sorry i bought them recently, have followed your orders and they still dont seem to work would it be ok to ask you whether you could use teamviewer and give it a go? Its really getting me and its been a month now

[gjpminingco]

I can Give you a hand if you would like

[kano]

Tanks Raptor2213, I have tryed the solution posted on the git but don't work for me.

Code:

 The easy fix for this - provided on the bitcointalk forum by artpego,
is to edit /usr/lib/lua/luci/controller/cgminer.lua to undo the change
commented out in there. Around line 287, look for:
  --lst_date = os.date("%c", lst)
  lst_date = lst
and change it back to:
  lst_date = os.date("%c", lst)
  --lst_date = lst

W_M

Make sure you restarted cgminer.

Then post 2 things:

Screen capture of the web page showing LSTime

Text output, after you login to your ant, of the command:
cgminer -V

(edit: and a pastebin of /usr/lib/lua/luci/controller/cgminer.lua )

[kolsernik]

Hi. I need help. This problem. Today I received a Antminer S1:
http://yadi.sk/d/i3324BBtMSpGF
C430 and C424
What are these capacitors?
100nF Capacitor (1608) 6,3v?