[Awesome Miner] - Powerful Windows GUI to manage and monitor up to 200000 miners

[bensam1231]

Alright, well I'm going to assume that the UI design and hierarchy of AM is just a bit off and that it's not based on a licensing strategy. I assume if this competes with the business model AM will never be improved, but as it currently stands AM is borderline unusable for GPU miners. For ASIC miners it's probably great as each 'instance' correlates' to one machine. Your income is not constricted by the use of the product.

AM is supposed to be a all inclusive miner management system. As it stands right now there are some flaws in how AM is designed, what it does, how it does it, and of course the UI itself. Some of what I'm suggesting here isn't new stuff, it's simply restructuring what's already done in the product. This is not meant to rub AM the wrong way, even if it seems this way.


-First off is how AM decides what a 'instance' is for licensing. For ASIC miners a instance, is simply the miner itself as the mining software is in and of itself the miner. With GPU miners, rigs are generally considered the 'miner' and mining software is quite numerous in the amounts and distributions. Often times experimental branches and miners that become outdated right away are used.

AM needs to organize GPU miners based on rigs for licensing. This in and of itself will keep me from using AM as licensing costs will balloon exponentially with the number of miners you use and the number of rigs you own. So if you mine Library, SIB, Ethereum, Decred, and Equihash and you have five rigs, you'll end up needing 25 'instance' license spots'. That takes a license which should cost $50 for five machines and puts it into the $100 range. It's multiplicative, the more rigs, the more this spirals out of control.

While you can 'adjust' each 'instance' in AM this is basically manual managements of miners and not what I'm paying for or what I assume other people are paying for. I would be willing to pay more per license as long as it allows unlimited miners per rig.

-Licensing aside, this means each 'instance' needs to be a rig. So when you add a new ASIC, FPGA, or RIG to AM it takes up a miner spot.

-Right now when you add a rig, each rig is tied to a coin and miner. This is not the way it should be. You should be able to add AM managed rigs straight into AM without assigning a miner or coin(algo). Conversely AM should periodically scan the network for new AM rigs and add them to a 'unassigned' list. This I will explain later on and while it seems like it's not a big change, it definitely is based on how rig management hierarchy works.

-Each rig should have GPU management stats sent directly to AM. This should not be tied into and/or depend on miner software. Right now GPU management in AM is more of a hack then a robust piece of software. AMD and Nvidia have built APIs for managing their GPUs. AM should be able to pull this directly, completely bypassing whatever miner is running. You should be able to see and have available to you everything those APIs do. This means GPU temps, utilization, memory usage, memory speed, gpu speed, TDP (especially TDP), and fan speed.

--Taking this a bit further. Through GPU management you should be able to adjust all of these things through AM. I will discuss this more later on, but you should be able to adjust clocks/memory clocks/tdp/voltage(AMD)/fan speed through AM. Everything MSI Afterburner is able to do, you should be able to do with AM.

Nvidia Inspector is a piece of software that does a lot of these things. While you can manage this with MSI Afterburner all of these attributes should be controlled by a all encompassing management software. I shouldn't need to touch my rigs outside of AM for mining purposes.

--AM should exist on the system level. This means I also need to see relevant system stats on a per rig basis without the miners running (GPU included). This includes CPU utilization, memory usage, pagefile usage, and free space on the hard drives. All of this can be pulled through Windows. There is CPU mining and different miners use different amounts of all of the above. All of those stats need to be seen on AM for GPU mining purposes. This is all stuff I monitor manually right now.


AM should have two distinct sections one for algos and one for rigs. It has this right now (coin section), but they aren't done correctly.

-Algos (neos/ethereum/equihas/etc) should have their own spot and this is what mining hierarchy is based off of.

-Each algos should start off with having a piece of mining software assigned to use with it. From the top most level the algorithm needs to be split up by AMD and Nvidia. Each of those use different pieces of mining software. From there each model need customizeable. So a AMD 480 can have a different piece of mining software then a AMD 380x. Vice versa. Nvidia 1070 compared to a 970 should be customizeable on a per gpu level.

This means there should be a generic piece of software assigned for mining say Library for AMD and one for Nvidia. Down a level you should be able to assign different software for each model. This also means you should be able to assign special mining parameters for each TYPE and MODEL. So special configurations can be made.

-Each algo also needs to have custom hardware parameters. This means you need to be able to adjust TDP/clocks(gpu and memory)/fan speed on a per coin, per type (AMD/Nvidia), per model (480/1070/etc) basis.

This is important as each algo, each miner will tolerate different overclocking parameters. Ideally this should be done automatically, but auto-overclocking is an entirely diffferent ballgame and you can speed a lot of time designing this. So just setting these parameters manually would be nice. TDP is very important as it pertains to efficiency and safety. Depending on how much power a person needs to use, these will be set to different things.

--Drilling down further this needs set on a PER GPU level as each GPU will tolerate different overclocking and TDPs. This once again is something a lot of miners currently do manually.

So the hierarchy for customization looks like this:

ALGO --> Miner per TYPE(AMD/Nvidia) --> Miner per Model (480/380/1070/970)

Each one of those parts needs to have the ability to edit GPU hardware parameters and a step further, which is per rig

ALGO --> Edit hardware per TYPE --> Edit hardware per model --> Edit hardware per rig GPUs

The hierarchy exists because sometimes you don't need to edit things past a different miner for AMD or Nvidia, other times you need to have a different miner for different models (and/or special parameters per model) and taking it a step further mining different algos (with or without different miners) requires you to use different TDPs/GPU clocks/GPU memory clocks/ETC.

So there is potential for leaving everything on 'general' settings or editing it all the way down to a GPU level.

Yes you can currently do this on certain miners and in AM. Depending on miners for this is a half ass solution for miner management. You need to be able to do this all the time and it shouldn't depend on buggy/glitchy/nonexistant miner implementations. AM shouldn't use miner APIs for anything other then miner stats and management. System level management should be done with other more robust tools already available to the OS (Nvidia API, Windows hardware pulling)

-Under each algo needs to have coins.

--Each coin needs to have pool(s) assigned to it. This means Library coin for instance can have any number of pools added to it with their address, worker name, password parameters. These should exist under the coin itself, just like with miners (and hardware under miners).

---AM needs to periodically check these pools and see whether or not they're functioning. AM also needs to manage pool failover, NOT done through the miner. This means if pool A goes down and the miner is getting timeouts, AM needs to KILL the miner and start it up on a pool B. Not all miners support failover and if they do, it doesn't always function properly.

Yes this is more work, yes it needs to be done for management software. I can setup failovers in a miner right now and do all of this with a batchfile. It's not impressive having AM do the same thing I do with a batchfile and still has all the problems I do with the batchfile.

-Right now you can only setup 'one' hashrate for each algorithm. Each algorithm needs to have separate hashrate setup on a PER TYPE, PER MODEL level. That means for each algorithm (and the coins that function under it) the user needs to be able to setup different hashrates for 380s/480/Fury/970s/1060s/1070s/ETC. A 380x for instance wont earn the same income with the same coin as a 1070. These varies completely based on what is profitable to mine for what.


Lets pull back a second and look at Miners currently. This is where everything ends up. The way the 'miners' tab is setup isn't done properly in the UI. Maybe 'Miners' isn't a good word for it, you can call it 'Mining Station' or whatever.

-What needs to be done in here is you have a area with unassigned rigs (which each take a license spot) and you have coins organized by algos. You can drag, shift move, or however you want those miners to under each coin and engage the hierarchy in the section I mentioned earlier. You should be able to click on each rig and look at system stats on it in addition to miner stats.

--The miner section could even be combined with the coin section in this manner where you have coins listed in a list and you can drag miners underneath the coin to start it up, showing actual/projected earnings compared to estimated earnings whattomine (whatever coin api) gives you.

---Taking this even further many big pools support API calls. This means you can get ACTUAL earnings from the pools themselves in addition to pool reported hashrate, efficiency, and pool projected income. So when you switch pools this all eventually becomes available to you in addition to what is being monitor through AM's stats.

This is all important and currently done manually. Good miners check all of these things to make sure they're all in line with each other. You can have a perfectly functional miner and bad gpus, bad pools, and of course the estimations for coins themselves done through coin calculators can be completely off. This is imperatively important to good miners and needs to be monitored.

-GPUs live in a mixed ecosystem. This means there can be a combination of 380x, 480, Fury, 970s, 1060s, and 1070s across multiple rigs. The coin section needs to reflect this. Being able to display earnings based on a per rig basis would be preferable. Possibly changing the 'earnings' for each coin when you pick up a rig to move it or showing the most profitable coin for a current rig. There are a few different ways to do this. But the static 'hash' system that is currently in place for each coin doesn't work for people that own more then one type of GPU (which is most GPU miners).

--Conversely, you could set it up so you can assign a GPU type to a coin and a algo. This would be a much more flexible system. That means every system with every GPU would be assigned to the algo, miners would automatically start across all systems and they would be put onto a coin with the appropriate algo, coin, system stats applied.

This is the ideal system and allows for much more flexibility, even allowing people to assign a certain number of GPUs per algo (not all of them), starting up the appropriate miners on all the machines, and then giving a global readout on the dashboard

-Each rig in the management pane needs to show the GPUs they currently have on board in addition to system stats mentioned earlier.

-All of the above can be compounded by mixed ecosystem rigs... Such as a rig that has a AMD 480 and a Nvidia 1070 in it. If a system is utilized that just pulls GPUs from a pool rather then per rig, that would make management of mixed rigs much easier. A GPU 'pool' system where it just shows all the GPUs across multiple rigs may be the ultimate solution here and allow the absolute most flexibility for rig owners to manage their system.

The advanced version of this would allow a 'GPU' page to be established which allows overall viewing of all GPUs across all the rigs, show their rig number (or name), other all around stats, algo they're mining, temps, utlization, fan speeds. Warnings could easily be setup to highly problematic rigs or temp issues.


