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

[patrike]

I find that many a times on diff miners, the awesome miner fails to extract the folder and is stuck extracting the files in download.
Do i need to run as admin or something? This is new and i havent had this issue before.

If you run into a problem where the mining software isn't extracted correctly:

1) Please check if the downloaded zip-file for the mining software is valid or corrupt - this could be valuable information to know
2) Please collect the Remote Agent log file for when this happend and send the information to me. I can then review the scenario.

Thanks!

[patrike]

Hello Patrike, I have more suggestions on temperature control, and problems.

I have suggested a double OC, but it would be too much, I suppose, for 4 months of heat, that is, 1/3 of the year.

I am using the maximum temperature in OCs, but it has a big problem. If I put a generous OC, many cards reach the limit and start falling from Core, and as a result the rig yields much less because when you lower the core, it yields less, much less. Only at night goes well when temperatures drop.

If I put a very smooth OC, I will not reach those temperatures day or night, but it would also be producing less hash.

Lowering the core is very effective but produces a too strong drop in the hash, so my suggestion is:

You can do the same but instead of downloading the core in real time, whatever you reduce is the TDP or power of the source to that card. That also reduces the temperature but does not produce such a strong hash drop. In fact, it can produce more because it does not heat up and the core is not lowered. Or a combined system, that lowers a bit of core and a little power or TPD from the source.

A real example, the same night rig Cucka31 8.22 mhs, day 6.2 mhs. If I put a soft OC so that neither day nor night comes, I would stay at about 6.7 -6.9 mhs

That's why I asked for double oc, but I think that a system that drops the Power to each card by independent in steps of 5, would be fine.

What is 80 power 90 core, 500 memory. Well I get down to 75 90 500, that is not enough I would lower 70 90 500. The lowering of electric power, does not drop the hash as much. But the same as the core, card by card. I do not know if you can, if you can please you can add it as an option in the OC.

And it is impossible to have a single CB that serves both the day and the night without losing hash.

This is an interesting concept.

If it's only a single parameter like the "Power Limit" it should be possible for Awesome Miner to figure out what to do with it to reach some target power usage. The challenge with only a target power usage is that it's different depending on the GPU.

What about defining some offset? Like during certain hours (night time) Awesome Miner should take your power limit and reduce it by 10% for all profiles for example? That would work even with mixed GPU's and will not require so much work for you to configure even if you have many clocking profiles.

[patrike]

Then there is another secondary problem.

The auto profit does it according to the benchmark profile or to save the Hash.

But of course in my profile it puts 8.22 in cucka31, but in the day it does not even reach 7, but it does not change the currency because what it sends is the saved hash, not the hash that is being produced.

That is the important thing to be able to have a better solution for the temperatures, because it is not only the fact that it yields less, but also that it is more serious because the auto switch does not look at real parameters (impossible for X16r for example), but I want you to understand that problem

A Rig produces X power in a Something, but when that Rig in summer by temperature yields 20% less, it does not take it into account. Somehow the programming of the auto switch should know if that rig has 1 or several cards of reduced core or power, and automatically apply to the hash saved a transparent reduction, so as to better guess with the hash changes produced by the heat. It would be something to keep in mind. It is clear that if 1 or more cards are in the limit of temperature, low pontencia and the hash they get is not the one that is saved as a reference, but knowingly, you can apply a transparent reduction to that hash when one or more cards are in maximum temperature, because they will not be producing their maximum. I hope you understand what I mean.

Right now the auto profit with the function of maximum temperature lowering the core and dropping the hash, is not realistic in its changes, and keeps me in currencies that are not the most profitable at that moment because of the heat.

Awesome Miner is currently only measuring the hashrate and power usage based on the clocking you had when you do the benchmark. In this case you have taken care of the temperature by lowering the performance, and at this point the previously benchmarked hashrate and power usage is no longer fully correct. I do understand your point here - that you may not be able to reach this level of hashrate and power usage due to high temperatures.

I don't think there is any easy solution to this as Awesome Miner would have to be quite smart about finding out this automatically without making any mistakes.

[patrike]

Antminer Z11 hashrates are reported as Mh/s instead of Kh/s on my awesome miner windows GUI. As a result daily payout looks like $10,000 per day instead of $10 per day. Anyone else have this issue?

I know that recent Z11 firmwares have some changes to the reported hashrate unit.

Could you please send me the API report (toolbar: Tools -> API Report) for this miner via PM? Thanks!

[patrike]

Hi patric, I have started to use remote GPU rig (not local network) on windows10pro, but main AW window not show power usage for this rig and of course calculate wrong total profit.
If i go to GPU tab in AW for this rig, i see power usage for every GPU in this rig.
I have asics which is controled from the same AW instance in local network and power usage control/profit calculation works right.
In my config asics and gpu placed in different miner groups.
pls help....

Can you please go to the Options dialog, Profitability section, and make sure the "Power usage mode" is set to one of the modes including "Actual usage"?

[patrike]

Anayone seen the "coin prices" on bottom of program ?
For me all are ok.. changing live, except for BTC witch was rising .. now it still shows 10.968,50 € whitch is wrong price..

Please note that since a while ago, Awesome Miner is getting the BTC exchange rate via our Amazon servers. Please make sure you don't have any general blocking of Amazon Web Services in your firewall or similar. If you can access this URL via your web browser, it indicates that the connection is fine:
https://5aozpdg9s2.execute-api.us-east-1.amazonaws.com/cachedprod/SystemOverview

[SiddFan]

Anayone seen the "coin prices" on bottom of program ?
For me all are ok.. changing live, except for BTC witch was rising .. now it still shows 10.968,50 € whitch is wrong price..

Please note that since a while ago, Awesome Miner is getting the BTC exchange rate via our Amazon servers. Please make sure you don't have any general blocking of Amazon Web Services in your firewall or similar. If you can access this URL via your web browser, it indicates that the connection is fine:
cute-api.us-east-1.amazonaws.com/cachedprod/SystemOverview

I can not access it..

All firewalls off

[patrike]

Anayone seen the "coin prices" on bottom of program ?
For me all are ok.. changing live, except for BTC witch was rising .. now it still shows 10.968,50 € whitch is wrong price..

Please note that since a while ago, Awesome Miner is getting the BTC exchange rate via our Amazon servers. Please make sure you don't have any general blocking of Amazon Web Services in your firewall or similar. If you can access this URL via your web browser, it indicates that the connection is fine:
https://5aozpdg9s2.execute-api.us-east-1.amazonaws.com/cachedprod/SystemOverview

I can not access it..

All firewalls off

Please send me your Awesome Miner log file (toolbar: Tools -> Log File) via mail or via the Support form on the web site. Thanks!

[GKumaran]

Running GMiner adds --pers auto to the command line, how to change this behaviour. Seems counter productive to add --pers for each equihash algo as a new custome miner

[patrike]

Running GMiner adds --pers auto to the command line, how to change this behaviour. Seems counter productive to add --pers for each equihash algo as a new custome miner

Awesome Miner should only add 'auto' if your pool (see the Properties dialog) doesn't have any Personalization String defined. Once you define your own personalization string for the specific coin you are mining, Awesome Miner will use that one instead of 'auto'.

[GKumaran]

Works perfectly, Thank you.

[trucobit]

Then there is another secondary problem.

The auto profit does it according to the benchmark profile or to save the Hash.

But of course in my profile it puts 8.22 in cucka31, but in the day it does not even reach 7, but it does not change the currency because what it sends is the saved hash, not the hash that is being produced.

That is the important thing to be able to have a better solution for the temperatures, because it is not only the fact that it yields less, but also that it is more serious because the auto switch does not look at real parameters (impossible for X16r for example), but I want you to understand that problem

A Rig produces X power in a Something, but when that Rig in summer by temperature yields 20% less, it does not take it into account. Somehow the programming of the auto switch should know if that rig has 1 or several cards of reduced core or power, and automatically apply to the hash saved a transparent reduction, so as to better guess with the hash changes produced by the heat. It would be something to keep in mind. It is clear that if 1 or more cards are in the limit of temperature, low pontencia and the hash they get is not the one that is saved as a reference, but knowingly, you can apply a transparent reduction to that hash when one or more cards are in maximum temperature, because they will not be producing their maximum. I hope you understand what I mean.

Right now the auto profit with the function of maximum temperature lowering the core and dropping the hash, is not realistic in its changes, and keeps me in currencies that are not the most profitable at that moment because of the heat.

Awesome Miner is currently only measuring the hashrate and power usage based on the clocking you had when you do the benchmark. In this case you have taken care of the temperature by lowering the performance, and at this point the previously benchmarked hashrate and power usage is no longer fully correct. I do understand your point here - that you may not be able to reach this level of hashrate and power usage due to high temperatures.

I don't think there is any easy solution to this as Awesome Miner would have to be quite smart about finding out this automatically without making any mistakes.

