I've seen a number of discussions about the Excavator miner, and I've just implemented initial support for the recent versions of Excavator as an External Miner. It's included in the latest Awesome Miner release where it's at least possible to monitor it.
I do have an implementation for it as a Managed Miner in the pipeline as well, but that one needs a bit more testing before I will release it. More operations will also be made available later on.
The Excavator mining software is a bit special, and it looks like the configuration file needs to be specified with the number of workers you want for each GPU (the worker.add command). From an Awesome Miner point of view it would be great if Excavator simply could use all GPU's by default, because having Awesome Miner detecting GPU's first and then launch Excavator with a configuration based on this is a possible source of error.
The Excavator miner also provides very few configuration options via the command line, making it difficult to override any behaviors that Awesome Miner will enforce by default. I will try to come up with a good way to support this software anyway, but it's has a "unique" design.
In addition to the above, the Excavator miner will never be downloaded automatically due to the restrictions in the Nicehash EULA.
I do have an implementation for it as a Managed Miner in the pipeline as well, but that one needs a bit more testing before I will release it. More operations will also be made available later on.
The Excavator mining software is a bit special, and it looks like the configuration file needs to be specified with the number of workers you want for each GPU (the worker.add command). From an Awesome Miner point of view it would be great if Excavator simply could use all GPU's by default, because having Awesome Miner detecting GPU's first and then launch Excavator with a configuration based on this is a possible source of error.
The Excavator miner also provides very few configuration options via the command line, making it difficult to override any behaviors that Awesome Miner will enforce by default. I will try to come up with a good way to support this software anyway, but it's has a "unique" design.
In addition to the above, the Excavator miner will never be downloaded automatically due to the restrictions in the Nicehash EULA.
Thank you for adding Excavator support and for the effort to integrate new api from it.
I want to propose to you some improvements :
1) I think it would be very useful for all AM users to see also the hash-rate a pool records for us. Lately almost all pools had connection problems, was stopped or they are simply recording a lower hashrate than the one that we see on miner's window.
To achieve this you have to call pool's API : https://www.ahashpool.com/api/walletEx/?address= and you have the list of all miners. You have to uniquely identify each AM instance by assigning a uniquely generated random ID (that appears also in API json from the pool) that remains the same for a RIG (do not generate a new id when starting a new miner to track past values). Now that you have uniquely identified each instance you will have to download every 1 minute a new JSON from the link above and add values together with timestamp in an array you store for each pool and algo. By making the difference between 2 consecutive different values and divide to the number of seconds between the 2 values you have the real HashRate per second from the Pool. You also can show values like : unsold, balance and unpaid for that pool.
The implementation from above will give us very useful insight about each pool performance and can help us earn more, now that BTC has a very low value, every optimization is really useful.
2) Sometimes when pools have too many connections they disable new connections for a period of time for a specific algo. In this case AM remains stucked with the last value AM received from the mining instance of ccminer and does nothing to fix that.
I believe it would be better to show income statistics based on submitted (and also accepted shares) , instead AM now remains without any refresh to the last hash rate that was submitted by ccminer even hours ago.
If AM waits for hours for an updated hashrate from ccminer and does not take time into consideration it is not the correct behavior. It should have a timer that checks every x seconds the received hashrate from the miner (if there isn't an updated value - identical values could also be a problem - , the for several checks, that miner has an issue) with one minute delay when miner is started to allow all GPUs to be started and send hash rates. Like this if one pool / algo server is offline, it will change to the next most profitable algo from the list.
What do you think, Patrike ?
1) I'm planning to add the pool balance on the Balance tab, just below the existing list of wallet addres balances. This item is quite high on my priority list, but the implementation has not yet started. Hopefully I will have it done before the end of this month.
2) I've already started the implementation for detecting pool failures as part of the profit switcher. What I've implemented so far is that the profit switcher looks at the number of Accepted Shares. If it's not moving for 5 - 10 minutes (configurable), the pool will be marked as "failed" and will be ignored by the profit switcher for 2 - 24 hours (configurable). The profit switcher would then move on to the next pool that isn't marked as "failed".
What I've implemented so far should at least partially solve the case you describe. Hopefully I will be able to have a first release with this feature later this week.
Thank you very much, Patrike.
We are frustrated because a lot of money are lost when AM does not take actions to solve issues like failing miners or pool failure.
It is very important to have them solved, because even if it is not being reported, the problems from above are present to all users of AM that paid for the premium version.
I do appreciate that you are concentrating on fixing the functionality of the software and I hope it will be ready soon, it will reduce our stress with the monitoring and errors we see.
Questions:
1) If I want to add more custom pools, is AM compatible with all type of pools with full support, or just Yiimp pools ?
2) Do you know if there is a list somewhere with a list of pools ordered by number of miners ? I am asking this because lately HashRefinery is doomed, and it is misleadingly reporting revenue of $400/day/rig instead of a real rate like $40/day/rig and makes AM switch to HashRafinery and actually do $10/day/rig . To solve this I disabled HashRafinery. Zpool recovered a little on past 2 days from DDOS attacks, but zpool now has 30k miners, probably they upgraded hardware with load balancing.
So I do not have too many options I only use AHashPool and MPH and I want to check some other good pools that can be integrated latter in AM and that will solve another problem that AM is currently causing to pools. For example when a new algo is more profitable, all 2000 miners witch from one algo to another and DDOS protection (or system sudden overload) denies connections from a part of them. Having more options might distribute the load a little for similar values like +/-$2 and also will allow AM to function better with the solution you are implementing right now.
What do you think ?
PS: If you check HashRefinery right now (http://pool.hashrefinery.com/site/mining on nist5 algo) , they started reporting $600/rig/day on nist5 and in just 1 minute the number of miners on nist5 form HashRefinery whent form 100 to 10800 miners on nist5 ... WOW . Also, I had one test rig to see what is happening, it simply was not being able to connect to HasRefinery because there were already 9300 connected and probably their server crashed. Do you think the users that switched to HasRefinery/Nist5 made anything ? All the miners lost the money during this period and also ccminer had red error on screen with connection refused, retry in 30 sec for 10 minutes, without any action form AM to switch to the next pool from the list.
