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

I noticed that we read the chip temperatures on Whatsminer, something we do for many other ASIC miners. Please allow me to look into this for the next release.

Chip temperature colors are configured in the Options dialog, Appearance section. Once we read the chip temperature for Whatsminer, you can use it to configure the colors.

Thanks for the update. So it could simply be that when it looked like Awesome Miner "waits prior to doing any actions" - it was simply too much load on the computer that made things run slower than usual. I don't think there are any general issues with the variable action in combination with wait actions.

What is the initialization time for the GPU miner?
Is it possible to increase it in the settings?
I have a problem.
RIG for 10 video cards and 10 miners with their own profit profiles, Linux.
The problem only appears on SRB-MINER on cards and AMD and NVIDIA on the DNX coin
This coin has a much longer initialization time.
Miners, without waiting for initialization, restart the process. And so it goes cyclically.
With 10 miners on onezerrominer - and other coins - everything is fine.
I change to SRB-MINER on two video cards - cyclic restart.
I run 10 processes in 10 consoles - everything is OK

is there any way to change the default temp that is displayed on dashboard for asics?

for whatsminers "Chip Temp Max":" <- this is what i want to see as temp and is it also possible to change the colours at temp x? i mean...85°C for example is in green area for whatsminers...95°C maybe yellow and red should start at 105°C

Seems like a race condition that fails under heavy load, the kind of problem that can cause spacecraft to crash on Mars:

https://www.cs.cornell.edu/courses/cs614/1999sp/papers/pathfinder.html

Have fun reproducing it.

Number 2 seems like an acceptible workaround:
https://www.guidingtech.com/top-ways-to-change-priority-level-for-programs-on-windows-10-and-windows-11/

You might also want to avoid running AM on a heavily loaded system. It had to be said.

Wanted to make sure I had this figured out. It looks like AM doesn't always function correctly and things are delayed or possibly aren't executed on systems that are heavily overloaded. The computer it was on was around 80-90% CPU utilization. Setting AM to high priority fixed this and haven't had a issue since doing this. I believe this issue can be duplicated by overloading the work system.

Could a option be added to run AM as high priority on startup (or whatever the person wants)?

There is a new mining software definition update available now, where Octopus dual mining is supported for Rigel.

Dual Mining options for Rigel Octopus+ second doesn´t work. Only the first coin is in the commandline, the second is ignored.
If i add the parameters for the second coin to the commandline, AM use this parameters and override the first pool, so the same problem like in the past.

I setup a normal pool and i wrote this in the commandline

-a octopus+alephium [2]stratum+tcp://de.alephium.herominers.com:1199 -u [2]xxxxxxx.worker -p [2]x

this is the result:

 -a octopus+alephium [2]stratum+tcp://de.alephium.herominers.com:1199 -u [2]xxxxxxx.worker -p [2]x -o stratum+tcp://pool.eu.woolypooly.com:3094 --api-bind 0.0.0.0:4028  --no-watchdog

complete random commandline  this belongs to all combinations with octopus

Awesome Miner version 9.10.7

 Awesome Miner Antminer firmware
  - Added mining profiles for Awesome Miner firmware, Antminer S19 (126 chip)
 Mining software
  - BzMiner 17.0.0
  - OneZero Miner 1.2.5
  - Rigel 1.9.0
  - SrbMiner-Multi 2.3.6
 Changes
  - Improve predefined rules to have action limits by default
 Corrections
  - Correction to hash rate display for Whatsminer and Antminers running BraiinsOS

Thanks for your report. Unfortunately you are correct. There is an issue where the Whatsminer and Antminers running BraiinsOS doesn't show the hashrate correctly.

For Whatsminer you do see what they report as the 5 second average hash rate - but we shouldn't use that one because it's typically too high. Instead, Awesome Miner should go for the 1 minute average hash rate as it's the more relalistic value reported.

There will be a new version available during the day to correct this issue. Sorry for any inconvenience.

new version bugged with Whatsminer reported hashrate

Version: 9.10.6 (100)
API command: config
{
  "STATUS": "E",
  "When": 1696097646,
  "Code": 14,
  "Msg": "invalid cmd",
  "Description": ""
}
API command: summary
{
  "STATUS": [
    {
      "STATUS": "S",
      "Msg": "Summary"
    }
  ],
  "SUMMARY": [
    {
      "Elapsed": 36997,
      "MHS av": 84288937.23,
      "MHS 5s": 101535086.89,
      "MHS 1m": 84094103.34,
      "MHS 5m": 84277031.0,
      "MHS 15m": 84293775.86,
      "HS RT": 84277031.0,
      "Accepted": 1313,
      "Rejected": 0,
      "Total MH": 3118448944256.0,
      "Temperature": 46.75,
      "freq_avg": 715,
      "Fan Speed In": 0,
      "Fan Speed Out": 0,
      "Power": 3205,
      "Power Rate": 38.03,
      "Pool Rejected%": 0.0,
      "Pool Stale%": 0.0,
      "Uptime": 37399,
      "Hash Stable": true,
      "Hash Stable Cost Seconds": 374,
      "Hash Deviation%": 0.0222,
      "Target Freq": 706,
      "Target MHS": 84083190.0,
      "Env Temp": 50.5,
      "Power Mode": "Normal",
      "Factory GHS": 87951,
      "Power Limit": 3200,
      "Chip Temp Min": 63.0,
      "Chip Temp Max": 81.9,
      "Chip Temp Avg": 73.5,
      "Debug": "",
      "Btminer Fast Boot": "disable",
      "Upfreq Complete": 1
    }
  ],
  "id": 1
}
API command: privileged
{
  "STATUS": "E",
  "When": 1696097646,
  "Code": 14,
  "Msg": "invalid cmd",
  "Description": ""
}
API command: edevs
{
  "STATUS": [
    {
      "STATUS": "S",
      "Msg": "3 ASC(s)"
    }
  ],
  "DEVS": [
    {
      "ASC": 0,
      "Slot": 0,
      "Enabled": "Y",
      "Status": "Alive",
      "Temperature": 46.75,
      "Chip Frequency": 722,
      "MHS av": 28296777.73,
      "MHS 5s": 28166125.1,
      "MHS 1m": 28284638.58,
      "MHS 5m": 28362602.76,
      "MHS 15m": 28334921.29,
      "HS RT": 28362602.76,
      "Factory GHS": 29367,
      "Upfreq Complete": 1,
      "Effective Chips": 105,
      "PCB SN": "xxxxxxxxxxxxxxxx",
      "Chip Data": "xxxxxxxxxxxxxxxx",
      "Chip Temp Min": 63.9,
      "Chip Temp Max": 82.1,
      "Chip Temp Avg": 73.74,
      "chip_vol_diff": 10
    },
    {
      "ASC": 1,
      "Slot": 1,
      "Enabled": "Y",
      "Status": "Alive",
      "Temperature": 46.38,
      "Chip Frequency": 713,
      "MHS av": 28052366.5,
      "MHS 5s": 28121470.13,
      "MHS 1m": 28009448.47,
      "MHS 5m": 28052641.79,
      "MHS 15m": 28050671.15,
      "HS RT": 28052641.79,
      "Factory GHS": 29221,
      "Upfreq Complete": 1,
      "Effective Chips": 105,
      "PCB SN": "xxxxxxxxxxxxxx",
      "Chip Data": "xxxxxxxxxxxxx",
      "Chip Temp Min": 63.9,
      "Chip Temp Max": 81.9,
      "Chip Temp Avg": 73.53,
      "chip_vol_diff": 10
    },
    {
      "ASC": 2,
      "Slot": 2,
      "Enabled": "Y",
      "Status": "Alive",
      "Temperature": 46.12,
      "Chip Frequency": 711,
      "MHS av": 27938742.06,
      "MHS 5s": 28178201.74,
      "MHS 1m": 27888920.82,
      "MHS 5m": 27861786.45,
      "MHS 15m": 27908183.42,
      "HS RT": 27861786.45,
      "Factory GHS": 29363,
      "Upfreq Complete": 1,
      "Effective Chips": 105,
      "PCB SN": "xxxxxxxxxxxxxx",
      "Chip Data": "xxxxxxxxxxxxxxx",
      "Chip Temp Min": 63.0,
      "Chip Temp Max": 81.6,
      "Chip Temp Avg": 73.25,
      "chip_vol_diff": 10
    }
  ],
  "id": 1
}
API command: pools
{
  "STATUS": [
    {
      "STATUS": "S",
      "Msg": "1 Pool(s)"
    }
  ],
  "POOLS": [
    {
      "POOL": 1,
      "URL": "xxxxxxxxxxxxxxxx",
      "Status": "Alive",
      "Priority": 0,
      "Quota": 1,
      "Getworks": 3424,
      "Accepted": 1313,
      "Rejected": 0,
      "Works": 0,
      "Discarded": 0,
      "Stale": 0,
      "Get Failures": 0,
      "Remote Failures": 0,
      "User": "norman666.191968",
      "Last Share Time": 1696097587,
      "Stratum Active": true,
      "Stratum Difficulty": 524288.0,
      "Pool Rejected%": 0.0,
      "Pool Stale%": 0.0,
      "Bad Work": 62,
      "Current Block Height": 0,
      "Current Block Version": 536870916,
      "To Remove": false
    }
  ],
  "id": 1
}
API command: coin
{
  "STATUS": "E",
  "When": 1696097646,
  "Code": 14,
  "Msg": "invalid cmd",
  "Description": ""
}
API command: stats
{
  "STATUS": "E",
  "When": 1696097646,
  "Code": 14,
  "Msg": "invalid cmd",
  "Description": ""
}
API command: devdetails
{
  "STATUS": [
    {
      "STATUS": "S",
      "Msg": "Device Details"
    }
  ],
  "DEVDETAILS": [
    {
      "DEVDETAILS": 0,
      "Name": "SM",
      "ID": 0,
      "Driver": "bitmicro",
      "Kernel": "",
      "Model": "M30SVE10"
    },
    {
      "DEVDETAILS": 1,
      "Name": "SM",
      "ID": 1,
      "Driver": "bitmicro",
      "Kernel": "",
      "Model": "M30SVE10"
    },
    {
      "DEVDETAILS": 2,
      "Name": "SM",
      "ID": 2,
      "Driver": "bitmicro",
      "Kernel": "",
      "Model": "M30SVE10"
    }
  ],
  "id": 1
}

