Author

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

member
Activity: 277
Merit: 23
@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
jr. member
Activity: 756
Merit: 2
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.
legendary
Activity: 3346
Merit: 1094
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
legendary
Activity: 3346
Merit: 1094
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.
hero member
Activity: 1151
Merit: 528
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.


Remote Miner Logs and AM Recent Logs: https://drive.google.com/open?id=18IJGZKAh8Lt0CnSoCWDYjWelbeOoi_py
legendary
Activity: 3346
Merit: 1094
So after using this software for so many years you'd think I'd know the answer to this.. is there a way to unset a miner highlight after a rule/error is cleared?

For example, if miner does not increase accept progress in 8 minutes it is highlighted yellow. If that then ends up increasing, the miner is rebooted, or the notification is cleared, I would want that highlight to be cleared.
BUT
I don't want a blanket rule to clear all highlights.. because other highlights might still apply.. I only want to unset the yellow highlight if the accept increases.. does this make sense? Is this possible?
I fully understand your question and what you are looking for.

There are unfortunately no perfect solution to this, but what you could try out is to add a trigger called "Detect miner API connection established" and then use an action to set the Highlight back to "None". It's not a complete solution for what you are asking for, but if the miner is rebooted and then started again, this rule could at least remove the highlight once the miner is up and running again.
legendary
Activity: 3346
Merit: 1094
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!
legendary
Activity: 3346
Merit: 1094
Awesome Miner version 6.7.4 ( Development preview of 6.8 )

 ASIC mining
  - Antminer S15/T15 power mode configuration
 Features
  - Keystrokes can be sent to mining software via the rule actons. Configurable via the Miner Command action.
 Mining software
  - CpuMiner-Opt 3.9.6.2
  - Phoenix Miner integration improved to display share information per GPU
  - Nanominer integration updated for RandomHash algorithm

Can the keystrokes be sent without rules ? like from a menu in the console tab?
I will add it to the Console tab in the next release.
legendary
Activity: 3346
Merit: 1094
When you added the nheqminer, did you add it via the Options dialog, Managed Software section, and configured it with Command Line as compatibility mode? In that case Awesome Miner shouldn't try the API and should understand that it cannot get hashrate/share information.

Yes, I added nheqminer in compatibility mode (EWBF CUDA Zcash Miner) and added additional command line arguments in profit profile properties:
-v -l mine.zergpool.com:3300 -u BTCaddress -t 7 -a 4029 -p c=BTC,ID=NAME
Thanks for the details. The Compatibility Mode provides several options. Have you tried using "None"?
hero member
Activity: 1151
Merit: 528
So after using this software for so many years you'd think I'd know the answer to this.. is there a way to unset a miner highlight after a rule/error is cleared?

For example, if miner does not increase accept progress in 8 minutes it is highlighted yellow. If that then ends up increasing, the miner is rebooted, or the notification is cleared, I would want that highlight to be cleared.
BUT
I don't want a blanket rule to clear all highlights.. because other highlights might still apply.. I only want to unset the yellow highlight if the accept increases.. does this make sense? Is this possible?
jr. member
Activity: 756
Merit: 2
Testing Beta feature "Enable GPU global power limit":

setting Default power limit 80%, overrides the GPU clocking profile when starting, so all GPU clocking now starts at 80%.

Then try Disable Global power limit and the GPU start profile works again.

I would like to have option to set Default power limit for the normal GPU clocking profile when starting since the my RTX 2060
always starts at 100% no matter what.
The new power limit control is a feature is on a global level, so setting the default power to 80%, it will be 80% all the time unless your temperature condition indicates something else.

When you define your Clocking Profile, Power Limit is one of the properties. If you set this one to 90%, isn't that applied for your RTX 2060 GPU?

Yes my Clocking Profile Power Limit normally gets set, but if the Power Limit does not get applied like in the case of my RTX 2060, Then the _Default_ Power Limit value of 100%  is applied.

 This setting  would need to be Added to the Clocking Profile Properties in Edit - Clocking Profiles :
Property - Default Power Limit (%) ....not the Power Limit (%)
Value - (%)

This acts as a fail safe value (like the Global power limit but only for my RTX 2060 profile)  in case the Clocking Profile fails.
Thanks for the update. So this specific RTX2060 is not applying the Power Limit property correctly - but it works for all other GPUs? Is it working if you manually apply it via the clocking dialog? Is it never applied correctly when being part of a Clocking Profile?

Based on your description it sounds like the new Power Limit control feature was able to set the Power Limit correctly for this GPU - but this feature is setting the same Power Limit property as when you manually apply it or set it via a Clocking Profile.

The Power Limit control feature is intended to dynamically adjust the Power Limit based on GPU temperature and it's not at all related to the clocking profiles.

