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

[Lunga Chung]

Thanks for the update.

Awesome Miner should display what the Antminer API is reporting. Could you please have a quick look at the numbers you see in the Antminer web interface and compare them with what the API is reporting?
1) Select a miner and click on the toolbar: Tools -> API Report
2) Search for the following three properties near the end of the file:
chain_consumption6
chain_consumption7
chain_consumption8

These are all indicating power usage in Watt for each of the three chains. The total is the power usage Awesome Miner should display. Can you please compare this with the Antminer web interface as well - and we might be able figure out the issue.
Many thanks!

Sure.....


This is from the API

API command: stats
chain_vol6":840,"chain_vol7":840,"chain_vol8":840,"chain_consumption6":422,"chain_consumption7":405,"chain_consumption8":420,"miner_version":"26.0.1.3","manual_fan_mode":false,"build_version":"for AWESOME 3.8.6"}],"id":1}

So API/web monitor says 1247W

On AM set to actual,fall back to static says 1290~1300W

[GKumaran]

Im not sure how the dead device detection as sick works. I 'think' AM is rebooting my rigs without cause.

Rig: 6x Vega 64 running TeamRedMiner

Log from Miner:

[2019-08-06 12:41:44] Pool europe.cryptonight-hub.miningpoolhub.com share accepted. (GPU0) (a:1690 r:0) (378 ms)
[2019-08-06 12:41:46] Pool europe.cryptonight-hub.miningpoolhub.com share accepted. (GPU0) (a:1691 r:0) (377 ms)
[2019-08-06 12:43:56] Initializing GPU 0.
[2019-08-06 12:43:57] Initializing GPU 1.
[2019-08-06 12:43:58] Initializing GPU 2.
[2019-08-06 12:44:00] Initializing GPU 3.
[2019-08-06 12:44:01] Initializing GPU 4.
[2019-08-06 12:44:02] Initializing GPU 5.
[2019-08-06 12:44:03] Watchdog thread starting.

The miner has a built in watchdog, and im pretty sure if a GPU had crashed the miner watchdog would have picked it up before AM does. Note how the shares are submitted till 12:41:46 and then a reboot of rig, so no log for 2 mins and miner starts again

Log from Awesome Miner:

