Author

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

member
Activity: 277
Merit: 23
After loading AM S9 firmware i cannot see most pages for example status, update.. getting 404 error


clear cash in browser
full member
Activity: 195
Merit: 104
After loading AM S9 firmware i cannot see most pages for example status, update.. getting 404 error
legendary
Activity: 3346
Merit: 1094
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
legendary
Activity: 3346
Merit: 1094
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.
legendary
Activity: 3346
Merit: 1094
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.
legendary
Activity: 3346
Merit: 1094
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.
legendary
Activity: 3346
Merit: 1094
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.
member
Activity: 204
Merit: 10
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.
newbie
Activity: 24
Merit: 0
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
jr. member
Activity: 348
Merit: 5
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,
jr. member
Activity: 348
Merit: 5
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)
legendary
Activity: 3346
Merit: 1094
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
legendary
Activity: 3346
Merit: 1094
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:
Quote
[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:
Quote
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  Huh

Log from Remote Agent:
Quote
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!
legendary
Activity: 3346
Merit: 1094

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.
member
Activity: 204
Merit: 10
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:
Quote
[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:
Quote
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  Huh

Log from Remote Agent:
Quote
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 !!
member
Activity: 277
Merit: 23

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




legendary
Activity: 3346
Merit: 1094
Awesome Miner version 6.8.1

 Mining software
  - T-Rex Miner 0.13
  - CpuMiner-Opt 3.9.7
 Corrections
  - Correction to the display of total hashrate per algorithm for the new Nicehash platform
  - Correction to Remote Agent reporting Interface Offline for mining software under certain conditions
  - Correction to wallet balance feature for better detecting the correct balance property in API responses
  - Correction to profit switching when running the Awesome Miner Antminer S9 firmware
legendary
Activity: 3346
Merit: 1094
Awesome Miner shows exaggerated pool hashrates for new Nicehash stratums on Online Services tab, they should be at least ~100000x lower.
Thanks for reporting. I will correct this in the next release.
legendary
Activity: 3346
Merit: 1094
Hi Patrike,

I'm using Russian (vnish 3.8.6) of the custom S9 firmware you are offering in the last AwesomeMiner. I want to migrate to your version to support you, but don't want to lose all the setting/tuning I've already done. Is it possible and what is the best way to do it?

P.S. Uploaded your version of the firmware on one machine for testing. All the settings remained the same, but there is something wrong: Antminer keeps restarting every few minutes (the auto tuning part is not activated).
If you use the standard way of updating the firwmare, it will by default have "Keep settings" checked. If you use Awesome Miner to update the firmware, it will also use the "Keep settings". When I've been testing with firmware upgrades, this "Keep settings" have made sure that all settings and tuning are kept when you change the firmware. So the steps you taken sounds correct.

If you use the Upgrade firmware feature again to roll back to the exact firmware you were running before - is everything running stable at this point?

Could you please create a backup of your settings (on the Upgrade tab in the Antminer web interface) and send me this information via mail I can work out this with vnish. Thanks!
legendary
Activity: 3346
Merit: 1094
@Patrik

The AM S9 firmware (vnish) has a pretty precise consumption in logs and monitoring menu, would it be possible for AM to obtain this info directly from miner?

good job on the keystroke feature, this will help a lot
Yes, Awesome Miner can actually read the estimated power usage provided by the firmware API.

In Awesome Miner, please go to the Options dialog, Profitability section, and change "Power usage mode" to "Actual Usage". On new Awesome Miner installations this is the default, but on existing installations it's not. With "Actual Usage" you will get the power usage from the API of the miner instead of the power usage values you manually configured in Awesome Miner.

Thanks for the feedback on the keystroke feature as well!

Just set it up, couple of miners on the web monitor show 1260W on AM 1300W, the rest are in pair with the web monitor
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!
Jump to: