Topic: [Guide] Dogie's Comprehensive Bitmain AntMiner S2 Setup [HD] - page 16. (Read 63123 times)

Oh, yeah, I'm pretty sure the Miner Config page is hard coded to expect certain types of values -- and if it doesn't see them, it resets them or erases them or whatever.  I don't use the GUI all that much (just the status page sometimes to check on the "oooooo" status of the chips) but I remember people with custom configs on the S1 (eg, with more than 3 pools set up -- when there was only room for 3 to display on the GUI web form) would run into lockups or various problems as the GUI tried to deal with all the extra data that it didn't think ought to be there...

So your problem might be that the GUI is screwing with your config when you try to look at it to "confirm" your config is working.  It probably doesn't expect to see any weird ass "number-then-a-semicolon-then-a-url" shenanigans in the "url" field...  Oh, and actually now that I think about it, we are REMOVING the url field and replacing it with a quota field so I can imagine the web form *might* be assuming we left those values blank or that the file is corrupt ...or whatever random assumption it might make, it seems safe to assume it's probably not all that great for what we're trying to do. :)

Instead, try setting up your configuration file (per my previous post), restart cgminer (/etc/init.d/cgminer restart or it might be /etc/init.d/cgminer.sh restart sorry not in front of the machine right now so I can't check) while you're still logged in via SSH.  It will reload your config file and should start hashing again -- but without a reboot, and without having to go click anything on the web form...so we can eliminate those two possible variables for the time being.  That way you can at least confirm you don't have a typo in the config file, or something along those lines.

So long as you keep your changes confined within the /config directory, it should survive any reboots, because that's the only directory that actually persists between sessions.  Try it one more time, and (instead of rebooting) restart cgminer, then once you see the box is hashing again (flashing green lights) enter the following:
That should reconnect you to the screen session and you should be able to diagnose any problems from there....assuming you've used cgminer in other situations and you know what it "ought to look like" (otherwise it'll be no more or less confusing than anything else!).  For reference, here is a shot of what mine looks like when I issue the command above.  I'm leaving out the unimportant "job xxx accepted" crap, yours will have all kinds of extra data too.  We're just focusing on the top third of the screen:


The first thing to look for is on the 5th line from the top, where it says "Connected to multiple pools with block change notify."  If you don't see that, then you have a typo in your config somewhere (perhaps you're still using "url" and not "quota" lines in the pool definition section?) or you failed to add "load-balance" : true, to the file.  

Alternatively,
Anyway, if you don't have load-balance or balance set in your config file, then that line I referenced above will say something akin to "Connected via Stratum to stratum.btcguild.com:3333 with diff 512..."  

Assuming you *do* see the lines about "connected to multiple pools" then you can hit the 'P' key (for some reason I had to hit it five or six times before cgminer actually showed me the menu -- so don't worry if it is sluggish to appear) and you should see something like the following, but with your pool data of course:


Again, refer back to my first post (1 or 2 pages ago) to see the config file that corresponds to this screen.  But you'll note that the numbered list shows that pool 0 and pool 1 both have a quota of 50, while pool 2 has a quota of 0 (failover only).  Also, here is a good place to confirm that your config file has no typos -- note that the 5th line from the bottom says "Current pool management strategy: Load Balance."   So that shows my cgminer.conf file is indeed set up for load-balance and is working fine...and this is fresh from a reboot (well, fresh as in "I rebooted late last night") to make sure I wasn't leading you astray about the file persisting across sessions/reboots.  

Note that (4th line from the bottom) it says: "[F]ailover only disabled."  That's the way it should look (if you're unfamiliar with cgminer -- if not, then I apologize for what probably seems like I'm talking down to you -- certainly not my intent!) and if it doesn't look that way, make sure your config file doesn't have any additional parameters that could be screwing with stuff -- eg, I have no clue what "failover-only" : true, would do if combined with "load-balance" : true, in the conf file, but it seems safe to assume one of them would "overrule" the other.  Or at least confuse things!

(Obviously if you decide to use regular "balance" instead of "load-balance" as your management strategy, then the line 5th from the bottom would say "balance" and you wouldn't see all that quota crap in the numbered list of pools.)

Now -- again, apologies if you know all this already -- if you're ready to get the hell out of that screen, or anything running under a GNU screen session for that matter, you hold the control key and press A...then you release both keys...and then you hit 'D'.  So "Ctrl+A, D."  [spoiler]lol, I tend to catch myself thinking "And...Disconnect" so I guess that's how I tend to remember that combo.  Fans of Emacs will remember that combo because they use that, plus tons of other similar combos, all the time.  Fans of vi will think that's crazy, why not just type "Escape, colon, q, exclamation point, enter" -- something intuitive like that?! :)   Fans of sanity will think both of these hypothetical guys are crazy...but they'll also be wise enough to never say such heresy out loud![/spoiler]

If you disconnected from the screen session successfully, you'll find yourself dumped back at a normal/familiar root@s20~# prompt, at which point it's safe to exit...assuming things are working okay.

Now, if they *are* working okay, you can experiment to see if it's really the GUI that is mucking up your config file.  First, make a copy of your (currently functional) cgminer configuration file:
Now load up the web GUI, just cruise over to the page and view the page.  (Don't change anything, and certainly don't *apply* anything from the cgminer config page on the website -- if you did that before, then that's probably what wiped out your load-balance config and replaced it with a standard failover setup.)  Does it look okay?  Broken?  Same as before?  

Alt+Tab over to your ssh window and type
...and see if the file has changed.  If you're unsure, check the last time the file was modified:


Note that the clock is running on UTC time by default, so it might be worthwhile to check the current time as I did, just to make sure you're not comparing apples and oranges.  So if you look at the stuff above, you can see that the last edit to my config file was roughly a day and a half ago...so it definitely persisted through the reboot yesterday.  But more importantly, you can see that nothing has gone behind my back and changed it AGAIN since I edited it....however, I didn't go mess with the web GUI, since I don't use it to set up configuration stuff (it's easier for me to just scp over known-good config files that I've saved from another system, or edit the image when I first prepare the sdcard for the S2...plus you never know what kind of weird stuff the GUI might overwrite) and I don't have immediate access to the system right now so I didn't want to (potentially) do whatever it is you're doing and reset my own file, because that would be annoying. :)

I'm pretty sure you can use the "Status" screen all you want in the GUI.  It's the "Miner Setup" page that has the potential to screw with your configuration file, I *think*.  So none of this prevents you from using that to monitor your system, if that's how you roll.  Note however that you can use other methods (from the command line while logged in via ssh, or even via your local machine if you have the API set up correctly) to check your work.  So, one final example before I go -- and let's hope *some* of this helped you, since apparently my last message failed to do anything but annoy and frustrate you further!  Kind of like going "hey look at what I can do...hahahahaha...this is what it looks like when your settings persist!"  But I assure you that wasn't my intention! :)

When you think you have load-balance working and you want to check from the command line, enter the following, and then use enter or spacebar to page through the results.  I'm doing this via ssh on to the S2, but you can also do this remotely if your API is set up correctly -- which I will leave as an exercise to the reader.  
The command is:

As you page through the info that is displayed, you should see all the stuff we set up in the configuration file -- there should be at least two pools (or three, depending on your configuration setup.  I suppose there could be *one* but load-balancing *one* pool server would be...a questionable use of one's time.), zero indexed, so you'll see info for POOL0, POOL1 and so on.  The main thing to look for here is -- assuming you just restarted cgminer a few minutes ago -- are your (different, load-balanced) pools each completing work successfully, or are you (mostly) still just submitting work to POOL0?  

You can also see (if your config file is setup correctly) there will be entries like [QUOTA] => 50, showing that your quota setup in the config file is being applied correctly.  But mostly if you see that POOL0 and POOL1 have approximately their "fair share" of work listed under their [Difficulty Accepted] => xxyy sections, then you can rest easy that things are working properly.  (Double check by going to your pool's site -- eg, btcguild or wherever -- and make sure that it is estimating your hash speed to be somewhere in the neighborhood of what it *should* be getting.  Obviously the pool's estimate is an approximation -- but if something is really screwed up (say your rejected shares are really high on one pool only, due to using the wrong username or something like that) it's possible for cgminer and the GUI to show that you're happily hashing away at 1015Gh/s ...even though as far as the pool is concerned, you're doing *nothing* or very little!  I know that seems obvious, but when I was experimenting around with some of the settings a few days ago, I managed to find a terribly unfortunate combination of config options that resulted in BTCGuild rejecting the vast majority of my shares, while the GUI and API and cgminer ncurses display all implied I was hashing just fine.  It wasn't until I checked and noticed that the *pool* thought i was running around 50 GH/s (and not 500GH/s) that I realized I had "load balanced" myself in such a way that half of my hashrate was going to one pool...and the other half was going down the drain!  

But, oops, I digress.  Again.  (Because it's what I do.)

But, freebit13, I sincerely hope this helps you troubleshoot your "mysterious resetting issue" and I really am sorry that my earlier effort led you down the path of "lots of time invested, with zero return!" :)  Hopefully we can get this figured out for you...since (as i mentioned in the previous post) I was hunting around for info on this exact same thing a few days ago, so I assume there are others who will want to do it, too.  And since everyone knows "Dogie's Comprehensive(TM) is the most trusted brand of forum-based documentation for ASIC configuration," I'm sure some of them will come to this thread...
[/color]


edit: PS, this *might* not be strictly relevant, freebit13, but if you continue to have trouble duplicating (on your box) the setup I have working on mine, it might be useful to know some info about your setup, eg: What batch S2 do you have, is it the stock SD card or did you upgrade it to a Class 10, what firmware are you running, do you have a sister and is she single and if not does she have any hot friends?  (You know, standard "background" stuff.  it's important for the whole "troubleshooting" process.)  

Because when you post a question on Dogie's Comprehensive(TM) you know you can expect thoroughness ... even (and perhaps especially) if we don't actually solve your question or help you at all.  Which, I guess, so far would be the case here...um...I guess I will hit submit and hope things go better this time! Good luck!

Are you sure it's the board and not the pci slot? I've had X's show up from bent pins in the slot. If you swap the board out with another, do the X's still show up for that board in another slot or for the one in slot7?

Thanks for the tips InvalidSnack, it's helped me learn a few things, but I can't get my S2 to work with your code, it just seems to erase the url from the Miner Configuration in the GUI. I've tried a few other things to no avail, but I'll have a look at this on the weekend when I have a bit more time.

If you know its to do with that volt reg though, now you can take it to a local electronics shop and ask them either to resolder the legs or replace it entirely. The reg will cost literally $0.20 and they enjoy soldering.

Ah, I spoke to soon, I updated my miner configuration and the ---xx-- are back!  It's dropped to 960 GH/s average as well.

Ok, please help. 

Now I know solo mining is now, what most would call, a waste of time.  Fair enough! 

But I have an S2 and cannot for the life of me get it to solo mine my up-to-date Bitcoin-qt.  I have tried all sorts of configurations.  I have even contacted Bitmain but to no avail.  Now, a lot of you have .config sorted well ahead of me.  Someone must know what is needed, like changing some configurations in the cgminer or Bitcoin.conf.  I can get the miner to go live in the Antminer configurations to my local IP but it does not hash and the beeper sounds after about a minute.  I have strangely, managed to push my miner through bfgminer proxy that runs my erupter cube on 8330 but reduces back to only half hash rate.  Cannot be right. 

Any advice would be appreciated.

I just want to have the option.  Currently, I do not have that.

Ta

Cheers.  I'll quit my whingin' then!

991 is perfectly fine, mine varies between 990 and 1010ish.

Thanks for the advice regarding slot direction, people.

I had (maybe still have) a single board that was showing -----xxx-- in the first three groups of the seventh board.  The hash rate, after 14 hours, would land around ~950 GH/s.

Now I know a ton of people received machines that didn't make it through shipping, so I don't have any real room to complain, I'm just hoping to resolve the issue with the board so it runs to spec.

I contacted BM, and their engineer suggested I remove the board and "press each chip on the issued board with your finger."  This, off the bat, sounded crazy to me but I wanted to do my due diligence in case we need to RMA the board.  Today I removed the board and used a static free cloth to firmly "press" all the components.  It seemed crazy, but I did notice a solid "click" sound when I pressed the voltage regulators.  When I replace the board and fired it up, everything looked great, no x's and the average hash after 15 minutes was above 1TH.

That said, the average has slowly crept downward, and I'm looking at 991.84 after two and a half hours via the GUI.  I'm still waiting on Eligius to show my three hour average to see what that looks like, but it appears that I may still have an issue with that board.

Is this within spec; am I crazy?

I was actually trying to figure this out a couple of days ago and ran into the same problem you did.  We were both trying to modify the /etc/init.d/cgminer startup script; it's just a bad habit we picked up from modifying our S1s.  (By "bad habit," I mean we learned to do it that way because the S1 used a non-standard configuration file for cgminer -- so we couldn't just plug the values into the conf file without hacking around in init.d first.)  

I don't follow (at all) why Bitmain decided to "lock down" the S2 so much, making so much stuff reset automatically -- it seems like they went out of their way to make this thing difficult to customize for my tastes.   For example, on all my S1s, I used to have a couple of scripts installed locally to grab quick values from the API I was frequently looking for...and I had a couple of (very simple) cron jobs that ran twice a day, nothing earth shatteringly impressive -- but at least I could put a damned script file in my path, and modify my .profile, and at least cron was INSTALLED.  (And speaking of installation -- I will always have a fondness in my heart for vi, since that's what I first learned to use on the first UNIX-based system I ever came in contact with.  But nano is easier; and on the S1 it could easily be installed from the GUI.  I haven't really bothered to try to figure out how to install nano via opkg -- because I assume the damned thing would just lose any changes on reboot anyway.)

And what about my damned ssh pubkeys?  Every time that stupid thing reboots I have to ssh-copy-id my pubkey over *again*....unless I want to type the password every time I log in to do anything...which is annoying because (as anyone reading this has figured out) it would seem I am lazy as fuck. :)

*ahem*  but I digress.

Fortunately, the "how do I load balance" question is easier than you think -- because the  S2 (as far as I can tell) uses a standard cgminer.conf file structure in the /config/cgminer.conf file.  If you type you'll see that cgminer is loading directly from that file, so if you cruise over to the cgminer thread in this forum, or grab a copy of the README from github, you can see all the myriad options available...  almost any option you *could* put in the cgminer commandline can be placed in the JSON-formatted cgminer.conf file (located in /config/)...including those needed for load balancing.

Okay okay, enough prefacing.  Here's a practical (working) example taken from my S2.  First, let's look at the original (NON-LOAD-BALANCED) cgminer.conf file, which is just the original one that shipped with the machine (edited with my pool info, etc):


Okay, so nothing special -- other than the mining pool details and the changes I made to the "api-allow" line so my monitoring script could reach/query the thing, that's pretty much stock.

If you want to modify this to work in load-balance mode, per the cgminer README, you'll need to do the following:

• Add the parameter "load-balance" : true, to the conf file
• Change all the "url" lines (under the "pools" section) to "quota" lines, and modify the URL string so it contains the percentage of time you want the system to devote to each pool, then a semicolon, then the URL, like this: "quota" : "50;stratum+tcp://stratum.btcguild.com:3333",
• Look at the example below, since this explanation probably doesn't make any sense at all (but once you see an example you'll realize it's easy and you'll have yours up and running in a couple of minutes, tops).

So let's head back and look at my current (load balanced) file -- compare it with the one listed above, and you should be able to apply the same differences to yours with no problems.  Note that I just want to split my S2's time between two pools -- so the third pool gets a quota of "0."  That doesn't disable the third pool; it just sets it to be a backup/failover pool:



Now, if anyone out there knows anything about Dropbear -- I'm assuming the reason the dropbear config file is in /config (and thus will exist across reboots) is that there must be a way to tell the ssh daemon "authenticate using the ssh keys located in /config/authorized_keys , instead of the default, because I would like to quit copying them over every time I issue a shutdown or reboot command!"  I'm assuming there must be a way to say that in the /config/dropbear file, I just haven't had the time to go look up all the various dropbear options...so if anyone knows how to do this off the top of their head, please share!


(Or for that matter, if anyone knows how to make a larger portion of the S2's filesystem "persistent" without having to go through the trouble of writing a custom firmware for it -- that would be GREATLY appreciated.  Because I would like to be able to update cgminer (and other files) when/if Kano starts releasing updated binaries for this platform, as he did with the S1.  And I would like to install cron...and nano...and "whatever I damned well please" because surely the BeagleBone supports this kind of "crazy advanced behavior" ...right?  Right?  Anyone?  I admit I know next to nothing about modifying firmware images ...this seems like *such* a step backwards from the way the S1s were setup, I wonder why?  Okay, diatribe over.  For now...!)

I hope that gets you started, freebit13.  If it's not obvious, you can use different values other than "50/50/0" for the quota -- anything like "25/25/50" works too.  And it doesn't even need to add up to 100%; I just do that because it's easier for my feeble brain to keep up with the math.  (Again, see the cgminer README file for explicit instructions on how this is supposed to be done -- but if you're anything like me, what you *really* needed was an example showing you a version that actually works...so here you go!)  Good luck and let me know if you run into problems; I cut and pasted most of the above, so I don't *think* there are any typos, but obviously you should back up your old config file just in case.  

Hope that helps!

I have had 100% success SSHing into the machine and issuing a shutdown command before I flip the power off.  I've been troubleshooting a malfunctioning blade and have had the power off and on 20 times or so at this point.  Zero problems.

Tbh I think this corrupt SD problem is probably more to do with some shoddy programming than anything else. I think there is something writing to the disk the whole time and if not stopped 'gracefully', it corrupts the card. I'm finding that if I eject the card before powering down, I don't have a problem with corruption. I haven't re-imaged a card in a week 

I was referring to the SD card being corrupted

At the risk of sounding like a complete noob... if you can change things like miner configuration and ip address, why not the password, wouldn't that just require an update to the luci interface with the appropriate commands?

The fix would require a new model of the controller card, because its due to the specific type of BB they used not having non volatile memory (...the SD).

Thank you, sir.  I appreciate it.

I don't think there is a fix for this... perhaps BITMAIN will release an updated firmware soon (hint, hint)... hopefully.

Yep, it's the furthest card.. the slot numbers are written on the power board.

The numbers don't always match the chain number in the gui if a card is missing though, i.e. if one card is missing from slot 4, the gui will show chain#1-9.

Can somebody tell me how to change the password of the S2?

When i try it i always get the message "invalid password".

Thank you, sir.  That will save me a few steps.  I'll verify it tomorrow and return with what I find out!