Topic: Custom Innosilicon A2 Terminator image - Anx Edition - page 6. (Read 22718 times)

Thanks for the information  where is the link to your sd card download for the cgminer i want try your version for the a2 terminator sounds like it works better then the other one i been using,,,,,                                                                                                                                                                    plus...... you have been more helpful so i want to use yours so if i have a problem i know where to get help.,,, thank you once again.                                                                                                                                                                i have one question why is it when i look at the mgh the first one on the page saying 96.mgh5s the second one saying 96.mgh average and then the pool one saying76mghs is this normal or is the program that im using

To be honest, I just cut power to them with Ethernet PDUs.
I have meanwhile 4 kinds of different IP-PDUs: Very old Aviosys 4- and 8-Port, an old Epower Switch, an ALIX Board with a USB Relay from Cleware and my latest one is the RT5350F-OLinuXino-EVB. The ALIX runs on voyage linux and the Olinuxino with OpenWRT. On both I have a cgi script running that exposes the same API as the Aviosys IP-Switch. All IP-PDUs are controlled from a script that constantly monitors coin price, difficulty, env. temperature in basement, current electricity price and based on this switches only on if my script thinks it can make profit...

I am not sure if this is good. Imagine people having a miner in a datacenter in a remote place and accidentally clicking shutdown. For me I can do the shutdown via ssh with public key auth. But you are right in that shutting down the thing properly would be the way to go. I think I will have to add that to my script so that it shuts the Pi's down a few seconds before switching off power.

Ok, will be my next post, but it might take some time to get it put together.

From my past experience there are a few ways to acomplish that:

• Use Debians packages and have your own repo, run apt-get -y upgrade from cron.
  This would be the most professional way and it could even run automatically. But building Debian packages for every single file you, Innosilicon and others have added to the base image would be huge task. And there are really simpler things in life than running a debian repo...
• Ship the image with 2x <4GB partitions, one is active and will be mounted as rootfs, the other on inactive.
  If the user wants to update, download a tar file and extract it to the inactive partition (or dd an image), once inactive partition is populated and was checked, switch uboot to boot from this partition, making the other one now the inactive one.
  This is a nice way, but it might be easy to f*ck up uboot configuration, leaving the user with a non-working miner and the urgent need to reflash. OTOH, you can offer in the GUI to switch back to the previous version by changing uboot configuration to point to the currently inactive partition, giving basically a way to go back to the old version. Naturally you could also copy over all config to the newly populated partition.
• Something I would call differential updates: Basically you make your current vanilla image the baseline image and work in a separate copy of the baseline image. Once you are ready to realease changes you run rsync in dry mode (meaning it doesn't sync but onyl report what it would do) and pipe the resulting filelist through tar. This will pack you all files that have changed compared to the baseline image. Naturally you would have to manually exclude files like the rrd's that may have been created in your tests etc..
  These updates can be then applied by just unpacking over the installation. A great disadvantage is that you have to take care yourself of restarting things etc or even stopping services before you are going to overwrite critical files. Basically you want to include a script with a defined name in the archive that does all that before and after the updates have applied (i.e. before: stop webservice, after: reboot).
  

Given that I think you will be only replacing very few files, the last option sounds like best. I have done this for a prototype of an embedded appliance that needed to autoupdate a few years ago.


Sounds all very promising. All update methods I described preserve (or let you preserve) configs.

Interesting - how do you shut it down?  I'm assuming something like a PDU?  I'm in the process of building a little daughter board to go into the Terminators (or really any ATX-based miner), that will be a WiFi remote rebooter and environmental sensor.  The lame PDU's I have only cut off one of the 240v legs, so sometimes the machines keep working, so I needed a better solution.

I actually powercycle mine as well - shut down from 3 to 6 PM every day because of the power plan I'm on, although they run 24-7 on weekends.

Would you like me to add a 'Shutdown' option from the web interface?  This way you could easily just script it to shutdown the box a minute before you power it down, and ensure nothing is in a funky state.


I'm sure that it would be appreciated - right now there's basically almost no real storage being used (beyond RRD), so it generally shouldn't be an issue.  I also save the CGMiner logs to the FS, but that's because I figured if you're using them, you're probably trying to debug something, and it might need to survive reboot.

One thing I would *LOVE* to be able to do, but don't know how I would yet (haven't looked into it yet), is allow people to do the firmware update from the web interface.  If you've got any insight into that, I'd love to hear it... I think that would be awesome, and would also make batch updating machines a much more pleasant experience.

The long term things I've love to add would be:

#1, Single config file for everything (probably xml), so you could backup and restore configs
#2, Reflashing through the web interface
#3, Persistent settings through updates (really requires the web interface to be viable).

Thank you for your feedback. The mentioned 88 has one blade that gives upto 3-5% errors when run at 1200MHz, when I change this one blade to 1000MHz, I feel like I get overall better results from this specific miner. Otherwise its a nice feature to check how a specific blade behaves at a specific speed but admittedly except the above 88 all my other miners run at the same speed on all their blades.


Great, having a stable and solid fs is important to me as my miners are getting switched on/off automatically. So there are days with 2-3 on/off transitions and having a lot of possible writes to the SD card ongoing makes me fear I am going to replace the first SD cards soon.
I would propose to have a picture with the images shipped which is just blank and has a text saying, "please wait a few minutes for statistics to be generated". This could be in place when the firmware first starts so you do not have broken links (i.e. if the graphs do not exist, copy the empty image there at boot).
For running I would propose to save the rrd databases regulary on the SD card somewhere, say every 1h. That is not perfect as it still gets the SD card some writes, but it reduces them a lot. If you i.e. tar.gz all rrd databases that should take minimal space and reduce writes even more. On boot, just check if the backup is existing and populate the tmpfs with the backup files.
I would even rotate those snapshots (having 2 of them, latest and latest+1) so that in case the switchoff happens when the tar.gz is built you have a working archive, so if unpacking the latest returns an error from tar, go for the latest+1.


Exactly, and a selection to work on group 1 or 2. I was quite happy with that feature to quickly change where and what I mine without loosing all the primary pools and worker-logins (it's not much of a deal but I found it very comfortable).


Nice, I'd be happy to offer a howto on growing or shrinking the images (i.e. growing the 4GB image to an 8GB card or to shrink the 4GB for a 2GB card).

You must be running Emdje's version, since mine has only been around for a bit over a month - his allows better over/underclocking, etc:

https://bitcointalksearch.org/topic/ultra-under-overclock-image-for-a2-innosilicon-by-emdje-v50-672969

I imagine his firmware is similar to the original InnoSilicon, and from my testing it looks like if the pool is down on the initial start, and it can't connect to any pool, then CGMiner exits (at least that was the behavior I was seeing).  So more a problem with CGMiner than his build I would guess. 

If it's the actual SD Card you're having problems with - then it's probably due to the fact the original one was really not setup well to run on a SD Card, so it can basically wreck the card at some point with all the writes it makes.  My version is better than the original by a fair bit, but there is still work to be done to make it better still.  The safe bet if you're having issues with the SD Card would be to buy another and just do a clean flash.

Hope that helps!

I can add to the TODO list to allow individual blade setting as well - I'll probably make it an option, so you can set them all the same, or choose them individually if you're so inclined.  Just for my own reference, how were you determining you should run a blade at a lower clock rate?  What happened at higher ones?

A good suggestion on cgmrrd, what I'll do on the next one is make that tmpfs, and then make sure that as part of the bootup process it regenerates things, so there aren't a bunch of broken links.  I don't mind the broken links as much on the first install, but would like it cleaner once up.

On the pool as the ping target, the reason I didn't do that was a couple of the pools I tested were blocking ICMP, so no ping responses - so I figured Google was the next best thing, since they work hard to be as fast as possible, and would probably represent your base case Internet latency.  It might be worth it to have a 3rd one which is primary or maybe even all pools (different line for different ones) - that way you could see at what level an outage occurs, etc.

What do you mean "secondary pool config switch"?  Do you mean two different sets of 3 pool?


Ah, that's legacy from the original InnoSilicon image I used - but I will look to resize it to 4GB, that way it will work fine for everyone, and be faster to flash.

Last night the internet went off a few times now a2 terminator every time i try to put the cg miner on wont run can the sd card have something missing in the files now i been running this programm for the last 10 month no problem
Overclock version 2.0 by Emdje    my son install it the first time can you put up your link so i can  install again on my sd card thank you and it a great program never had a problem before with it

Thank you for your continous great work, awesome firmware!

The temperature and hashrate graphs are an enormous help!
DHCP by default eases life a lot when setting them up or upgrading, the same goes for timezone setting.

A few questions and wishes though:

• With emdje's fw I was able to set the speed of each blade separately, this would be a nice option as my 88 wants to run one of six blades at a lower speed for best performance
• Are you considering to put the 2 cdmrrd directories on a tmpfs to have less write on the SD card (I like the graphs, but I fear they could wear out the SD card quite quickly)?
• How about taking the primary configured pool as ping target ?
• A secondary pool config to switch to would be nice but it's not that big deal

Also I noticed the image is 8GB in size, but the partitions inside account only for about 2.8GB. May I propose to either grow the fs to use the remaining space and/or create an image that also fits on 2GB/4GB cards. (Actually I use it with all 3 sizes of cards)

I would be happy to help with all of the above ideas/wishes, just let me know what I can contribute.

So something happened to my unit today... I'd been running at 1000Mhz for weeks no problem and decided to crank it up to 1100Mhz on the 31st... came home and unit was not on.

I flipped the power off and back on and the pi loads, but it won't start mining. I'm going to load the new software as maybe something just got corrupted, but if that doesn't work... I toasted something, didn't I?

Log file reads:
[2015-09-02 14:48:27] Failed to read num_cores from chip(cs2) 0 (check job)

and later

[2015-09-02 23:20:03] Failure(cs0)(24): missing ACK for cmd 0x1a                    
[2015-09-02 23:20:03] ACK(cs0) timeout:cmd_READ_REG-0.27955s                    
[2015-09-02 23:20:03] Failed to read reg from chip(cs0) 6                  


*Edit: Good news everyone. She's still mining. I had issues when I first got it running it at 1200 and 1100 (I know i need to replace power supply if I want to run it at those speeds)... I should have known it was going to turn off eventually.

Best firmware 4fr...  

I love timezone!

Suggestions:
First graphs show X X X instead of graph.

Historical view shows
"CgminerRRD (2013) Reported at: 2015-08-31_20:10:02"

Further:
3 pools is not a  lot. I would like unlimited pools with >= 1 fallback:
i.e.:
pool1 minerpool.org:8888
pool2 minerpool.org: 3332
pool3 minerpool.org: 3338
Fallback minerpool2.com: 8888
And then pool 1,2,3 in balance.

A download-button at syslog and messages would also be nice.


For all:
The best fw for A2.
KEEP UP THE GOOD WORK!!!

Downloaded, haven't had a chance to load yet.  Can't wait to get home!!

Nice upgrade!!! THX. 

I've some suggestions:
Change the tab-names to Pools or Stats in stead off all mines

I just uploaded the new version (09-01-2015) - yeah, I know it's a bit early, but I've got a business trip and will be gone all week, so wanted to get it up before I had to take off.  I've updated the first post to include the link and changes, functionally this is really just a bunch of bells and whistles - I added log viewing, changed some of the file system to be more SD card friendly, added and cleaned up the graphs, etc.  There's a couple of other minor cosmetic and functional changes, but the big ones are outlined on the post.

As always, if you run into any problems, suggestions or whatever, let me know!  Hope everyone enjoys the new version!

Good catch - it should be fixed in the next version I put up in a couple days...



Yeah, that case looks exactly like all my 88's, except I only have one black 88 - although I don't think I have any where the power distribution board attaches to the front like those pictures from Deep In The Mines has - bizarre.  It seems like each batch of miners from any of these manufacturers has wild variations in them, and with no clear purpose.  There's been at least 4 variations of the S5's in just the bunch that I have.

I spent a bunch of time with the fans and designing airflow stuff for my S5's:

https://bitcointalksearch.org/topic/antminer-s5-laser-cutter-mods-1086882

I tried the Kaze's that worked so well for me in the Terminators, but they didn't make much difference, so not with bothering with (on the 88's at least).  I'm more inclined to just completely redesign the case, but I think first I'm going to experiment with water cooling on my S5's - and then if that works well, maybe look into water cooling the Terminators.  Their current design does a decent enough job with airflow, that apart from getting Pi airflow, I'm not sure what could be gained.

Let me know how it works on your other machines, hopefully it should be without issue...

As promised, here is a picture of my 110 black, this is also the only one of my miners that allows me to set the chip voltage (me thinks it is from LKETC not Innosilicon). It is still my best horse in the barn:

It looks a lot (actually exactly) like this one: http://deepinthemines.com/index.php?route=product/product&path=61_66&product_id=47

These stronger Nidec 12V/1.6A fans are used in the black 110 and the silver 88:


The new silver 110 I received from Innosilicon have these slightly less powerful but less noisy Delta 12V/1.4A fans:


I have started to replace the 3 fans on the backside of the 5-fan terminators step-by-step with the stronger ones and I am quite happy with the results so far (basically: much more noise and some more hash  )

I will try your firmware on the new silver 110s and the silver 88s in the next days (the 88 has currently emdjes firmware running fine), I fear it won't fit on the black due to voltage setting.



Agreed, you are absolutely right. So few things to configure after reflashing that it's not worth considering pw recovery. (It is easy enough though  )

Is there any way you can allow for multiple arguments for the password field that can be used to manipulate the miner? For instance, at Prohashing you can set the name of your worker, difficulty and mined coin all by entering a string of variables that make up the password. Such a string would go as follows: n=worker_2 d=2048 c=litecoin (n=name d=difficulty c=mined coin)

Currently the software will truncate the "password" and just use the n=worker_2 value and omit the rest, but I would like the ability to use the full argument if possible without having the manually enter it via SSH/command line. Hope this makes sense.

Password recovery is always a tricky proposition - since everything is stored on the SD card, the easiest is to just reflash it.  Sure, you loose your settings, but it's not like there's that many to begin with, so shouldn't be that big a deal...


Once I get the new release done, I'll take a look into the new Pi2 stuff - I want it if for nothing other than my own units. 

No idea about the 'daisy chain mode'... Maybe it has something to do with the blades, although they aren't daisy chained, they each connect to a main I/O board that the Pi connects to.

I vote for the raspberry pi 2 upgrade.  I think that's a great idea.

the specs for the new 110 unit say, " Configurable in daisy chain mode for distributed work with up to 253 ASICs."

has anyone done this?  what is it exactly?

I for one would welcome such a feature, however you then probably would need to prepare a simple howto for resetting passwords once they are lost or forgotten (which inevitably will happen rather sooner than later).
When I received my first 110 Terminator (the 3-fan that shouldn't exist  ) I was pretty new to all this and the first thing I did was pulling the SD card out and resetting the root password to login via ssh - it was only later when I discovered that they all share that "pi/innosilicon" account.... (why do it easy if a hard way is available too?? ).

Yes, it's at the moment slightly cooler in the datacenter (~24°C) vs. basement with 25-26°C. Also the air entering the miner in datacenter is quite cooler as it is sucking in air directly from the ACs blower.

One difference I noted between the black and silver 110s is: The black has 3x NIDEC 1.6A fans, the silver has 5x DELTA 1.4A fans which are not as strong in terms of airflow.
Regarding temperature: I had no chance to compare them with a laser thermometer yet, but just from touching the backside where all the blades are mounted to I would say both, the black and the silver 110s are at around the same feeled temperature.  The 110s I have are all around the same temperature, the only "cool guy" here is the 88.

Once I receive my spare fans (next 2 days) I'll make some comparisons and pictures and post them. I am also considering to replace some of the DELTA fans with the stronger NIDEC fans to see if I can reduce temperature a bit more.