Awesome Miner version 9.10.6

 Awesome Miner Antminer firmware
  - Include a few missing firmware configuration properties in Awesome Miner
 ASIC mining
  - Added support for DesiweMiner K10 Pro
  - Improve integration with IceRiver KS0
 Mining software
  - CpuMiner-Opt 2.23.3
  - Rigel 1.8.1
  - TT-Miner 2023.4.1
  - TeamBlackMiner 2.01

Thanks for your report. I've been trying to reproduce this without success. What I tried is the following as actions:
Set global variable value: 1
Wait 10 s
Set global variable value: 3
Wait 10 s
Set global variable value: 5

When I trigger this rule I can look at the global variable and see that it changes to 1, then 3 and finally to 5 - just as expected.

Hey Patrike, running into some weird issues with Rules > Action > Wait. It seems like it doesn't trigger the first action and WAIT based on where it is in the list, it instead WAITs prior to doing any actions, at least with changing variables.

Awesome Miner version 9.10.5

 Awesome Miner Antminer firmware
  - Added support for S19 Hydro
 ASIC mining
  - Improve support for Antminers running custom firmware
 Mining software
  - OneZero Miner 1.2.4
  - TT-miner 2023.4.0
 Corrections
  - Correction to hashrate display for individual hash boards for Antminer L7 running the Awesome Miner Antminer firmware

Awesome Miner version 9.10.4

 Awesome Miner Antminer firmware
  - Added support for more Antminer S19 variations
 ASIC mining
  - Improved integration with Auradine Teraflux ASIC miners, with support for firmware updates and hashrate configuration
 Features
  - Improved C# scripting to allow putting ASIC miners into low power mode
 Changes
  - Removed MagicPool
 Mining software
  - BzMIner 16.0.5
  - CpuMiner-Opt 3.23.0
  - Rigel 1.7.2
  - SrbMiner-Multi 2.3.5
  - TeamBlackMiner 1.99

Thanks for the feedback. Magicpool will be removed in the next release and I will consider the one you linked to.

The software definitions has been updated to fully include EthashB3.

Magicpool shutting down tomorrow, please delete from online services. Can you add https://richpool.pro/ instead of magicpool?

EthashB3 also missing and can you correct the dual mine options for EthashB3 + xxx (rigel, srbminer, bzminer). I added Ethb3 by myself, but the dual mine options doesn´t work. AM doesn´t add the parameters for the second algo.

I'm not sure what was communicated or declined here but it could be that someone at their support channel didn't like certain links to be posted. Anyway - all I stated in my previous post is fully correct so anyone that want to use Awesome Miner to easily deploy our firmware to their S19 miners can do so.

vnish telegram support declined this and i got kicked after i post what u wrote here...