-Going back to what was mentioned earlier, overclocking is not hard to do and it can be automated very easily. Most systems tolerate overclocking while mining. A globally operated system would allow for quite a bit of flexibility. A base 'safe' clock could be established (without OC), then AM could slowly ramp up clocks while mining and keeping track of historic 'working' clocks. Miners will usually 'soft' lock when a GPU is too high, the system will reset the GPU, the miner will spit out a error code (the first GPU error is the one that messed up) in the miner. AM could then reset the miner, restart the system if all the gpus aren't being detected properly, and then back off the clocks on the problematic GPU.

This is definitely doable, but of course takes more time and effort. Not something that is necessary out of the gate, but is something that would be a great addition. Each algo and each GPU all have different tolerable clocks and right now for most miners results in them simply not OCing or coming up with a 'safe' clock to utilize for most algos. This would be a selling point to bigger farms for getting more bang for their buck.


Yes once again all of this is a lot of work, but this is where it should end up.

Like I've mentioned earlier, a lot of what I've talked about is already existent in AM it's just unorganized or completely counter intuitive that makes managing through AM a completely PITA. I would pay a decent amount of money for good management software, but AM right now putting aside the messed up licensing doesn't do what I need it to, it only does bits and pieces which is really no different then me remotely executing batchfiles on my rigs.

[1714141666]

1714141666

[1714141666]

1714141666

[Noisyninja]

Is this software legit?

[mettalmag]

Is this software legit?

I just bought a licence and testing at first it seems pretty cool




At the farm itself I don't have any kind of host, how safe it will be to redirect ports and from home server use external IP address to access my miners? Or will it be better to bring there an old PC and install your software there?
Also the temps in status window aren't the hashing board temps, are there any possibilities to show the hashing board temps?

[toptek]

Is this software legit?

YES very Legit , regular updates are done so you won't be left in the Dark ..

[mettalmag]

devs willing to answer our questions ?
soft is good so far but no any kind of support!

[FlensGold]

soft is good so far but no any kind of support!

I totally disagree to this. Just read this thread and you can see that patrike tries to answer most questions.

[NotFuzzyWarm]

soft is good so far but no any kind of support!

I totally disagree to this. Just read this thread and you can see that patrike tries to answer most questions.

I agree 100% on the disagreeing ^^ The software works great and the dev actually responds to issues.

@ bensam1231, Please lose the text walls... They make the eyes go out of focus before even half-way through and certainly obscure the questions or points buried in there somewhere...

Yes the layout is quirky but nonetheless quite functional. Sorry if you have issues with how AM looks or functions but then again, if ya don't like it then move on to something else.

[patrike]

Anyone have ideas on why Awesome is displaying Avalons as I showed in https://bitcointalk.org/index.php?topic=676942.msg17968629#msg17968629 ?
More to the point I guess is, are the miners *really* hitting those blistering speeds even if only for a brief time? I've seen spikes as high as 60TH from the trio of 721's.

Since the real throughput as shown by the Avalon GUI and confirmed by CKpool stats is 18-20THs it would be nice if Awesome graphing could reflect that...

Is the numbers you see in the main window of Awesome Miner also jumping like that? So there is a variation on the 5s hash rate value if you look at it for a couple of minutes?

[patrike]

Alright, well I'm going to assume that the UI design and hierarchy of AM is just a bit off and that it's not based on a licensing strategy. I assume if this competes with the business model AM will never be improved, but as it currently stands AM is borderline unusable for GPU miners. For ASIC miners it's probably great as each 'instance' correlates' to one machine. Your income is not constricted by the use of the product.

AM is supposed to be a all inclusive miner management system. As it stands right now there are some flaws in how AM is designed, what it does, how it does it, and of course the UI itself. Some of what I'm suggesting here isn't new stuff, it's simply restructuring what's already done in the product. This is not meant to rub AM the wrong way, even if it seems this way.

...

First of all, thank you for providing all these comments. There are for sure some good point being made, but some of the requests will require significant development.

