Topic: [Awesome Miner] - Powerful Windows GUI to manage and monitor up to 200000 miners - page 611. (Read 703367 times)

Is this software legit?

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.

Anyone have ideas on why Awesome is displaying Avalons as I showed in https://bitcointalksearch.org/topic/m.17968629 ?
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...

i will test it soon. I'll tell you the results. Thanks!

I figured out the majority of the problems I described, however the above still remains.

It hasn't always been SGminer. There are plenty of other releases you have to setup in order mine specific coins with the fastest available miner. SGminer or CCminer (the version in AM is severely outdated) aren't the only distributions. For a lot of the coins in the coin list there are specific branches you need to use, such as Pascal, Library, Decred, Sib, and of course Ethereum as you've already mentioned.

So for three rigs (I have a lot more then that) I would need 15 'instances' or license spots. Those are just the easy ones off the top of my head. There are a lot of custom mining solutions I have to dump into AM to get things working as well. My mining folder has tons of distributions in it which have akrewed over the years, most of which aren't used anymore, but just a testament to the amount of custom miners that are needed to optimize profits. If all someone is using is SGminer or CCminer, they aren't going to be mining for long.

'Instances' should be defined as a single rig, not mining software inside the rig. It doesn't make sense unless you're trying to inflate license costs. Even if you could switch between instances in those miners, you wouldn't want to do that over just simply killing the instance and restarting the appropriate miner. AM is supposed to be mining management software, not something I can do with a batfile or minercontrol. Why even bother with algo switching inside of the miner? That's just over complicating something (in addition to some miners not playing nicely with algo switching).

I hope this is just a hierarchy and UI design issue and not intended to inflate licenses for each rig. If it's not the case, I do have a lot of ideas to help you improve your UI and make things much more manageable, but I'm not racking up N number of licenses per physical computer.

What kind of mining software is it? Can you please select the miner and click the Diagnostics button in the toolbar to get more details?

You can add, modify and remove miners from the Options dialog, if you select the "Managed Miners" section in the list on the left side. If you use External Miners later on, they are found in "External Miners" section of the Options dialog.

As you pointed out in a later post, you can add, modify and remove hosts from the Options dialog, "Managed Hosts" section.

A Host is basically only a server name and not changed that frequently. That's why you can only add them from the miner properties, but have to go to Options dialog, Managed Hosts section to modify or remove.

Is the scenario that you want to define configuration for both Sgminer and Etheruem Mining, and be able to start one and stop the other in an easy way? Right now that will require you to define two Managed Miners for the same Host.

The increase in number of mining software the last year is probably one of the reasons for this. In the past GPU mining was basically Sgminer and that you change coin by simply defining many pools and do a Change Pool operation. This way you always had one Managed Miner and you could change between all popular algorithms by changing pool.

Over the last year, I've added support for Claymore's miners, now a total of 3 of them. Because it's different mining software with different behaviors, you need to define a Managed Miner for each of them you want to use.

For the next major release of Awesome Miner, there will be a new profit switching where you can have a single Managed Miner, but it can easily change between multiple mining software. This will reduce the number of Managed Miner instances needed, and should address the issue you describe.

You are correct about the ASIC scenario - that one is easier because there is no concept of changing mining software.

I appreciate all the feedback you are providing. I'm always taking notes based on these kind of comments in order to improve the future releases of Awesome Miner. Thanks!

So I'm curious, after some playing around. Is the coin, pool, and miner management so messed up so it encourages people to make more then one miner per rig and thus increase the license they purchase?

I'm trying to figure out how to manage multiple coins and the only way to do it is by creating a new group with the same rig in it with different mining software and pool parameters. Since GPU mining is complicated and requires multiple different mining distributions to mine different algos. Each 'miner' NOT rig is seen as a 'instance' and therefore requires a mining 'instance' spot in the license. This balloons exponentially with the amount of rigs you have and the coins you mine (it multiplies). So if you mine equihash, ethereum, and lbry on three rigs, you basically require nine 'instances'. If you mine more (and there is a lot more algos, coins, and miners) it's going to expand out even further. The only way to address this is to tediously edit each 'instance' and change everything manually, which is really no different then editing rigs manually without software.