Rather it was commenting on if there was something easy but if you tell me it would be complicated, then I am satisfied. I'll look somehow the middle hash to put it by hand. I imagined that the auto profit was going to be difficult to modify by taking the benchmark reference. I leave a suggestion to see if it serves you. You can use an average of (benchmark + current hash) / 2 for Auto profit, so you have a very real average, you combine the saved hash + the hash generated at the moment divided by 2 to have a mean. It will always be a more real approach than just the benchmark. It's just a suggestion that I just came up with, it could be used for the whole year. The bad things are the algos that are extremely variable like x16r. Well it's just a suggestion, I understand how difficult it is and I understand that it is not done.

I am more interested in reducing power instead of Core, or even a mixed system, that works the same as the current temperature limit but primarily reduces Power and with less emphasis on Core. The point is to control the temperature with the lowest hash drop. There will always be a hash fall, it is inevitable, but according to my tests at hand, the hash suffers much less reducing power to that card, as it continues to maintain the CORE and is sometimes even able to keep the hash almost intact. But with the reduction of core the hash always falls.

The idea is as simple as putting another temperature limit option, that there are two, one for Core the current one and another for Power as I suggest, it has no more problem. Instead of 5 in 5 jumps it can be shorter steps like 2 in 2, or 3 in 3. But I tell you in tests that I have done by hand, many times the hash does not suffer just because the core is still intact and the temperature drops by power reduction. I also see it very interesting

As always I try to be constructive with my suggestions or criticisms, and I think that your system is the best in the market.

Finally, I still have some online interface problems but really if it is working, that is a direct problem with intelibrezee, I am already using windows 1903 which is quite stable. I have greatly reduced that error with this version but it still continues to appear and you have to restart once or several times until AM reads that remote well. Because I understand that this problem is remote.

[trucobit]

Anayone seen the "coin prices" on bottom of program ?
For me all are ok.. changing live, except for BTC witch was rising .. now it still shows 10.968,50 € whitch is wrong price..

Please note that since a while ago, Awesome Miner is getting the BTC exchange rate via our Amazon servers. Please make sure you don't have any general blocking of Amazon Web Services in your firewall or similar. If you can access this URL via your web browser, it indicates that the connection is fine:
cute-api.us-east-1.amazonaws.com/cachedprod/SystemOverview

I can not access it..

All firewalls off

I access perfectly and I also have all the firewalls turned off, and I say all because the general and the defender are there, each one separately.

[trucobit]

Running GMiner adds --pers auto to the command line, how to change this behaviour. Seems counter productive to add --pers for each equihash algo as a new custome miner

Do not add that line to the property miner, add it in each Pool in advanced, so each equihash currency can have its own line, because it changes according to the Equihash currency, so it is appropriate in the pool where you define the currency in Advanced and only It affects that pool.

[patrike]

The idea is as simple as putting another temperature limit option, that there are two, one for Core the current one and another for Power as I suggest, it has no more problem. Instead of 5 in 5 jumps it can be shorter steps like 2 in 2, or 3 in 3. But I tell you in tests that I have done by hand, many times the hash does not suffer just because the core is still intact and the temperature drops by power reduction. I also see it very interesting

As always I try to be constructive with my suggestions or criticisms, and I think that your system is the best in the market.

In a perfect world the existing Temperature Limit feature provided by the nVidia drivers would take care of this. You can already define the temperature limit and the nVidia drivers take action to keep it. The problem we agree on is that the nVidia drivers lowers the Core clock significantly and this results in much lower hashrate. So although the nVidia drivers keeps the temperature, it's not doing it in a good way for mining.

The nVidia drivers can however guarantee that you never go above the Temperature Limit as they enforce it so hard.

Awesome Miner could have it own Power-reducing Temperature Threshold feature in addition to what nVidia gives us. Awesome Miner could monitor the temperature and if it goes above 79C (configurable), it will reduce the Power Limit to 85% (configurable) and it it's above 82C (configurable) it will set the Power Limit to 65% (configurable). It's not that easy for Awesome Miner to guarantee a temperature here, but it could at least reduce the power usage and making it less likely that you hit the nVidia Temperature Limit that will do harder underclocking.

A concept where you are allowed to define two power reduction levels based on two temperatures should be realistic to implement in Awesome Miner. Would that make sense?

Finally, I still have some online interface problems but really if it is working, that is a direct problem with intelibrezee, I am already using windows 1903 which is quite stable. I have greatly reduced that error with this version but it still continues to appear and you have to restart once or several times until AM reads that remote well. Because I understand that this problem is remote.

I don't mind looking at the log files for this again - in case I can find out anything more. Please send me the logs via PM and let me know the time you did see the issues. Thanks!

[patrike]

Awesome Miner version 6.7.1

 ASIC mining
  - Added Innosilicon ASIC features for reboot, setting tuning profile, firmware upgrades and password change
  - Added support for Antminer Z11e
 Integration
  - UBQ block explorer updated
 User interface
  - The GPU Detailed Report dialog can be accessed via the GPU tab
 Mining software
  - CcMiner Zcoin Official 1.1.24
  - Ethminer 0.18.0
  - Gminer 1.53
  - CpuMiner-Opt 3.9.6.1
  - TeamRedMiner 0.5.6
  - Bminer 15.7.4
 Corrections
  - Correction to Ethminer protocol name for Nicehash and to not add -X parameter
  - Adjusted Grin coin calculations after the recent fork

[trucobit]

The idea is as simple as putting another temperature limit option, that there are two, one for Core the current one and another for Power as I suggest, it has no more problem. Instead of 5 in 5 jumps it can be shorter steps like 2 in 2, or 3 in 3. But I tell you in tests that I have done by hand, many times the hash does not suffer just because the core is still intact and the temperature drops by power reduction. I also see it very interesting

As always I try to be constructive with my suggestions or criticisms, and I think that your system is the best in the market.

In a perfect world the existing Temperature Limit feature provided by the nVidia drivers would take care of this. You can already define the temperature limit and the nVidia drivers take action to keep it. The problem we agree on is that the nVidia drivers lowers the Core clock significantly and this results in much lower hashrate. So although the nVidia drivers keeps the temperature, it's not doing it in a good way for mining.

The nVidia drivers can however guarantee that you never go above the Temperature Limit as they enforce it so hard.

Awesome Miner could have it own Power-reducing Temperature Threshold feature in addition to what nVidia gives us. Awesome Miner could monitor the temperature and if it goes above 79C (configurable), it will reduce the Power Limit to 85% (configurable) and it it's above 82C (configurable) it will set the Power Limit to 65% (configurable). It's not that easy for Awesome Miner to guarantee a temperature here, but it could at least reduce the power usage and making it less likely that you hit the nVidia Temperature Limit that will do harder underclocking.

A concept where you are allowed to define two power reduction levels based on two temperatures should be realistic to implement in Awesome Miner. Would that make sense?

Finally, I still have some online interface problems but really if it is working, that is a direct problem with intelibrezee, I am already using windows 1903 which is quite stable. I have greatly reduced that error with this version but it still continues to appear and you have to restart once or several times until AM reads that remote well. Because I understand that this problem is remote.

I don't mind looking at the log files for this again - in case I can find out anything more. Please send me the logs via PM and let me know the time you did see the issues. Thanks!

I propose suggestions, you tell me if it makes sense that there are two different systems to control the temperature, the one that already exists of Nvidia and the one that I commented through reduction of power.

Well, I don't know, you can do some programming tests, and see if it's really worth it. It is those schedules, that until you do a test in production you do not know if it is valid or not.

When you can compare the existing one with the one I suggest, in a programming environment and do 3 or 4 tests, and see if it really controls the temperature well and if the hash really falls less ... After doing it in tests, you You can decide whether it is worth it or not.

I have checked by hand, testing only by varying TDP or power and the hash reduced me almost always.

It is in your hand to try it or not, it is in your hand not to do it if you do not want it, I only provide ideas, suggestions. The current system works very well, but at the cost of losing enough hash in the hot hours, you can live with it, you just have to have a moderate OC. But if it is true that I would like you to at least try it in your programming environment and draw your own conclusion.

[GKumaran]

Code:

25-07-2019 09:49:58 PM.221 [009] [I][ManagedMiner#7 - Vega Rig] : ProcessMiner
25-07-2019 09:49:58 PM.221 [009] [E]System.IO.FileNotFoundException: Could not load file or assembly 'AwesomeMiner.ResourceAccess.Asic, Version=6.7.1.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
25-07-2019 09:49:58 PM.221 [009] [E]   at #=zgfBCWpQmeFuYIMGOw3SBNiW1m8UYcXNWa5nltMBwv6k3ddha60u44jHGa9ZJ..ctor()
   at #=zu7haAQa3AnJO2oyd$5pjMIpnxuzLHMJqw0a28NNQpdi$..ctor()
   at #=zQLN_D9ujnJv_wtRddKee5e8MY9FBncVKeKDobdE=.#=zOPdjUapFMX_$(String #=zvZcBBg4=)
   at #=zjqpSM22GL_x_QBYZCf4CAIUkj$Q2KzxdJpvcgbIFDm9a.#=z$Tye9fU=(MinerBase #=zbm34RMai5A4G, StatusUpdate& #=zH4K_FL0=)
25-07-2019 09:49:58 PM.659 [018] [S]Send service log file

Miner shows mining but no stats. Tried rebooting miner, windows, awesome miner.
Edit: Miner is TeamRedMiner 0.5.6, any seeing this same state on multiple miners.

[chuckinsuburbia]

I've noticed an issue with User-Defined Managed Software for CPU/GPU as it relates to the algorithm/-a parameter.  See below for a log from a Linux agent that shows the command line is missing the "-a m7m" parameter, and therefore fails.  Has anyone else seen this and have an idea how to address it?

Code:

6/20/19 7:51:24 PM.645 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] : Adding pool: stratum+tcp://m7m.mine.ahashpool.com:6033
6/20/19 7:51:24 PM.645 [014] [S]Set execution permission for: /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer
6/20/19 7:51:24 PM.651 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] Properties: (WindowMode: ConsoleFormat, EngineType: 20, IsProfitMiner: False)
6/20/19 7:51:24 PM.652 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] ====================================================================================================
6/20/19 7:51:24 PM.652 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer  -o stratum+tcp://m7m.mine.ahashpool.com:6033 -u [redacted] -p c=BTC --api-remote -b 0.0.0.0:4030
6/20/19 7:51:24 PM.652 [014] [S][ManagedMiner#89 - HMDNoah1 CPU] ====================================================================================================
6/20/19 7:51:24 PM.757 [014] [S]Set Diagnostics executable: /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer
6/20/19 7:51:24 PM.758 [014] [S]Creating start script: /root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/awesome-start.sh, Command:
stdbuf -o L "/root/AwesomeMinerService/cpuminer-opt-3.9.4-linux_3/cpuminer"  -o stratum+tcp://m7m.mine.ahashpool.com:6033 -u [redacted] -p c=BTC --api-remote -b 0.0.0.0:4030 &> "/root/AwesomeMinerService/diag.txt"

Thanks for the details. I was able to reproduce and correct the issue. It was an issue introduced in the latest development release. There will be a new release available soon.

Unfortunately this still seems to be an issue in 6.5.7.

For this user defined Managed Software you added for CpuMiner - have you configured it to have the compatibility mode "Full" with CpuMinerOpt?

I might have identified one more issue specific to the Remote Agent on Linux here, but only related to custom algorithm parameters.

Yes, it is configured as Full (Command line and API).  Sorry, I probably should have mentioned in my original post, but I saw some similar behavior with the Windows agent in 6.5.6 where it would not use the algorithm argument from the "Default command line argument" column, but would use an argument from the "User defined command line algorithm" column even if it was the same value.  I worked around this by simply replicating all the default args as user defined args.  But this workaround did not seem to work for the Linux agent.  So this may be a combination of multiple issues.

I'm happy to provide any additional info you might need to track this down.

What I still could reproduce on Linux for 6.5.7 was that the "User defined command line" not being used correctly and I will of course correct that. It should however fallback to use the "Default command line argument" in 6.5.7 (didn't work in 6.5.6). Is it not even doing this fallback when you test it?

I'm away from my rigs for a day or so, but I will run through some more tests as soon as I can and post the results.

My apologies for the super delayed response, just wanted to say that whatever issue I was seeing before seems to have been resolved at this point.

[patrike]

Code:

25-07-2019 09:49:58 PM.221 [009] [I][ManagedMiner#7 - Vega Rig] : ProcessMiner
25-07-2019 09:49:58 PM.221 [009] [E]System.IO.FileNotFoundException: Could not load file or assembly 'AwesomeMiner.ResourceAccess.Asic, Version=6.7.1.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
25-07-2019 09:49:58 PM.221 [009] [E]   at #=zgfBCWpQmeFuYIMGOw3SBNiW1m8UYcXNWa5nltMBwv6k3ddha60u44jHGa9ZJ..ctor()
   at #=zu7haAQa3AnJO2oyd$5pjMIpnxuzLHMJqw0a28NNQpdi$..ctor()
   at #=zQLN_D9ujnJv_wtRddKee5e8MY9FBncVKeKDobdE=.#=zOPdjUapFMX_$(String #=zvZcBBg4=)
   at #=zjqpSM22GL_x_QBYZCf4CAIUkj$Q2KzxdJpvcgbIFDm9a.#=z$Tye9fU=(MinerBase #=zbm34RMai5A4G, StatusUpdate& #=zH4K_FL0=)
25-07-2019 09:49:58 PM.659 [018] [S]Send service log file

Miner shows mining but no stats. Tried rebooting miner, windows, awesome miner.
Edit: Miner is TeamRedMiner 0.5.6, any seeing this same state on multiple miners.

Thanks for your report - I've identified the scenario when this happens. I will release a new version in about an hour to resolve this.