Although I think Awesome Miner is the best option for miner management already (I don't know any other tools with the same amount of features and support for management of very large number of miners), any product can of course get better. I do take note of almost every feature request I get, and I typically implement the features based on what the demand looks like. However, the world of mining is changing all the time with new software and concepts, so I would never claim that Awesome Miner can solve all use cases for all users across all kind of mining setups. I do however promise to continue to make the product better.

I do have some concepts in mind for the future releases that will address parts of what you are reporting.

[patrike]

Is this software legit?

As several users responsed already - yes! Please let me know if you have any further questions.

[patrike]

devs willing to answer our questions ?
soft is good so far but no any kind of support!

I did just notice that you sent me a private message two days ago that I didn't respond to. I will get back to you with an answer on this.
I try to answer questions as soon as possible, but sometimes there can be many questions from users, especially now when the Bitcoin price is high and more people are getting interested in mining.

[mettalmag]

devs willing to answer our questions ?
soft is good so far but no any kind of support!

I did just notice that you sent me a private message two days ago that I didn't respond to. I will get back to you with an answer on this.
I try to answer questions as soon as possible, but sometimes there can be many questions from users, especially now when the Bitcoin price is high and more people are getting interested in mining.

Thanks for reply, can't wait to have answers on those questions as well, I already bought premium edition and want to upgrade in nearest future.

[patrike]

At the farm itself I don't have any kind of host, how safe it will be to redirect ports and from home server use external IP address to access my miners? Or will it be better to bring there an old PC and install your software there?
Also the temps in status window aren't the hashing board temps, are there any possibilities to show the hashing board temps?

Although it's possible to setup port forwarding (redirects), it's also a security risk. At least if you enable full API access on the miners, that would allow for changing pool and more. It's more secure to setup some kind of VPN solution. I don't know what your router supports, but an option is always to have a PC on the site running VPN software like Hamachi LogMeIn, and then have Awesome Miner running at your location. As you point out, you can also run Awesome Miner directly on this PC on the site and connect via Remote Desktop, or use the Awesome Miner built-in web interface to monitor from your location.

I'm assuming it's Antminers for the moment, because you ask about hashing board temperaturs. Please correct me if I'm wrong. You can actually configure the Progress field in the Miner tab to display Antminer chip temperature. See the last example on this page: http://www.awesomeminer.com/help/customizefield.aspx

[mettalmag]

At the farm itself I don't have any kind of host, how safe it will be to redirect ports and from home server use external IP address to access my miners? Or will it be better to bring there an old PC and install your software there?
Also the temps in status window aren't the hashing board temps, are there any possibilities to show the hashing board temps?

Although it's possible to setup port forwarding (redirects), it's also a security risk. At least if you enable full API access on the miners, that would allow for changing pool and more. It's more secure to setup some kind of VPN solution. I don't know what your router supports, but an option is always to have a PC on the site running VPN software like Hamachi LogMeIn, and then have Awesome Miner running at your location. As you point out, you can also run Awesome Miner directly on this PC on the site and connect via Remote Desktop, or use the Awesome Miner built-in web interface to monitor from your location.

I'm assuming it's Antminers for the moment, because you ask about hashing board temperaturs. Please correct me if I'm wrong. You can actually configure the Progress field in the Miner tab to display Antminer chip temperature. See the last example on this page: http://www.awesomeminer.com/help/customizefield.aspx
[/quote]
you are right, they are all S9s, so far my future solution is to bring at the farm my old pc with awesome miner installed on it, disable full api access to miners and use mailing and web interface for monitoring. I have mikrotik there with vpn access but I prefer to have a pc there. That will give me maximum security, I won't even forward RDP just connect to vpn and use RDP that way. One more question, will I be able to set for web monitoring multiple users and passwords if I upgrade my awesomeminer of course?

[NotFuzzyWarm]

Anyone have ideas on why Awesome is displaying Avalons as I showed in https://bitcointalk.org/index.php?topic=676942.msg17968629#msg17968629 ?
More to the point I guess is, are the miners *really* hitting those blistering speeds even if only for a brief time? I've seen spikes as high as 60TH from the trio of 721's.

Since the real throughput as shown by the Avalon GUI and confirmed by CKpool stats is 18-20THs it would be nice if Awesome graphing could reflect that...

Is the numbers you see in the main window of Awesome Miner also jumping like that? So there is a variation on the 5s hash rate value if you look at it for a couple of minutes?

Ja. They jump BIG time. I've seen the 5sec avg go as low as 6THs or so and on the next refresh it's over 27THs and higher...

What Canaan's GUI shows of course bangs a round a couple THs but nowhere near what the raw readouts must be...


Any way to filter it? I've played with Awesome's refresh time going from default 5-sec to 1 min, no change.
Avalon 3x 721 ApiReport:

Code:

Version: 2.2.4
API command: config
{
  "STATUS": [
    {
      "STATUS": "S",
      "When": 1471333798,
      "Code": 33,
      "Msg": "CGMiner config",
      "Description": "cgminer 4.9.2"
    }
  ],
  "CONFIG": [
    {
      "ASC Count": 1,
      "PGA Count": 0,
      "Pool Count": 3,
      "Strategy": "Failover",
      "Log Interval": 5,
      "Device Code": "",
      "OS": "Linux",
      "Hotplug": 5
    }
  ],
  "id": 1
}
API command: summary
{
  "STATUS": [
    {
      "STATUS": "S",
      "When": 1471333798,
      "Code": 11,
      "Msg": "Summary",
      "Description": "cgminer 4.9.2"
    }
  ],
  "SUMMARY": [
    {
      "Elapsed": 342566,
      "MHS av": 19037365.27,
      "MHS 5s": 25046869.41,
      "MHS 1m": 22602272.17,
      "MHS 5m": 19950434.44,
      "MHS 15m": 19364680.34,
      "Found Blocks": 0,
      "Getworks": 11696,
      "Accepted": 98315,
      "Rejected": 826,
      "Hardware Errors": 12982,
      "Utility": 17.22,
      "Discarded": 183510,
      "Stale": 49,
      "Get Failures": 3,
      "Local Work": 72212184,
      "Remote Failures": 2,
      "Network Blocks": 651,
      "Total MH": 6521558360304.0,
      "Work Utility": 268840.08,
      "Difficulty Accepted": 1518418645.0,
      "Difficulty Rejected": 12795509.0,
      "Difficulty Stale": 315569.0,
      "Best Share": 5930165311,
      "Device Hardware%": 0.0008,
      "Device Rejected%": 0.8336,
      "Pool Rejected%": 0.8355,
      "Pool Stale%": 0.0206,
      "Last getwork": 1471333798
    }
  ],
  "id": 1
}
API command: privileged
{
  "STATUS": [
    {
      "STATUS": "S",
      "When": 1471333798,
      "Code": 46,
      "Msg": "Privileged access OK",
      "Description": "cgminer 4.9.2"
    }
  ],
  "id": 1
}
API command: devs
{
  "STATUS": [
    {
      "STATUS": "S",
      "When": 1471333798,
      "Code": 9,
      "Msg": "1 ASC(s)",
      "Description": "cgminer 4.9.2"
    }
  ],
  "DEVS": [
    {
      "ASC": 0,
      "Name": "AV7",
      "ID": 0,
      "Enabled": "Y",
      "Status": "Alive",
      "Temperature": 36.58,
      "MHS av": 19037928.29,
      "MHS 5s": 25046869.41,
      "MHS 1m": 22602272.17,
      "MHS 5m": 19950434.44,
      "MHS 15m": 19364680.34,
      "Accepted": 98315,
      "Rejected": 826,
      "Hardware Errors": 12982,
      "Utility": 17.22,
      "Last Share Pool": 0,
      "Last Share Time": 1471333797,
      "Total MH": 6521558360304.0,
      "Diff1 Work": 1534925500,
      "Difficulty Accepted": 1518418645.0,
      "Difficulty Rejected": 12795509.0,
      "Last Share Difficulty": 14804.0,
      "No Device": false,
      "Last Valid Work": 1471333798,
      "Device Hardware%": 0.0008,
      "Device Rejected%": 0.8336,
      "Device Elapsed": 342556
    }
  ],
  "id": 1
}
API command: pools
{
  "STATUS": [
    {
      "STATUS": "S",
      "When": 1471333798,
      "Code": 7,
      "Msg": "3 Pool(s)",
      "Description": "cgminer 4.9.2"
    }
  ],
  "POOLS": [
    {
      "POOL": 0,
      "URL": "stratum+tcp://stratum.kano.is:3333",
      "Status": "Alive",
      "Priority": 0,
      "Quota": 1,
      "Long Poll": "N",
      "Getworks": 11694,
      "Accepted": 98315,
      "Rejected": 826,
      "Works": 3080713,
      "Discarded": 183510,
      "Stale": 49,
      "Get Failures": 3,
      "Remote Failures": 2,
      "User": "Fuzzy.Avalon721_1",
      "Last Share Time": 1471333797,
      "Diff1 Shares": 1534925500,
      "Proxy Type": "",
      "Proxy": "",
      "Difficulty Accepted": 1518418645.0,
      "Difficulty Rejected": 12795509.0,
      "Difficulty Stale": 315569.0,
      "Last Share Difficulty": 14804.0,
      "Work Difficulty": 14804.0,
      "Has Stratum": true,
      "Stratum Active": true,
      "Stratum URL": "stratum.kano.is",
      "Stratum Difficulty": 14804.0,
      "Has GBT": false,
      "Best Share": 5930165311,
      "Pool Rejected%": 0.8355,
      "Pool Stale%": 0.0206,
      "Bad Work": 0,
      "Current Block Height": 455006,
      "Current Block Version": 536870912
    },
    {
      "POOL": 1,
      "URL": "stratum+tcp://stratum80.kano.is:80",
      "Status": "Alive",
      "Priority": 1,
      "Quota": 1,
      "Long Poll": "N",
      "Getworks": 1,
      "Accepted": 0,
      "Rejected": 0,
      "Works": 0,
      "Discarded": 0,
      "Stale": 0,
      "Get Failures": 0,
      "Remote Failures": 0,
      "User": "Fuzzy.Avalon721_1",
      "Last Share Time": 0,
      "Diff1 Shares": 0,
      "Proxy Type": "",
      "Proxy": "",
      "Difficulty Accepted": 0.0,
      "Difficulty Rejected": 0.0,
      "Difficulty Stale": 0.0,
      "Last Share Difficulty": 0.0,
      "Work Difficulty": 0.0,
      "Has Stratum": true,
      "Stratum Active": false,
      "Stratum URL": "",
      "Stratum Difficulty": 0.0,
      "Has GBT": false,
      "Best Share": 0,
      "Pool Rejected%": 0.0,
      "Pool Stale%": 0.0,
      "Bad Work": 0,
      "Current Block Height": 0,
      "Current Block Version": 536870912
    },
    {
      "POOL": 2,
      "URL": "stratum+tcp://stratum81.kano.is:81",
      "Status": "Alive",
      "Priority": 2,
      "Quota": 1,
      "Long Poll": "N",
      "Getworks": 1,
      "Accepted": 0,
      "Rejected": 0,
      "Works": 0,
      "Discarded": 0,
      "Stale": 0,
      "Get Failures": 0,
      "Remote Failures": 0,
      "User": "Fuzzy.Avalon721_1",
      "Last Share Time": 0,
      "Diff1 Shares": 0,
      "Proxy Type": "",
      "Proxy": "",
      "Difficulty Accepted": 0.0,
      "Difficulty Rejected": 0.0,
      "Difficulty Stale": 0.0,
      "Last Share Difficulty": 0.0,
      "Work Difficulty": 0.0,
      "Has Stratum": true,
      "Stratum Active": false,
      "Stratum URL": "",
      "Stratum Difficulty": 0.0,
      "Has GBT": false,
      "Best Share": 0,
      "Pool Rejected%": 0.0,
      "Pool Stale%": 0.0,
      "Bad Work": 0,
      "Current Block Height": 0,
      "Current Block Version": 536870912
    }
  ],
  "id": 1
}
API command: coin
{
  "STATUS": [
    {
      "STATUS": "S",
      "When": 1471333798,
      "Code": 78,
      "Msg": "CGMiner coin",
      "Description": "cgminer 4.9.2"
    }
  ],
  "COIN": [
    {
      "Hash Method": "sha256",
      "Current Block Time": 1471332690.861985,
      "Current Block Hash": "00000000000000000217e2b5ac45ebc7ed3925dd27fc7bda491bdc7fe70375dd",
      "LP": true,
      "Network Difficulty": 440779902286.58917
    }
  ],
  "id": 1
}
API command: notify
{
  "STATUS": [
    {
      "STATUS": "S",
      "When": 1471333798,
      "Code": 60,
      "Msg": "Notify",
      "Description": "cgminer 4.9.2"
    }
  ],
  "NOTIFY": [
    {
      "NOTIFY": 0,
      "Name": "AV7",
      "ID": 0,
      "Last Well": 1471333798,
      "Last Not Well": 0,
      "Reason Not Well": "None",
      "*Thread Fail Init": 0,
      "*Thread Zero Hash": 0,
      "*Thread Fail Queue": 0,
      "*Dev Sick Idle 60s": 0,
      "*Dev Dead Idle 600s": 0,
      "*Dev Nostart": 0,
      "*Dev Over Heat": 0,
      "*Dev Thermal Cutoff": 0,
      "*Dev Comms Error": 0,
      "*Dev Throttle": 0
    }
  ],
  "id": 1
}
API command: stats
{
  "STATUS": [
    {
      "STATUS": "S",
      "When": 1471333798,
      "Code": 70,
      "Msg": "CGMiner stats",
      "Description": "cgminer 4.9.2"
    }
  ],
  "STATS": [
    {
      "STATS": 0,
      "ID": "AV70",
      "Elapsed": 342566,
      "Calls": 0,
      "Wait": 0.0,
      "Max": 0.0,
      "Min": 99999999.0,
      "MM ID1": "Ver[7111610-810cba0] DNA[01315f1f02f6936a] Elapsed[342568] MW[3182071 3182076 3182040 3182040] LW[12728227] MH[556 1253 1327 1329] HW[4465] DH[2.033%] Temp[34] TMax[94] Fan[5010] FanR[64%] Vi[1211 1211 1205 1205] Vo[4475 4481 4486 4496] GHSmm[6786.14] WU[91843.17] Freq[736.34] PG[15] Led[0] MW0[14544 14253 14713 14666 13935 14189 14462 14163 14241 13503 14025 14333 14031 14616 14283 14571 15399 15040] MW1[14332 14814 14484 14347 14344 13890 13723 14267 14271 14470 13848 13876 14502 15113 14869 14704 14716 14766] MW2[15088 15442 15086 14934 15070 15176 13919 14504 14667 14167 14534 14563 14356 15005 14952 14750 15192 15403] MW3[14762 14544 14406 14594 14340 13787 14146 13907 14331 14999 14751 14793 14870 14855 14832 15514 15172 15036] TA[72] ECHU[0 0 0 0] ECMM[0] FM[3] CRC[0 0 0 0] PVT_T[17-77/0-93/80 17-79/0-94/88 0-78/7-92/83 17-78/0-92/86]",
      "MM ID2": "Ver[7111610-810cba0] DNA[0135f5ef1339ee6d] Elapsed[342567] MW[3182076 3182076 3182053 3182058] LW[12728263] MH[533 1266 1221 1316] HW[4336] DH[2.481%] Temp[35] TMax[93] Fan[4920] FanR[60%] Vi[1206 1206 1210 1204] Vo[4439 4449 4475 4465] GHSmm[6715.12] WU[89244.79] Freq[728.64] PG[15] Led[0] MW0[13954 13045 13377 12940 12851 12827 13034 13216 13105 12887 13543 13146 13246 13041 13204 13496 13172 13718] MW1[14785 15117 14241 14791 14211 14202 14074 13445 13368 14005 13859 14388 13800 13936 14133 14727 14399 14708] MW2[14730 14904 14613 14520 14571 14569 14368 13580 13695 13781 14033 14292 14389 14279 14498 14342 14706 14919] MW3[15537 15352 15226 14838 14987 14929 14696 14785 14957 13874 14748 14936 14270 14452 13973 14660 14685 15393] TA[72] ECHU[0 0 0 0] ECMM[0] FM[3] CRC[0 0 0 0] PVT_T[0-78/8-89/80 0-79/0-92/87 0-77/6-90/87 17-81/0-93/81]",
      "MM ID3": "Ver[7111610-810cba0] DNA[013dd53ac97e55b5] Elapsed[342567] MW[3182076 3182076 3182058 3182058] LW[12728268] MH[574 1281 1204 1122] HW[4181] DH[2.755%] Temp[35] TMax[92] Fan[4530] FanR[56%] Vi[1201 1198 1222 1212] Vo[4449 4439 4507 4543] GHSmm[6570.36] WU[87751.32] Freq[712.93] PG[15] Led[0] MW0[14750 13844 13914 14576 13955 13333 13087 12931 14001 14300 14191 14401 13974 14374 14247 14642 14762 14373] MW1[14300 14139 14082 13996 13532 13795 13311 13570 13568 13977 13152 13566 13841 13951 13943 14361 14405 14320] MW2[14703 14697 14281 14035 13994 14039 13778 14566 13577 13943 13781 13726 13630 13929 14173 14867 14736 14946] MW3[13920 13103 13413 12831 12987 13202 13378 13487 13413 13907 13651 13247 13228 13754 13636 13852 13948 14201] TA[72] ECHU[512 0 0 0] ECMM[0] FM[3] CRC[0 0 0 0] PVT_T[17-80/0-91/87 17-75/0-90/85 0-78/8-92/83 0-74/8-86/79]",
      "MM Count": 3,
      "Smart Speed": 1,
      "Connecter": "AUC",
      "AUC VER": "AUC-20151208",
      "AUC I2C Speed": 400000,
      "AUC I2C XDelay": 19200,
      "AUC Sensor": 12935,
      "AUC Temperature": 36.58,
      "Connection Overloaded": false,
      "USB Pipe": "0",
      "USB Delay": "r0 0.000000 w0 0.000000",
      "USB tmo": "0 0"
    },
    {
      "STATS": 1,
      "ID": "POOL0",
      "Elapsed": 342566,
      "Calls": 0,
      "Wait": 0.0,
      "Max": 0.0,
      "Min": 99999999.0,
      "Pool Calls": 0,
      "Pool Attempts": 0,
      "Pool Wait": 0.0,
      "Pool Max": 0.0,
      "Pool Min": 99999999.0,
      "Pool Av": 0.0,
      "Work Had Roll Time": false,
      "Work Can Roll": false,
      "Work Had Expire": false,
      "Work Roll Time": 0,
      "Work Diff": 14804.0,
      "Min Diff": 2052.0,
      "Max Diff": 16595.0,
      "Min Diff Count": 1784,
      "Max Diff Count": 831,
      "Times Sent": 99170,
      "Bytes Sent": 13673887,
      "Times Recv": 110863,
      "Bytes Recv": 18374938,
      "Net Bytes Sent": 13673887,
      "Net Bytes Recv": 18374938
    },
    {
      "STATS": 2,
      "ID": "POOL1",
      "Elapsed": 342566,
      "Calls": 0,
      "Wait": 0.0,
      "Max": 0.0,
      "Min": 99999999.0,
      "Pool Calls": 0,
      "Pool Attempts": 0,
      "Pool Wait": 0.0,
      "Pool Max": 0.0,
      "Pool Min": 99999999.0,
      "Pool Av": 0.0,
      "Work Had Roll Time": false,
      "Work Can Roll": false,
      "Work Had Expire": false,
      "Work Roll Time": 0,
      "Work Diff": 0.0,
      "Min Diff": 0.0,
      "Max Diff": 0.0,
      "Min Diff Count": 0,
      "Max Diff Count": 0,
      "Times Sent": 2,
      "Bytes Sent": 152,
      "Times Recv": 5,
      "Bytes Recv": 1487,
      "Net Bytes Sent": 152,
      "Net Bytes Recv": 1487
    },
    {
      "STATS": 3,
      "ID": "POOL2",
      "Elapsed": 342566,
      "Calls": 0,
      "Wait": 0.0,
      "Max": 0.0,
      "Min": 99999999.0,
      "Pool Calls": 0,
      "Pool Attempts": 0,
      "Pool Wait": 0.0,
      "Pool Max": 0.0,
      "Pool Min": 99999999.0,
      "Pool Av": 0.0,
      "Work Had Roll Time": false,
      "Work Can Roll": false,
      "Work Had Expire": false,
      "Work Roll Time": 0,
      "Work Diff": 0.0,
      "Min Diff": 0.0,
      "Max Diff": 0.0,
      "Min Diff Count": 0,
      "Max Diff Count": 0,
      "Times Sent": 2,
      "Bytes Sent": 152,
      "Times Recv": 5,
      "Bytes Recv": 1487,
      "Net Bytes Sent": 152,
      "Net Bytes Recv": 1487
    }
  ],
  "id": 1
}

[bensam1231]

Alright, well I'm going to assume that the UI design and hierarchy of AM is just a bit off and that it's not based on a licensing strategy. I assume if this competes with the business model AM will never be improved, but as it currently stands AM is borderline unusable for GPU miners. For ASIC miners it's probably great as each 'instance' correlates' to one machine. Your income is not constricted by the use of the product.

AM is supposed to be a all inclusive miner management system. As it stands right now there are some flaws in how AM is designed, what it does, how it does it, and of course the UI itself. Some of what I'm suggesting here isn't new stuff, it's simply restructuring what's already done in the product. This is not meant to rub AM the wrong way, even if it seems this way.

...

First of all, thank you for providing all these comments. There are for sure some good point being made, but some of the requests will require significant development.

Although I think Awesome Miner is the best option for miner management already (I don't know any other tools with the same amount of features and support for management of very large number of miners), any product can of course get better. I do take note of almost every feature request I get, and I typically implement the features based on what the demand looks like. However, the world of mining is changing all the time with new software and concepts, so I would never claim that Awesome Miner can solve all use cases for all users across all kind of mining setups. I do however promise to continue to make the product better.

I do have some concepts in mind for the future releases that will address parts of what you are reporting.

Yes, I fully understand this will take a lot of time and effort. I know rome wasn't built over night, however that is what it should look like when it's a mature product. AM in it's current form at the most basic level licensing doesn't work for me (and I'm sure other larger miners). Even with none of the other changes it requires too many licensing instances per rig.

Although no longer supported, Multiminer does the same thing and is free: https://bitcointalk.org/index.php?topic=248173.0

There is a lot of potential for management software here, AM is pretty far from that. I can monitor my hashrate poolside, I can change algos with 'live' directories (I drop batchfiles in on the miners, using a batchfile to copy these all across multiple systems). I can also deploy new miners across rigs with batchfiles. Im looking for software that does more then what I can already do, which is why I took all that time to type that out. It'll definitely take a lot of time, it's something I'm willing to pay for though and other are as well.

[mettalmag]

I'm assuming it's Antminers for the moment, because you ask about hashing board temperaturs. Please correct me if I'm wrong. You can actually configure the Progress field in the Miner tab to display Antminer chip temperature. See the last example on this page: http://www.awesomeminer.com/help/customizefield.aspx

And forgot to mention, it did the trick, now I see chip temps in progress bar, thank you.








This is the last place I can ask, after googling for couple hours..
I want to give web monitoring access to some users, for this I will have to forward port to my micrserver which is sitting in the same LAN as S9-s.
As I see there are some options you can change via web monitoring.
Is there any way to restrict these and make it read only mode ? Update: I figured it out, now when I access web interface from global it only shows the stats and it's impossible to change anything, I think now it is more secure.
And is it possible to add multiple emails in receiver address ?
Are there any error definitions ? I can't figure out what Accept progress means (

[NotFuzzyWarm]

Continuing thoughts into what Avalon's display https://bitcointalk.org/index.php?topic=676942.msg17968629#msg17968629 and followup https://bitcointalk.org/index.php?topic=676942.msg18027671#msg18027671 as massively spikey 5-sec hash rates, wonder it is from how/when the 1 controller is talking to the 3x 721's chained off of the 1 USB/I2C adapter coupled with how Canaan's (legal) fork of CGminer reads that? Looking at what Canaan's GUI displays they must be smoothing out a lot of samples...

Perhaps for several sec or more there is nothing to report to AM followed by a massive data burst as the miners in unison report findings/request more work? I can easily see that the light on the adapter only flashes with a burst of activity for a couple sec maybe 5x a minute.

[patrike]

I want to give web monitoring access to some users, for this I will have to forward port to my micrserver which is sitting in the same LAN as S9-s.
As I see there are some options you can change via web monitoring.
Is there any way to restrict these and make it read only mode ? Update: I figured it out, now when I access web interface from global it only shows the stats and it's impossible to change anything, I think now it is more secure.
And is it possible to add multiple emails in receiver address ?
Are there any error definitions ? I can't figure out what Accept progress means (

With the Enterprise Edition there is actually a feature when you can define multiple users accounts, and they will all have different login credentials to the web interface. It's also possible to define per user account which miners they should be allowed to see and what they are allowed to do (control the mining or only view the statistics).
See: http://awesomeminer.com/help/security.aspx

Accept progress is basically that the statistics that show as "Accepted" (in contrast to Rejected shares) will increase over time. You can compare to ensure that in a 5 minute interval, the Accept value should increase.

Update: For multiple e-mail receivers, you simply separate them with either a comma or semi-colon.

[patrike]

Continuing thoughts into what Avalon's display https://bitcointalk.org/index.php?topic=676942.msg17968629#msg17968629 and followup https://bitcointalk.org/index.php?topic=676942.msg18027671#msg18027671 as massively spikey 5-sec hash rates, wonder it is from how/when the 1 controller is talking to the 3x 721's chained off of the 1 USB/I2C adapter coupled with how Canaan's (legal) fork of CGminer reads that? Looking at what Canaan's GUI displays they must be smoothing out a lot of samples...

Perhaps for several sec or more there is nothing to report to AM followed by a massive data burst as the miners in unison report findings/request more work? I can easily see that the light on the adapter only flashes with a burst of activity for a couple sec maybe 5x a minute.

Thanks for all info on the Avalon hashrate you have provided. Based on your previous posts, it looks like the 5s hashrate is reported with a large variation. Awesome Miner is currently not smoothing any values - everything is displayed exactly as reported by the miner API's.

It would probably be possible to add some smoothing to the graphs in Awesome Miner, but the question is really if you want to see a pretty graph or a graph showing what's actually reported.