I had already made a post addressing a lot of the bugs, UI issues, and problems with the miner which I haven't posted yet as I'm still figuring things out, but if this is by design this is absolutely unacceptable.

Maybe this is a misunderstanding and this is designed more for ASICs where there isn't multiple miners per 'computer/device/workstation'?

Apparently somehow my installation got corrupted after updating to the newest version and was causing the connectivity problems. Reinstalled and deleted the app data and was able to connect to the miner correctly.

Hosts can be edited in the options. When you add hosts via the properties page, there is no way to edit them there. That's what was confusing me (not sure why you still can't edit them there or it takes you to the options panel for pools).

Still haven't figured out how to remove a miner once you add one besides editing xml.

There doesn't seem to be anyway to manage a repository of miners (once you transfer them to the miner). You can go into the properties on the miner > path browse there, but that doesn't allow you to easily manage distributions across multiple miners.

Thanks for the feedback.
That miner will probably work, as all standard compliant miners works with Awesome Miner.

The rig in the list just sits at 'starting' and doesn't do anything else. What's wrong?

Why can't you remove miners after you add them to the miner list?

I'm going to make a more inclusive post of things that could definitely made better, but I can't get it to work at the most basic level. I'm using the free version to try things out, not sure if that matters.

Edit: For some strange reason, the service wont start the miner, but will connect to the management console. After restarting the management console and the service over and over again, sometimes it will start a miner. Really weird. It seems to work better when connecting to IP instead of host name. Still doesn't reliably work.

Running Windows 8.1 x64 on both machines. Also why is 'host' and 'new host' even a option? This should be configured in the actual properties of the miner. There is no way to edit current hosts or delete them, they just pile up.

1st, love Awesome miner.

Now for the fun... I just added 3x of the Avalon 721 miners to my farm and after I configured the Avalon controller with CGminer switches needed for Awesome to communicate I was flabbergasted to see this:


Now, the Avalon software in the controller shows a perfectly smooth 19-20THs for the trio and CKpool reports a solid tad over 19THs. Just as expected. So what's with the 40THs spikes swamping the scale factor? Are the trio of Avalon's actually hitting those speeds? Makes it damn hard to see how the s7's, 9's, and R4 are doing

Any way to filter the sampling response to smooth it out?

We are using Awesome miner in our facility and it works really good. Support is also excellent.

I wonder if the Baikal Giant-A900 is or will be supported?

Awesome Miner Version 2.3

• Added support for temperature and device display for Antminer T9 and Antminer L3
• Added support for Claymore's CryptoNight GPU Miner (Monero)
• The rule for Offline Detection adds configuration of offline duration before the rule is triggered.
• Sgminer 5.6, including Pascal algorithm
• Claymore's Zcash Miner 12.0
• Several corrections

First of all, the change frequency changes may not work correctly on the latest S9 batches because those miners handle the frequency configuration in a different way.
Both when makng frequency and API Access changes, Awesome Miner will only restart the mining software process on the Antminer. It's not a complete reboot.

do you know if awesomeminer can change the frequency of the S9 witohut restart it?
just curious....
but maybe i'm sayng bullshit..
i immagine to slow down frequency if the room temperature is too high.

I can break nearly anything  , so I will let you know if I find other issues.

Good catch - thanks! This miner reported a very long software string, so I will make some user interface adjustments to make it look better.
Please continue testing the new development version of Awesome Miner and provide feedback!

Awesome Miner can do all that, including remote monitoring via a web interface and e-mail notifications. The web interface works well with both smart phones and desktop web browsers.

There are many happy users out there running Awesome Miner with Antminer S9.

Will try and report. Thanks 

Hi,
Try to enter only the first part: http://shittycoinexp.info/api
However, some block explorers work differently than the standard, so if it doesn't work, please give me some examples and I will look into adding support for it.