we got problem with our S15's
thats what is AM showing - temps looks good
thats what shows when i click on miner
and thats data from status page
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
The Chip Temperature should be higher than the PCB temperature and when looking at my S15 that's the case. I will have to investigate this a bit more. Can you please let me know which firmware version you are running? Thanks! |
|
|
|
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 ..... 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). |
|
|
|
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. |
|
|
|
|
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
|
|
|
|
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
--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. |
|
|
|
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/sMl2EYjWhen 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. |
|
|
|
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, Thanks for the suggestion - it's noted and I do see your point here. |
|
|
|
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. |
|
|
|
|
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
|
|
|
|
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! |
|
|
|
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. |
|
|
|
|
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
|
|
|
|
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. |
|
|
|
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! |
|
|
|
@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! |
|
|
|
Hello,
I'd like to swtich 300 miners S9i on latest official firmware "Working Mode" from normal to hashrate-unchanged - lower voltage. via the web custom command interface.
How would I do it since ssh is locked ?
thank you
With the standard Bitmain firmware, Awesome Miner doesn't have any feature to change the "Working mode" for different hashrate/power levels. As @nordmann666 and @Lunga Chung correctly pointed out, with the custom firmware for Antminers you can set multiple levels of hashrate/power modes and these can be set via Awesome Miner. More information: https://www.awesomeminer.com/antminerfirmwarePlease let me know if running the custom firmware would be an option for you. Otherwise I can plan for supporting the "Working mode" on Bitmain firmware in the future. If you need help to enable SSH access or disable the firmware signature check on your Antminers, just let me know and I will of course help out. Awesome Miner can do that on Antminer S9. |
|
|
|
@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! |
|
|
|
I have a Patrike doubt about the new power temperature system. The first thing I've noticed is that I get more hash. I use both power and core systems. I have the power one at 75 and the Core one at 76 degrees.
Using both systems, power should have more priority than Core.
In the interface I do not define a default power because if not all rigs would start with the same power, but then I see that you have to specify a minimum Power, right now in my case it is 70%.
My question is, I have a rig running at 85 power, when it reaches the target temperature that occurs.
1.- The power falls directly from 85 to 70 (I don't see it right)
2.- When you approach the target temperature, the power is gradually reduced, suppose the case of 5 in 5, which would be 85 is as it was, 80, 75 and finally 70.
The option that I commented is the two, because to make a fall from 85 to 70 it happens that the rig reaches 77 and suddenly falls to 72 degrees, then rises again to 75-77, then falls again.
I should have hysteresis. I don't know if that word exists in English. It is that the system acts a couple of degrees before dropping 5 a degree before the target, wait 30 seconds to see if temperature falls, if not, again lower it 5 degrees, etc. If after reaching the minimum defined by me, in this case 70, and if I have temperature activated also by the core, then at that time the core fall would be activated. OSea first give priority to see if the power drop produces the desired effect, and if you do not get it with my minimum, then pay attention to the Core drop, if defined in the OC.
It's a good job anyway, but I think it lacks this little detail that I tell you.
Thanks for testing out the new feature. It's a bit basic at the moment, but the idea was to give you something to try with to see if the concept is working. I didn't want to implement something too complex in case the entire concept of Power Limit control wasn't found useful. I fully understand your point about not making too frequent changes and not too large changes. Having multiple multiple temperature targets would also be an improvement. I will look into making some improvement here. Thanks for the feedback! It really works quite well, now I have the power temperature limit at 74 degrees and the core limit at 76 degrees. The only thing is that you didn't answer me. Is that if I have set a minimum of 70% and throw a miner at 85% power, if the power drops suddenly from 85 to 70, or it does so little by little and maybe the power stays for example at 75% in time of 70 because it already maintains the temperature. Really more hash is obtained by reducing power than Core, the only thing I ask is that the power reduction be gradual until the minimum marked. You don't have to hit the 85% jump I'm working at 70%. Going down in 3 or 5 point jumps would be great. Combine both systems, power and core already, you just have to give it two different temperatures, setting the core temperature higher in case the power reduction is not enough. It has certainly been a success. The only thing that worries me, is when I gradually lower the power do it every 10 seconds or so, I do not continue fast because it can destabilize the Rig. If for a few moments it exceeds 76 degrees, the core system works, which then cancels itself when the temperature drops again and the power continues to drop to the minimum point I have set. It would only be going down little by little and with 10-second jumps between them so as not to destabilize the rig, and for me it would already be perfect and leave the problem of forgotten heat, in fact heat is no longer a problem for me nor does it take double oc or anything Both systems simultaneously control the temperature excellently, my congratulations. The Power Limit will not change in small steps. It can drop from 85 to 70 right away. I did however introduce two improvments in version 6.8 compared to the development release. You can now define two pair of temperature and power limits instead of one. This makes it possible to define one temperature where the Power Limit should drop to 75% and another temperature where it should drop to 70%. It can make the adjustments a bit smoother. The latest version also uses a 30 second concept where changes will never be applied more often than 30 seconds - to reduce too frequent changes as you had in the development release. |
|
|
|
Awesome Miner version 6.8 Awesome Miner Antminer S9 firmware - Better performance and flexible hashrate and power configuration when mining with Antminer S9 - Integrates with Awesome Miner by providing: LED flash, pause and resume mining in a power efficient way, antivirus scan and apply mining profiles (hashrate and power usage). - The features are available via the ASIC tools menu and as rule actions in Awesome Miner - Display of power usage - SSH access to the Antminer - Mining fee 2% - Awesome Miner can install this firmware even when the Antminer is locked with signature check and SSH is disabled (contact us for instructions) - For more information, see the web site: https://www.awesomeminer.com/antminerfirmware ASIC mining - Antminer S15/T15 power mode configuration GPU mining - GPU power limit control based on temperature, configurable in the Options dialog, GPU Settings section Features - Keystrokes can be sent to mining software via the Console tab and also via the rule actons (Configurable via the Miner Command action) - Miner highlight feature includes 5 additional colors - Configurable if a double click on an External Miner should open the ASIC miner web interface. Configurable via the Options dialog, General section. - Improved wallet balance feature to handle more data formats User interface - Antminer&ASIC menu renamed to ASIC tools - Temperature sorting improved for miner list in compact mode Mining software - XmRig CPU 2.99.3 beta incl. RandomXL - XmRig AMD 2.14.5 - CpuMiner-Opt 3.9.6.2 - Phoenix MIner 4.5c - Phoenix Miner integration improved to display share information per GPU - Nanominer 1.5.3 - Nanominer integration updated for RandomHash algorithm - Bminer 15.7.6 - CcMiner Zcoin Official 1.1.26 - Z-enemy miner 2.1
|
|
|
|
This bug is pissing me off to no end but I have no idea where the fault is..
You can see below, the first entry is not show temps, accepts, or hashrate. This effects reports, rules, etc, everything. BUT. The miner is working fine! If I click the console command tab everything is happy, it is running fine.
I will investigate and get back to you. |
|
|
|
|
Show Posts
