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

New CryptoDredge 0.21 https://github.com/technobyl/CryptoDredge/releases

New T-Rex 0.13.2  https://github.com/trexminer/T-Rex/releases

Thanks in advance

we got problem with our S15's

thats what is AM showing - temps looks good
https://i.imgur.com/uBoeNBt.png
thats what shows when i click on miner
https://i.imgur.com/X5hSKWW.png

and thats data from status page
https://i.imgur.com/24Me4LL.png

and thats on all S15, reality is that temp is much higher and couple of them shut off due to overheat when i thought all was good

ok it works now, thx for suggestion

Yes the wall shows the same on both firmwares

All miners have the same profile set now, I'll SSH to clean the config file manually

Thanks for the update. Do you measure the power usage at the wall?

For Bitmain firmware, Awesome Miner doesn't have any way to display the actual power usage - it's only based on what you have entered in your profiles in Awesome Miner. For the Awesome Miner Antminer firmware, the firmware can report a decent estimate of the actual power usage (if you have configured "Actual usage" in the Options dialog, Profitability section).

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 .....





 

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.

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?

yea worked, after mashing ctrl f5 couple times

clear cash in browser

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

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

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.

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.

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

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.

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

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.

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

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 (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,

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)