I am 2080 and it works well for me, what is strange to me is that I do not see the power changes in GPU clocking while mine.

What should not be done is to establish a general Power for all rigs from the option there is, I have it unchecked and I use a custom OC, with its Power, core, and mem. But if I set the lowest limit where the power can fall, in my case up to 70%

Either I haven't noticed or it doesn't happen to me. but now I get more hash than just dropping the core. Although I use both systems, power at 75 degrees and Core at 76 or 77 as a second barrier because of something, and then another rule in case it reaches 82 to stop the miner.
jr. member
Activity: 756
Merit: 2
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.
full member
Activity: 1148
Merit: 132
When will you be adding random xl for Loki
Is it a fork and change of algorithm for this coin?
https://www.coincalculators.io/coin/loki

It looks like XmRig will support this one. I will look into it.

Update: It's supported by XmRig 2.99 but this one introduces command line and API changes as well. For this reason I cannot push the update yet - but I will add support for it within the next few days.

awseomse @patrike thanks , this is important because in October XMR is forking to the same algo
member
Activity: 204
Merit: 10
Awesome Miner version 6.7.4 ( Development preview of 6.8 )

 ASIC mining
  - Antminer S15/T15 power mode configuration
 Features
  - Keystrokes can be sent to mining software via the rule actons. Configurable via the Miner Command action.
 Mining software
  - CpuMiner-Opt 3.9.6.2
  - Phoenix Miner integration improved to display share information per GPU
  - Nanominer integration updated for RandomHash algorithm

Can the keystrokes be sent without rules ? like from a menu in the console tab?
newbie
Activity: 21
Merit: 0
When you added the nheqminer, did you add it via the Options dialog, Managed Software section, and configured it with Command Line as compatibility mode? In that case Awesome Miner shouldn't try the API and should understand that it cannot get hashrate/share information.

Yes, I added nheqminer in compatibility mode (EWBF CUDA Zcash Miner) and added additional command line arguments in profit profile properties:
-v -l mine.zergpool.com:3300 -u BTCaddress -t 7 -a 4029 -p c=BTC,ID=NAME
newbie
Activity: 21
Merit: 0
legendary
Activity: 3346
Merit: 1094
Awesome Miner version 6.7.4 ( Development preview of 6.8 )

 ASIC mining
  - Antminer S15/T15 power mode configuration
 Features
  - Keystrokes can be sent to mining software via the rule actons. Configurable via the Miner Command action.
 Mining software
  - CpuMiner-Opt 3.9.6.2
  - Phoenix Miner integration improved to display share information per GPU
  - Nanominer integration updated for RandomHash algorithm
legendary
Activity: 3346
Merit: 1094
When will you be adding random xl for Loki
Is it a fork and change of algorithm for this coin?
https://www.coincalculators.io/coin/loki

It looks like XmRig will support this one. I will look into it.

Update: It's supported by XmRig 2.99 but this one introduces command line and API changes as well. For this reason I cannot push the update yet - but I will add support for it within the next few days.
legendary
Activity: 3346
Merit: 1094
Testing Beta feature "Enable GPU global power limit":

setting Default power limit 80%, overrides the GPU clocking profile when starting, so all GPU clocking now starts at 80%.

Then try Disable Global power limit and the GPU start profile works again.

I would like to have option to set Default power limit for the normal GPU clocking profile when starting since the my RTX 2060
always starts at 100% no matter what.
The new power limit control is a feature is on a global level, so setting the default power to 80%, it will be 80% all the time unless your temperature condition indicates something else.

When you define your Clocking Profile, Power Limit is one of the properties. If you set this one to 90%, isn't that applied for your RTX 2060 GPU?

Yes my Clocking Profile Power Limit normally gets set, but if the Power Limit does not get applied like in the case of my RTX 2060, Then the _Default_ Power Limit value of 100%  is applied.

 This setting  would need to be Added to the Clocking Profile Properties in Edit - Clocking Profiles :
Property - Default Power Limit (%) ....not the Power Limit (%)
Value - (%)

This acts as a fail safe value (like the Global power limit but only for my RTX 2060 profile)  in case the Clocking Profile fails.
Thanks for the update. So this specific RTX2060 is not applying the Power Limit property correctly - but it works for all other GPUs? Is it working if you manually apply it via the clocking dialog? Is it never applied correctly when being part of a Clocking Profile?

Based on your description it sounds like the new Power Limit control feature was able to set the Power Limit correctly for this GPU - but this feature is setting the same Power Limit property as when you manually apply it or set it via a Clocking Profile.

The Power Limit control feature is intended to dynamically adjust the Power Limit based on GPU temperature and it's not at all related to the clocking profiles.
full member
Activity: 1148
Merit: 132
When will you be adding random xl for Loki
Jump to: