Custom Innosilicon A2 Terminator image - Anx Edition

[psycodad]

As I'm starting to lock down this next release, one thing I was considering adding was the ability to change the Pi account password from "innosilicon" to whatever you wanted... The security is basically non-existent on any of these miners anyway, so I don't know if this is that important to anyone, but if it were then I would add it, and the ability to require authentication on the web interface as well - to at least give you the ability to lock things up just a tad if you were so inclined. 

I haven't looked into it in any great detail - I thought I would see first if people had an immediate desire for this option - otherwise I'll just punt it until a later version.

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?? ).

[1714767554]

1714767554

[1714767554]

1714767554

[1714767554]

1714767554

[1714767554]

1714767554

[1714767554]

1714767554

[wmtomlinso]

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?

[MarkAz]

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?? ).

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...

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?

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.

[thesmokingman]

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.

[psycodad]

I have a black 110Mhs with 3 fans and a silver 88Mhs with 3 fans, my last buy from Innosilicon are 110Mhs and silver with 5 fans. However the miners with 3 fans have NIDEC 1.6A fans, the miners with 5 fans have 1.4A DELTA fans.

Well, there you have it - there is officially no consistency with A2's!    I have 15 110's and 13 88's, black cases (all my black ones are 88's), silver cases, short cases, long cases - the only thing that was consistent between them was the 3 fan/5 fan thing, so I assumed that was the easiest indicator, so back to the drawing board as far as figuring out which is which.  The last two I bought from Zoomhash were silver 110's with 5 fans.

Personally, I'm surprised the 110's would run with 3 fans, my 88's run considerably cooler than the 110's, and the 110's run hot with 5 fans, I couldn't imagine running them on 3.  What are the temps like on your black one?

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.

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?? ).

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...

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  )

[MarkAz]

Is there any way you can allow for multiple arguments for the password field that can be used to manipulate the miner?

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

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:

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://bitcointalk.org/index.php?topic=1086882.0

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...

[MarkAz]

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!

[wieme]

Nice upgrade!!! THX. 

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

[madmartyk]

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

[wieme]

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!!!

[CoinLeaf]

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.

[psycodad]

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.

[hashmaster1]

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

[MarkAz]

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

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?

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.

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.

[MarkAz]

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

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://bitcointalk.org/index.php?topic=672969.0

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!

[psycodad]

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

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?

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.

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.

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.

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?

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).

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.

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.

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).

[MarkAz]

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.

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.

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).

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).

[psycodad]

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.

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.

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...

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 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.

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).

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.

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

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.

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.

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).

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

[hashmaster1]

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

[MarkAz]

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

The link is at the very first post in this thread, you can get the current version as well as older version - when I release a new one, I update that first post so you only have to look one place to get it.

I will say that Emdje's firmware has more flexibility in terms of what you can do with the device - mine has more of the convenience things, that make it a bit easier to manage a bunch of them.  Either way the experience is much nicer than the stock one. 

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

There usually is a difference between what you see locally and what the pool sees - and of course what the pool sees is all that really matters.  The difference typically comes from discards and rejects, which knock your rate down on the pool side, so you'll probably want to look into that first.  The speed you're getting is pretty strange, 96MH would be low for a 110, and high for an 88... If I had to guess, and it would be a big guess, it's that you're running a heavily overclocked 88 - the higher you overclock, the more hardware errors (and in turn rejects) you get, so you can crank up you apparent to higher speed, but your actual speed is lower than normal.  You might try dropping down to 88 and see what happens - if your pool rate increases to be much closer, then that's what's happening.  Overclocking is tricky, it's all a balance of managing heat/power/errors...