06/08/2019 12:41:56 PM.132 [022] [ S][ManagedMiner#7 - Vega Rig] Dead device detection: Sick
06/08/2019 12:41:56 PM.132 [022] [ S]Rule execute: Dead device detection, miners: [Vega Rig, 192.168.100.33]
06/08/2019 12:41:56 PM.144 [022] [ S][ManagedMiner#7 - Vega Rig] Run Miner Command: Reboot
06/08/2019 12:41:56 PM.145 [022] [ S]Rule execution done: Dead device detection

Based on the above logs, 10 seconds after the last shares the rigs is marked as sick  

Log from Remote Agent:

06-08-2019 12:41:52 PM.950 [009] [ManagedMiner#7 - Vega Rig] : ProcessMiner
06-08-2019 12:41:52 PM.950 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"config"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"summary"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"privileged"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"devs"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"pools"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"coin"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"stats"}
06-08-2019 12:41:54 PM.841 [020] MinerService.AddMinerCommand
06-08-2019 12:41:54 PM.841 [020] [ S]MinerService.AddMinerCommand from client: 192.168.100.29:33439, Reboot
06-08-2019 12:41:54 PM.841 [020] [ S]Command request: Reboot
06-08-2019 12:41:54 PM.841 [007] [ S][ManagedMiner#7 - Vega Rig] Execute command: Reboot
06-08-2019 12:41:54 PM.841 [007] [ S]Reboot of Managed Miner initiated
06-08-2019 12:41:54 PM.904 [007] [ S]Miner commands left to process: 0

Last share by miner : 12:41:46
Last stats query by AM : 12:41:52
Declared sick and reboot init : 12:41:54

I have no clue how this is happening. Since i am pretty sure TRM watchdog would pop the dead GPU and log it before AM !!

[patrike]

Thanks for the update.

Awesome Miner should display what the Antminer API is reporting. Could you please have a quick look at the numbers you see in the Antminer web interface and compare them with what the API is reporting?
1) Select a miner and click on the toolbar: Tools -> API Report
2) Search for the following three properties near the end of the file:
chain_consumption6
chain_consumption7
chain_consumption8

These are all indicating power usage in Watt for each of the three chains. The total is the power usage Awesome Miner should display. Can you please compare this with the Antminer web interface as well - and we might be able figure out the issue.
Many thanks!

Sure.....
This is from the API

API command: stats
chain_vol6":840,"chain_vol7":840,"chain_vol8":840,"chain_consumption6":422,"chain_consumption7":405,"chain_consumption8":420,"miner_version":"26.0.1.3","manual_fan_mode":false,"build_version":"for AWESOME 3.8.6"}],"id":1}

So API/web monitor says 1247W

On AM set to actual,fall back to static says 1290~1300W

Thanks for the report you sent me. There will be a new release later today for this case.

[patrike]

Im not sure how the dead device detection as sick works. I 'think' AM is rebooting my rigs without cause.

Rig: 6x Vega 64 running TeamRedMiner

Log from Miner:

[2019-08-06 12:41:44] Pool europe.cryptonight-hub.miningpoolhub.com share accepted. (GPU0) (a:1690 r:0) (378 ms)
[2019-08-06 12:41:46] Pool europe.cryptonight-hub.miningpoolhub.com share accepted. (GPU0) (a:1691 r:0) (377 ms)
[2019-08-06 12:43:56] Initializing GPU 0.
[2019-08-06 12:43:57] Initializing GPU 1.
[2019-08-06 12:43:58] Initializing GPU 2.
[2019-08-06 12:44:00] Initializing GPU 3.
[2019-08-06 12:44:01] Initializing GPU 4.
[2019-08-06 12:44:02] Initializing GPU 5.
[2019-08-06 12:44:03] Watchdog thread starting.

The miner has a built in watchdog, and im pretty sure if a GPU had crashed the miner watchdog would have picked it up before AM does. Note how the shares are submitted till 12:41:46 and then a reboot of rig, so no log for 2 mins and miner starts again

Log from Awesome Miner:

06/08/2019 12:41:56 PM.132 [022] [ S][ManagedMiner#7 - Vega Rig] Dead device detection: Sick
06/08/2019 12:41:56 PM.132 [022] [ S]Rule execute: Dead device detection, miners: [Vega Rig, 192.168.100.33]
06/08/2019 12:41:56 PM.144 [022] [ S][ManagedMiner#7 - Vega Rig] Run Miner Command: Reboot
06/08/2019 12:41:56 PM.145 [022] [ S]Rule execution done: Dead device detection

Based on the above logs, 10 seconds after the last shares the rigs is marked as sick  

Log from Remote Agent:

06-08-2019 12:41:52 PM.950 [009] [ManagedMiner#7 - Vega Rig] : ProcessMiner
06-08-2019 12:41:52 PM.950 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"config"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"summary"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"privileged"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"devs"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"pools"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"coin"}
06-08-2019 12:41:52 PM.957 [009] Execute API, Hostname: 192.168.100.33:4028, Command: {"command":"stats"}
06-08-2019 12:41:54 PM.841 [020] MinerService.AddMinerCommand
06-08-2019 12:41:54 PM.841 [020] [ S]MinerService.AddMinerCommand from client: 192.168.100.29:33439, Reboot
06-08-2019 12:41:54 PM.841 [020] [ S]Command request: Reboot
06-08-2019 12:41:54 PM.841 [007] [ S][ManagedMiner#7 - Vega Rig] Execute command: Reboot
06-08-2019 12:41:54 PM.841 [007] [ S]Reboot of Managed Miner initiated
06-08-2019 12:41:54 PM.904 [007] [ S]Miner commands left to process: 0

Last share by miner : 12:41:46
Last stats query by AM : 12:41:52
Declared sick and reboot init : 12:41:54

I have no clue how this is happening. Since i am pretty sure TRM watchdog would pop the dead GPU and log it before AM !!

Awesome Miner uses the API data from the mining software to find out if the mining software considers a device to be dead/sick.

Could you please send me the API report (toolbar: Tools -> API Report) for this miner when it's in this state? Thanks!

[patrike]

Awesome Miner version 6.8.2

 Awesome Miner Antminer S9 firmware
  - Display of chip hashrate details on a new ASIC Chip tab for the selected miner
  - Backup and restore of Antminer configuration
 GPU mining
  - The context menu for a Managed Miner will include a link to the support page for the mining software
 Mining softare
  - Phoenix Miner 4.5c for Linux
  - TT-Miner 3.0.1
  - T-Rex miner 0.13.1
  - TeamRedMiner 0.5.7
  - CcMiner Zcoin Official 1.2
 Corrections
  - Correction to power usage display when running the Awesome Miner Antminer S9 firmware

[moppidoo]

Hi Patrike,

I have noticed that lately AM does not use the correct pool when "View Details" shows all profits < 0 for a Managed Profit Miner for my rigs, it has occurred on 6.7.x and since upgrade to 6.8.1, remains the issue.

(i.e, instead of mining at pool x at next least loss level of -$0.01 per day, it go with something at pool y at a loss of -$0.30 per day)

Best Regards,

Edit:
Actually, I think it is still doing the switching correctly but under certain circumstances, it might play up from time to time. I am not sure, but hypothesising on some conflict between rules and Profit Switching Options. Or it might be that the profit switching threshold didn't apply properly when profits are negative.

I noticed I have
Minimum Time to stay on a pool (minutes) option set

+

a Rule that restarts the mining process if Rejected % is above certain threshold in a given period of time.

and according to the above condition

the Minimum time to stay on a pool seems to override Switching Interval on the same Options page (on top), that is, if Min time on pool > Switching interval, then Switching interval = Min time on pool.

then this in conjunction with the reject/restart rule, that say triggered b4 the Min Time on pool is reached, seems to reset the Min Time on Pool and consequently, the Profit Switching interval for a said Managed Profit Miner. so if the reject/restart rule keep triggering due to say, the pool or miner for some reasons throws a lot of rejects, then the profit switching interval can stay indefinitely not triggered (or for hours) until manual intervention or the situation corrects itself whichever comes first (usually the former)

[moppidoo]

Hi Patrike,

Also, Feature Request related to Coin Dynamic Update:

As a reasonable number of coins utilise multi-algo PoW, is there any robust way in your opinion, to duplicate/clone those dynamic properties within AM?

I was thinking about some sort of template feature in Coin Properties -> Dynamic Update -> Provider (consider adding default lists, either from history via other custom coin properties, or standard common ones, especially from more common exchanges fetching prices)

(e.g, if I'm to fetch prices from an exchange say, crex24, I can select it from Provider List and AM will populate the URL (except the Ticker Pair), HTTP method, JSON property expression to

Code:

[0].bid

(subjective, but as far as concerned, bidding price seems more popular to use than asking).

**

And for other properties such as Difficulty, Network Hash (running a local node), it'll be nice to have a history to pull as they all ended up having the same URL, POST body, and slightly different JSON property expression.


Not an urgently needed feature but would be handy (currently in process of adding GlobalToken and it's kinda pita with 60 odd supported algos less the ASIC ones, granted it's likely not profitable to mine it, rather it's able to be merge mined, but would like to keep it as option as well as other coins that uses mult-algos)

Best Regards,

[Asusrogmining]

Hey patrike,

Currently, I am using the latest version of Awesomeminer, and I added ZelCash (2miners) to the pool list. But in the pool options, ZelCash is under Equihash 144.5 not 125.4, and as the result if I select Equihash 144.5 for this coin, Gminer doesn't run at all. And if I select unspecified Equihash 125.4, it doesn’t show the current profit in the dashboard. Please help

Please take a look:
https://imgur.com/a/sMl2EYj

[GKumaran]

Im not sure how the dead device detection as sick works. I 'think' AM is rebooting my rigs without cause.

Awesome Miner uses the API data from the mining software to find out if the mining software considers a device to be dead/sick.

Could you please send me the API report (toolbar: Tools -> API Report) for this miner when it's in this state? Thanks!

Hey did some testing with the miner dev. The miner will declare the GPU as dead after testing it for 10-20 seconds, but AM will declare as Sick in the first signs of trouble.

Suggestions:

• AM logs could show which GPU(bus ID or something) went sick
• It would be preferable if AM could route the "Dead device detection" for TeamRedMiner via the miner commands

Code:

--watchdog_script=reboot.bat

where the reboot command could be stored in the reboot.bat.[/li]

These are just suggestions and not sure which is the optimal method.

My reasoning is : AM reboots on GPU death so soon that miner doesnt log the error(needed to debug the crash) and AM doesnt save in its own logs neither the GPU that crashed nor the API response on crash.

[patrike]

Hi Patrike,

I have noticed that lately AM does not use the correct pool when "View Details" shows all profits < 0 for a Managed Profit Miner for my rigs, it has occurred on 6.7.x and since upgrade to 6.8.1, remains the issue.

(i.e, instead of mining at pool x at next least loss level of -$0.01 per day, it go with something at pool y at a loss of -$0.30 per day)

Best Regards,

Edit:
Actually, I think it is still doing the switching correctly but under certain circumstances, it might play up from time to time. I am not sure, but hypothesising on some conflict between rules and Profit Switching Options. Or it might be that the profit switching threshold didn't apply properly when profits are negative.

I noticed I have
Minimum Time to stay on a pool (minutes) option set

+

a Rule that restarts the mining process if Rejected % is above certain threshold in a given period of time.

and according to the above condition

the Minimum time to stay on a pool seems to override Switching Interval on the same Options page (on top), that is, if Min time on pool > Switching interval, then Switching interval = Min time on pool.

then this in conjunction with the reject/restart rule, that say triggered b4 the Min Time on pool is reached, seems to reset the Min Time on Pool and consequently, the Profit Switching interval for a said Managed Profit Miner. so if the reject/restart rule keep triggering due to say, the pool or miner for some reasons throws a lot of rejects, then the profit switching interval can stay indefinitely not triggered (or for hours) until manual intervention or the situation corrects itself whichever comes first (usually the former)

I didn't see any issues with the profit switching priority in general with negative profit values, but as you point out the combination of using Minimum time on pool might very well be the case.

If your profit switching interval is 1 minute and minimum time to stay on pool is 5 minutes, the profit switching for a specific miner will not happen after running for the first 5 minutes, but then it can happen either at 5 minutes, 6 minutes and so on. Please note that because you can have several miners and profiles, there can be profit changes to different miners every minute - just that for a specific miner it's not more often than 5 minutes.

I will have to explore this case a bit more. If you find out anything more, please let me know.

Another point, maybe there should be a trigger for "mining software uptime", so you can configure rules to not trigger for the first number of minutes from when the mining started.

[patrike]

Hi Patrike,

Also, Feature Request related to Coin Dynamic Update:

As a reasonable number of coins utilise multi-algo PoW, is there any robust way in your opinion, to duplicate/clone those dynamic properties within AM?

I was thinking about some sort of template feature in Coin Properties -> Dynamic Update -> Provider (consider adding default lists, either from history via other custom coin properties, or standard common ones, especially from more common exchanges fetching prices)

(e.g, if I'm to fetch prices from an exchange say, crex24, I can select it from Provider List and AM will populate the URL (except the Ticker Pair), HTTP method, JSON property expression to

Code:

[0].bid

(subjective, but as far as concerned, bidding price seems more popular to use than asking).

**

And for other properties such as Difficulty, Network Hash (running a local node), it'll be nice to have a history to pull as they all ended up having the same URL, POST body, and slightly different JSON property expression.


Not an urgently needed feature but would be handy (currently in process of adding GlobalToken and it's kinda pita with 60 odd supported algos less the ASIC ones, granted it's likely not profitable to mine it, rather it's able to be merge mined, but would like to keep it as option as well as other coins that uses mult-algos)

Best Regards,

Thanks for the suggestion - it's noted and I do see your point here.

[patrike]

Hey patrike,

Currently, I am using the latest version of Awesomeminer, and I added ZelCash (2miners) to the pool list. But in the pool options, ZelCash is under Equihash 144.5 not 125.4, and as the result if I select Equihash 144.5 for this coin, Gminer doesn't run at all. And if I select unspecified Equihash 125.4, it doesn’t show the current profit in the dashboard. Please help

Please take a look:
https://imgur.com/a/sMl2EYj

When I look in my system, ZEL is listed as Equihash 125.4 - both in the Coins tab and in the coin list in the Pool Properties.

Do you have any custom setting for this coin? Please go to the Options dialog, Coins section to verify that you don't have ZEL as a user defined coin. Also go to the Options dialog, Statistics Provider section, click Configure for "Override coin algorithms" and make sure it isn't listed here.

[patrike]

Im not sure how the dead device detection as sick works. I 'think' AM is rebooting my rigs without cause.

Awesome Miner uses the API data from the mining software to find out if the mining software considers a device to be dead/sick.

Could you please send me the API report (toolbar: Tools -> API Report) for this miner when it's in this state? Thanks!

Hey did some testing with the miner dev. The miner will declare the GPU as dead after testing it for 10-20 seconds, but AM will declare as Sick in the first signs of trouble.

Suggestions:

• AM logs could show which GPU(bus ID or something) went sick
• It would be preferable if AM could route the "Dead device detection" for TeamRedMiner via the miner commands

Code:

--watchdog_script=reboot.bat

where the reboot command could be stored in the reboot.bat.[/li]

These are just suggestions and not sure which is the optimal method.

My reasoning is : AM reboots on GPU death so soon that miner doesnt log the error(needed to debug the crash) and AM doesnt save in its own logs neither the GPU that crashed nor the API response on crash.
[/quote]
So the scenario is that the mining software report it as Sick over the API right away, but waits 10-20 seconds before taking action. Awesome Miner will simply look at what the mining software report and as soon as it see "Sick" or "Dead", the rule will take action right away.

Right now the device ID/Name is not made part of the notification, but I will at least make sure it's logged to the Awesome Miner log file when it happens so there is some way of knowing. In the next release it will be possible to see the Awesome Miner log file and search for "Dead device detection" to get more details.

Thanks for the feedback.

[patrike]

Awesome Miner version 6.8.3

 Awesome Miner Antminer S9 firmware
  - Automatically apply the firmware no matter if the Antminer has signature check or not
  - Configure AsicBoost and Full Reboot properties as part of setting the Mining Profile
  - Show AsicBoost status on the Pools tab for the selected miner
 Corrections
  - Correction to setting Mining Profile via Awesome Miner

[supersonic]

After loading AM S9 firmware i cannot see most pages for example status, update.. getting 404 error

[Lunga Chung]

After loading AM S9 firmware i cannot see most pages for example status, update.. getting 404 error

clear cash in browser

[supersonic]

yea worked, after mashing ctrl f5 couple times

[Lunga Chung]

yea worked, after mashing ctrl f5 couple times

Its a nice firmware with solid features, but don't expect much regarding performance. Latest Bitmain firmware does better regarding Ths/W (or at least mine S9 couldn't do better on this firmware)

@Patrik

I noticed that after reverting back to latest Bitmain firmware the consumption got higher on ELPM. Previously for S9 ELPM was 9.5Ths/760W now i get 9.5Ths/860W (this performance was also on vnish when mimicking ELPM). Can you check with developers of vnish what could possible be the reason for this?

[patrike]

yea worked, after mashing ctrl f5 couple times

Its a nice firmware with solid features, but don't expect much regarding performance. Latest Bitmain firmware does better regarding Ths/W (or at least mine S9 couldn't do better on this firmware)

@Patrik

I noticed that after reverting back to latest Bitmain firmware the consumption got higher on ELPM. Previously for S9 ELPM was 9.5Ths/760W now i get 9.5Ths/860W (this performance was also on vnish when mimicking ELPM). Can you check with developers of vnish what could possible be the reason for this?

Thanks for the feedback. Please note that before version 6.8.3 of Awesome Miner, the Mining Profile selection if made via Awesome Miner wasn't always correctly applied. If you use the latest Awesome Miner version or select the Mining Profile directly from the Antminer web interface it should work better.

The feedback I've received from other users is that they get to 14.7TH/s - 15.5TH/s on their S9 miners. In your case I assume your are looking for the lowest possible power usage and it might be that there are less room for improvements in that end.

When you use the Update firmware feature in Awesome Miner, it will do "Keep settings" as it's called in the web interface. Have you made a full reset of the settings when you are on the Bitmain firmware to make sure all custom properties in bmminer.conf are removed? Once your bmminer.conf is default the Bitmain firmware should perform exactly like before.

[Lunga Chung]

Thanks for the feedback. Please note that before version 6.8.3 of Awesome Miner, the Mining Profile selection if made via Awesome Miner wasn't always correctly applied. If you use the latest Awesome Miner version or select the Mining Profile directly from the Antminer web interface it should work better.

The feedback I've received from other users is that they get to 14.7TH/s - 15.5TH/s on their S9 miners. In your case I assume your are looking for the lowest possible power usage and it might be that there are less room for improvements in that end.

When you use the Update firmware feature in Awesome Miner, it will do "Keep settings" as it's called in the web interface. Have you made a full reset of the settings when you are on the Bitmain firmware to make sure all custom properties in bmminer.conf are removed? Once your bmminer.conf is default the Bitmain firmware should perform exactly like before.

I'm using the latest version.

Regarding consumption you are right it appears that there is very little room for improvement (hot summer trying to wer the heat as much as possible)

I did without keep settings option but no luck .....