[Awesome Miner] - Powerful Windows GUI to manage and monitor up to 200000 miners - page 176.

trucobit

jr. member

Activity: 756

Merit: 2

Quote from: patrike on May 02, 2019, 05:45:56 AM

Version 6.3.5 (Development preview of 6.4)
Features
  - New trigger for GPU power usage
  - Native overclocking feature includes support for setting voltage limit for nVidia and memory voltage for AMD
Integration
  - Added additional Mining Pool Hub pools and made the API processing more robust
  - Added more algorithms for the WhatToMine integration
  - Allow change of the pool ports for the predefined online services
Mining software
  - Miniz Miner 1.3n3
  - SrbMiner 1.8.7
  - Bminer 15.2.2
  - Gminer 1.40
  - TeamRedMiner 0.4.5
  - Nanominer 1.2.4
Corrections
  - Correction to the caching for the dynamic update of coin properties
  - Correction to Claymore Ethereum miner API processing
  - Correction to coins per day calculation for the profit switcher when using the network hashrate formula in combination with a low network hashrate

To get access to development versions, open the Options dialog in Awesome Miner. In the General section, enable Check for development versions. Then go to the Menu and click Check for updates.

Direct download links if needed:
https://www.awesomeminer.com/download/setupdev/AwesomeMiner.msi
https://www.awesomeminer.com/download/setupdev/AwesomeMinerRemoteService.msi

Good update, a suggestion.

I could add edit BULK in all the OC profiles or in the selected ones. I have more than 100 and if I have to put or remove automatic fan, I have to go one by one. If I have to change the voltage at 30, I have to go one by one.

Now the power to modify the voltage will surely amplify my OC profiles much more, it is not the same for all the 1080ti, that the 1070 or 1060 are not equal in voltage issue. For that, a Bulk option helps to go faster in the OC profile editing

GKumaran

member

Activity: 204

Merit: 10

Quote from: patrike on May 02, 2019, 05:43:58 AM

Quote from: GKumaran on May 02, 2019, 05:18:18 AM

DLL detected by AV as virus inside the %temp% folder.
The miner is not used for mining in this pc, it is used to monitor another remote node.

Im ok with exlcuding a folder in AV for awesome miner, but y is this in the %temp% path?

Dll list:

ehokahrd.dll
cz1kbcwg.dll
veochfjs.dll
2dssckxt.dll
jjncdwlh.dll
cygfd1rd.dll

All files detected as RiskTool.MSIL.BitcoinMiner.gen and are shown to be in use by awesome miner.

It's quite common for security software to give warnings about mining related tools.

Awesome Miner is downloading mining software to %appdata%\AwesomeMinerService or %localappdata%\AwesomeMiner. These two folders can be added as exceptions.

Awesome Miner also uses dynamic C# scripting, for example for the dynamic update of coin properties. This scripting feature may result in small dll-files being automatically generated in the temp-folder so it might be those files you see here. These files are however not at all related to mining and this is the first time I get a report that security software would flag these files.

I can investigate if the auto generation could be made to a different folder as well.

Thx dude !!
I'm ok with marking awesome miner specific folders

Currently exlcuded:
Install location
Appdata

Now that you mention dynamic coin prop update it did pop up after i re-configured some coins for incorrect data a few days back. Never has the report for last 1 year.
Would be nice to have those dll in a safe to exlcude folder. Excluding the %temp% seems like a surefire way to get hit by virus !!

patrike

legendary

Activity: 3346

Merit: 1094

Version 6.3.5 (Development preview of 6.4)
Features
  - New trigger for GPU power usage
  - Native overclocking feature includes support for setting voltage limit for nVidia and memory voltage for AMD
Integration
  - Added additional Mining Pool Hub pools and made the API processing more robust
  - Added more algorithms for the WhatToMine integration
  - Allow change of the pool ports for the predefined online services
Mining software
  - Miniz Miner 1.3n3
  - SrbMiner 1.8.7
  - Bminer 15.2.2
  - Gminer 1.40
  - TeamRedMiner 0.4.5
  - Nanominer 1.2.4
Corrections
  - Correction to the caching for the dynamic update of coin properties
  - Correction to Claymore Ethereum miner API processing
  - Correction to coins per day calculation for the profit switcher when using the network hashrate formula in combination with a low network hashrate

To get access to development versions, open the Options dialog in Awesome Miner. In the General section, enable Check for development versions. Then go to the Menu and click Check for updates.

Direct download links if needed:
https://www.awesomeminer.com/download/setupdev/AwesomeMiner.msi
https://www.awesomeminer.com/download/setupdev/AwesomeMinerRemoteService.msi

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: GKumaran on May 02, 2019, 05:18:18 AM

DLL detected by AV as virus inside the %temp% folder.
The miner is not used for mining in this pc, it is used to monitor another remote node.

Im ok with exlcuding a folder in AV for awesome miner, but y is this in the %temp% path?

Dll list:

ehokahrd.dll
cz1kbcwg.dll
veochfjs.dll
2dssckxt.dll
jjncdwlh.dll
cygfd1rd.dll

All files detected as RiskTool.MSIL.BitcoinMiner.gen and are shown to be in use by awesome miner.

It's quite common for security software to give warnings about mining related tools.

Awesome Miner is downloading mining software to %appdata%\AwesomeMinerService or %localappdata%\AwesomeMiner. These two folders can be added as exceptions.

Awesome Miner also uses dynamic C# scripting, for example for the dynamic update of coin properties. This scripting feature may result in small dll-files being automatically generated in the temp-folder so it might be those files you see here. These files are however not at all related to mining and this is the first time I get a report that security software would flag these files.

I can investigate if the auto generation could be made to a different folder as well.

GKumaran

member

Activity: 204

Merit: 10

DLL detected by AV as virus inside the %temp% folder.
The miner is not used for mining in this pc, it is used to monitor another remote node.

Im ok with exlcuding a folder in AV for awesome miner, but y is this in the %temp% path?

Dll list:

ehokahrd.dll
cz1kbcwg.dll
veochfjs.dll
2dssckxt.dll
jjncdwlh.dll
cygfd1rd.dll

All files detected as RiskTool.MSIL.BitcoinMiner.gen and are shown to be in use by awesome miner.

Siolim

newbie

Activity: 107

Merit: 0

Quote from: patrike on May 01, 2019, 01:03:40 AM

Quote from: Siolim on April 30, 2019, 06:55:04 AM

Hi Patricke.
Tell me, please, is it possible to connect a miner without adding a line - no-watchdog? Some miners do not understand this version (for example https://github.com/xaya/ccminer/releases/tag/v0.1)

Thank you for the wonderful work.

Thanks for your nice feedback!

This command line (--no-watchdog) is only added automatically for software based on CryptoDredge. Please try to select CcMiner instead and it shouldn't be added.

Hello
Everything works. Thank you.

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: trucobit on April 30, 2019, 05:21:09 PM

Quote from: patrike on April 30, 2019, 04:41:56 AM

Quote from: trucobit on April 30, 2019, 02:29:14 AM

Quote from: trucobit on April 29, 2019, 07:48:03 AM

At the moment this problem of the OC and temperatures is causing me great problems. there are already two RIGs, the rig of the RTX there is a card, which is more in the background that even reaches 87 and turn off the miner in security.

But I start observing the FAns in GPU, and I see that suddenly I'm at 84 and fans are lowered to 65% because it has picked up the temperature of another card, according to my rules at 84 degrees it would go to 90% fan, and repende is lowered to 65%, because that card reaches the maximum temperature of 87 and turns off the miner.

I hope you have a solution or I will have to drive MSI aftherburner again. But I really like this native solution. You should only take the value of the hottest card in the RIG and do not go changing card reading

At the same time I'm going to have to leave the fixed fans something I do not want, but of course it's a big mistake that I take the temperature data from different cards, so it can not be efficient.

Please, if you are not going to fix it, tell me already and I will change to the old system with Aftherburner or a fixed fan.

One of the two is wrong. Right now, like this one, you do not look at just one card, you look at all of them. Then a card, the hottest one that should be sent, is activated at 90% fan at 80 degrees, but now it turns out that another card of the same rig reaches 75 degrees and I lower the fans to 70% .. Is it more important to reduce 75 degrees or reduce 80 degrees?

Therefore the concept of temperature for a rig, should take into account only 1 card, the hottest. Because the change of speed is applied to ALL THE RIG. If the speed of the fans was independent by card, his vision would be accurate, but as it is not so, it is wrong.

I suppose I could use Atherburner only for the fans, its solution to put rules that jump at different temperatures is not valid. It can not be that I have a card at 84 degrees that would correspond to 100% of FAN, and suddenly because another card of the rig reaches 75 degrees, I lower all the rig to 75% of Fan. Obviously the card that is in 84 degrees will rise and to 86 I turn the miner to avoid problems of breakage by temperature.

Here there are only 3 solutions:

1- that the rules affect each card independently, it would be very good.

2 - Always take the value of the hottest card, this would be the optimal point, that always in the rules send the FAN the card with the highest temperature. This would be the best solution and faster in programming.

3.- re-use Aftherbuner at the same time as the native, only to control the fans.

You understand that as it is now, even with rules, if I have not activated the heat protection rule, I could have damaged cards. I like your native OC a lot, but the temperature should send the card with more heat, whatever it is inside the rig, and just follow that. If suddenly another card in the same rig exceeds the previous one in temperature, then that new card is the one that would take control of the entire RIG. TAl as it is now, yesterday I skipped the rigs every few minutes and they stopped. I could not give credit to my eyes, to see cards at 84 degrees to 100% and suddenly went down to 65% because another card had reached the goal of a rule and applied to the whole rig, that does not matter as you explain it But it's not good.

You give a greater control of fan as aftherburner or you guide by the card of more temperature of the rig, because if not, cards of those people who do not have rules of stopping the miner can be broken if it reaches 86 degrees as I have.

This kind of situations did not happen with the complete solution of aftherburner, although the connection with the main program is very bad, so I will use the native and I will see that I think so, use a fan speed curve in aftherburner, but this is already ahead of time It will be a problem for many as soon as the heat arrives.

The Device Temperature trigger is currently looking for the GPU with the highest temperature. If your trigger condition is 80 degrees, it will trigger as soon one of the GPU's hit this level. Any action will be performed on the miner itself.

If you have multiple Device Temperature triggers and two of them have met the conditions at the same time - there are no concept where Awesome Miner makes a guess which one of you actions that would make most sense to run - it will simply run the defined actions.

I think what you are asking for is basically a more specialized way to setup the clocking based on conditions, and the rules are very generic purpose way of doing operations and may not be refined enough for this level of per-device control.

As pointed out earlier, making the rules more device-aware could be a way forward in the future.

Update: Please also see my answer below that is a bit more solution-oriented.

You understand but half. If AM only takes the value of the hottest card, whatever is inside the rig, problem solved. You know it but you do not say it.

But right now I do not care anymore. The fan control system in AM does not work well and works perfectly Aftherburner, I do not change anymore. I stay with Aftherburner for the fans, since it takes into account each card by independent and can be curved. I tried to emulate the curve with rules, but as any card triggers contrary rules, it is a disaster.

To me now if it fixes or I do not care, I will not use it anymore. Fan control only by aftherburner.

I appreciate the feedback, but there is no need for this attitude.

I'm very well aware of that if rules in Awesome Miner execute the actions on a miner level, not for a specific device. That was exactly my point above - to explain how the rules works today and why it's not a perfect fit for this scenario. So I do acknowledge that for the scenario you describe, the rules concepts are not yet good enough.

This was also why I referred to my second post that included a proposed solution to be developed.

Quote from: trucobit on April 30, 2019, 05:27:40 PM

Quote from: patrike on April 30, 2019, 05:03:07 AM

Quote from: trucobit on April 30, 2019, 02:54:01 AM

I just tried a rig with native OC + aftherburner for the fans and it's another world. The much lower temperatures.

The temperature change is such that now I can increase the OC, because the temperatures are very low.

It has to improve the temperature system of native OC. I already happened to Aftherburner to control the fans. We are talking about almost 10 degrees less per card with a car curve in Aftherburner.

Is this with the "Automatic fan control properties" in the Properties dialog of MSI Afterburner? I think this is a pure software periodic check for temperature that set a fan speed based on the curve - without being a feature in the nVidia drivers itself. Defining a high fan speed here will of course result in a lower temperature.

Awesome Miner can probably be extended do something similar. The question is where it should be applied. If it isn't a feature of the nVidia drivers, Awesome Miner would have to check for the temperature all the time and compare it what you defined in your profile. A specific GPU is however not linked to a clocking profile, as you can apply any clocking profile to a miner while it's running. So there needs to be a new concept of last applied profile. But what if you apply a clocking profile to a miner where the new profile no longer have any fan/temperature curve? It's getting complex quite fast here.

I see that MSI Afterburner only do this fan control on a global level, completely outside their profile concept. That's a quite easy approach but may not be flexible enough if you run a mix of GPU's where you want different fan/temperature settings.

A solution somewhere in between would be to introduce a new rule action that you can schedule to run every 15 seconds, where the action will apply different fan speed settings per GPU depending on a fan/temp curve (or table) you define in the rule. That would be a solution outside the clocking profile concept, but maybe easier to both implement and configure.

Please do not say those things. With aftherburner takes the independent temperature of each card and increases or decreases the fan for each graphics card. So if one is hotter the fan will go faster but if one is cooler, the fan does not turn up. In the end it is less extress for the fans, less noise and a much more exhaustive control. It does not have to go faster

The problem in AM is that a card reaches 83 it gets ALL the RIG to 100% of fans although it is not necessary, but then suddenly one of the cards reaches 75, or 70 degrees and makes the speed drop to 70% but there is a card at 84 degrees that will reach 86 and stop the rig.

Aftherburner does not make the fans go faster, gives each card the amount of fan it needs, independently of one another within the same rig, something that AM can not do and I do not care as I do or do not. I think Aftherburner gives a control precision that is going to be very difficult for you to equalize.

I always appreciate all your work and I am always grateful to you, but I think you should recommend Aftherburner to the users and leave the fan control for aftherburner. And I repeat, the fans are not faster, and in some cards I have dropped to 10 degrees, in others the normal is from 4 to 7 degrees, and each card at a speed automatically dispends according to my curve. Do not try to discredit Aftherburner by saying that it will go faster, it goes fast on the card you need, on the others you do not.

The future solution I was considering for Awesome Miner above was the following (not yet supported): "...apply different fan speed settings per GPU depending on a fan/temp curve (or table) you define in the rule". Isn't that exactly what MSI Afterburner do? Per-GPU control of fan speed based on monitoring of the temperature for each individual GPU.

If Awesome Miner would apply per-GPU control of fan speed based on a fan/temperature curve/table like MSI Afterburner do, the result should be the same. Some GPU's will have lower fan speed while other GPU's will have higher fan speed - depending on temperature. Just to make it very clear again, Awesome Miner cannot do this today - all I'm discussing here is a new feature to address your initial request.

If a GPU runs at a specific clock, voltage, power limit and fan speed - shouldn't the temperature be the same no matter if Awesome Miner or MSI Afterburner set those parameters? If the mining software/algorithm, clock, voltage and power limit remains the same, isn't it mainly the fan speed that will impact the temperature of a GPU? So reducing GPU temperature is a matter of fan speed control (= higher fan speed for some GPU's) at this point.

So let's work together on making the new per-GPU control of fan speed based on temperature (using a curve/table) a good new feature! Thanks!

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: mikeywith on April 30, 2019, 06:20:30 PM

Quote from: tim-bc on April 30, 2019, 10:46:25 AM

Hi Patrick,

I don't use Awesome Miner myself, but I would suggest adding a feature to switch between LPM and Enhanced LPM on miners with firmwares that support it.

https://bitcointalksearch.org/topic/antminer-s9-heres-how-to-switch-between-lpm-and-enhanced-lpm-programmatically-5109185

Cheers!

I second this, would really love to have this on Awesome Miner.

please put it on your To-Do List Patrick, all new firmware for s9 and later gears have these LPM and Enhanced LPM ( more power saving ), it is very useful to have an auto-switch between these two, for those who have different power rate at peak hours, it would also be great for miners who mine in a hot region like myself, where i might need to set all my gears to Enhanced LPM during noon/afternoon time and to switch back to LPM automatically.

Thanks for the suggestions.

Based on what I can see in the linked thread, I assume this is only a matter of executing an SSH command on the Antminer? Awesome Miner can do that via the rules already today. Any SSH commands can be sent to an ASIC miner.

You can for example have one rule that triggers at 11 AM and send one SSH command to set Enhanced LPM and another rule that triggers at 4 PM that send the SSH command to set LPM.

The concept should be similar to "Example: Run GPU mining during a specific time", but instead of the action that will start/stop the miner, you would use the "SSH Command" action to execute the command to set LPM or ELPM.
https://support.awesomeminer.com/support/solutions/articles/35000085907-rules-detect-mining-issues-and-automate-tasks

If this solution works fine I can also add it as a separate example in the documentation.

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: Siolim on April 30, 2019, 06:55:04 AM

Hi Patricke.
Tell me, please, is it possible to connect a miner without adding a line - no-watchdog? Some miners do not understand this version (for example https://github.com/xaya/ccminer/releases/tag/v0.1)

Thank you for the wonderful work.

Thanks for your nice feedback!

This command line (--no-watchdog) is only added automatically for software based on CryptoDredge. Please try to select CcMiner instead and it shouldn't be added.

mikeywith

legendary

Activity: 2394

Merit: 6581

be constructive or S.T.F.U

Quote from: tim-bc on April 30, 2019, 10:46:25 AM

Hi Patrick,

I don't use Awesome Miner myself, but I would suggest adding a feature to switch between LPM and Enhanced LPM on miners with firmwares that support it.

https://bitcointalksearch.org/topic/antminer-s9-heres-how-to-switch-between-lpm-and-enhanced-lpm-programmatically-5109185

Cheers!

I second this, would really love to have this on Awesome Miner.

please put it on your To-Do List Patrick, all new firmware for s9 and later gears have these LPM and Enhanced LPM ( more power saving ), it is very useful to have an auto-switch between these two, for those who have different power rate at peak hours, it would also be great for miners who mine in a hot region like myself, where i might need to set all my gears to Enhanced LPM during noon/afternoon time and to switch back to LPM automatically.

trucobit

jr. member

Activity: 756

Merit: 2

Quote from: patrike on April 30, 2019, 05:03:07 AM

Quote from: trucobit on April 30, 2019, 02:54:01 AM

I just tried a rig with native OC + aftherburner for the fans and it's another world. The much lower temperatures.

The temperature change is such that now I can increase the OC, because the temperatures are very low.

It has to improve the temperature system of native OC. I already happened to Aftherburner to control the fans. We are talking about almost 10 degrees less per card with a car curve in Aftherburner.

Is this with the "Automatic fan control properties" in the Properties dialog of MSI Afterburner? I think this is a pure software periodic check for temperature that set a fan speed based on the curve - without being a feature in the nVidia drivers itself. Defining a high fan speed here will of course result in a lower temperature.

Awesome Miner can probably be extended do something similar. The question is where it should be applied. If it isn't a feature of the nVidia drivers, Awesome Miner would have to check for the temperature all the time and compare it what you defined in your profile. A specific GPU is however not linked to a clocking profile, as you can apply any clocking profile to a miner while it's running. So there needs to be a new concept of last applied profile. But what if you apply a clocking profile to a miner where the new profile no longer have any fan/temperature curve? It's getting complex quite fast here.

I see that MSI Afterburner only do this fan control on a global level, completely outside their profile concept. That's a quite easy approach but may not be flexible enough if you run a mix of GPU's where you want different fan/temperature settings.

A solution somewhere in between would be to introduce a new rule action that you can schedule to run every 15 seconds, where the action will apply different fan speed settings per GPU depending on a fan/temp curve (or table) you define in the rule. That would be a solution outside the clocking profile concept, but maybe easier to both implement and configure.

Please do not say those things. With aftherburner takes the independent temperature of each card and increases or decreases the fan for each graphics card. So if one is hotter the fan will go faster but if one is cooler, the fan does not turn up. In the end it is less extress for the fans, less noise and a much more exhaustive control. It does not have to go faster

The problem in AM is that a card reaches 83 it gets ALL the RIG to 100% of fans although it is not necessary, but then suddenly one of the cards reaches 75, or 70 degrees and makes the speed drop to 70% but there is a card at 84 degrees that will reach 86 and stop the rig.

Aftherburner does not make the fans go faster, gives each card the amount of fan it needs, independently of one another within the same rig, something that AM can not do and I do not care as I do or do not. I think Aftherburner gives a control precision that is going to be very difficult for you to equalize.

I always appreciate all your work and I am always grateful to you, but I think you should recommend Aftherburner to the users and leave the fan control for aftherburner. And I repeat, the fans are not faster, and in some cards I have dropped to 10 degrees, in others the normal is from 4 to 7 degrees, and each card at a speed automatically dispends according to my curve. Do not try to discredit Aftherburner by saying that it will go faster, it goes fast on the card you need, on the others you do not.

trucobit

jr. member

Activity: 756

Merit: 2

Quote from: patrike on April 30, 2019, 04:41:56 AM

Quote from: trucobit on April 30, 2019, 02:29:14 AM

Quote from: trucobit on April 29, 2019, 07:48:03 AM

At the moment this problem of the OC and temperatures is causing me great problems. there are already two RIGs, the rig of the RTX there is a card, which is more in the background that even reaches 87 and turn off the miner in security.

But I start observing the FAns in GPU, and I see that suddenly I'm at 84 and fans are lowered to 65% because it has picked up the temperature of another card, according to my rules at 84 degrees it would go to 90% fan, and repende is lowered to 65%, because that card reaches the maximum temperature of 87 and turns off the miner.

I hope you have a solution or I will have to drive MSI aftherburner again. But I really like this native solution. You should only take the value of the hottest card in the RIG and do not go changing card reading

At the same time I'm going to have to leave the fixed fans something I do not want, but of course it's a big mistake that I take the temperature data from different cards, so it can not be efficient.

Please, if you are not going to fix it, tell me already and I will change to the old system with Aftherburner or a fixed fan.

One of the two is wrong. Right now, like this one, you do not look at just one card, you look at all of them. Then a card, the hottest one that should be sent, is activated at 90% fan at 80 degrees, but now it turns out that another card of the same rig reaches 75 degrees and I lower the fans to 70% .. Is it more important to reduce 75 degrees or reduce 80 degrees?

Therefore the concept of temperature for a rig, should take into account only 1 card, the hottest. Because the change of speed is applied to ALL THE RIG. If the speed of the fans was independent by card, his vision would be accurate, but as it is not so, it is wrong.

I suppose I could use Atherburner only for the fans, its solution to put rules that jump at different temperatures is not valid. It can not be that I have a card at 84 degrees that would correspond to 100% of FAN, and suddenly because another card of the rig reaches 75 degrees, I lower all the rig to 75% of Fan. Obviously the card that is in 84 degrees will rise and to 86 I turn the miner to avoid problems of breakage by temperature.

Here there are only 3 solutions:

1- that the rules affect each card independently, it would be very good.

2 - Always take the value of the hottest card, this would be the optimal point, that always in the rules send the FAN the card with the highest temperature. This would be the best solution and faster in programming.

3.- re-use Aftherbuner at the same time as the native, only to control the fans.

You understand that as it is now, even with rules, if I have not activated the heat protection rule, I could have damaged cards. I like your native OC a lot, but the temperature should send the card with more heat, whatever it is inside the rig, and just follow that. If suddenly another card in the same rig exceeds the previous one in temperature, then that new card is the one that would take control of the entire RIG. TAl as it is now, yesterday I skipped the rigs every few minutes and they stopped. I could not give credit to my eyes, to see cards at 84 degrees to 100% and suddenly went down to 65% because another card had reached the goal of a rule and applied to the whole rig, that does not matter as you explain it But it's not good.

You give a greater control of fan as aftherburner or you guide by the card of more temperature of the rig, because if not, cards of those people who do not have rules of stopping the miner can be broken if it reaches 86 degrees as I have.

This kind of situations did not happen with the complete solution of aftherburner, although the connection with the main program is very bad, so I will use the native and I will see that I think so, use a fan speed curve in aftherburner, but this is already ahead of time It will be a problem for many as soon as the heat arrives.

The Device Temperature trigger is currently looking for the GPU with the highest temperature. If your trigger condition is 80 degrees, it will trigger as soon one of the GPU's hit this level. Any action will be performed on the miner itself.

If you have multiple Device Temperature triggers and two of them have met the conditions at the same time - there are no concept where Awesome Miner makes a guess which one of you actions that would make most sense to run - it will simply run the defined actions.

I think what you are asking for is basically a more specialized way to setup the clocking based on conditions, and the rules are very generic purpose way of doing operations and may not be refined enough for this level of per-device control.

As pointed out earlier, making the rules more device-aware could be a way forward in the future.

Update: Please also see my answer below that is a bit more solution-oriented.

You understand but half. If AM only takes the value of the hottest card, whatever is inside the rig, problem solved. You know it but you do not say it.

But right now I do not care anymore. The fan control system in AM does not work well and works perfectly Aftherburner, I do not change anymore. I stay with Aftherburner for the fans, since it takes into account each card by independent and can be curved. I tried to emulate the curve with rules, but as any card triggers contrary rules, it is a disaster.

To me now if it fixes or I do not care, I will not use it anymore. Fan control only by aftherburner.

These past weeks I have purchased professional ARTIC brand coolers to reduce the temperature for summer, but I see that AM is not up to scratch. There are other important things and in all the functions AM can not be the best. Right now native OC + Aftherburner in each machine in car and with custom curve reduces in much the temperature of each rig.

tim-bc

full member

Activity: 538

Merit: 175

Hi Patrick,

I don't use Awesome Miner myself, but I would suggest adding a feature to switch between LPM and Enhanced LPM on miners with firmwares that support it.

https://bitcointalksearch.org/topic/antminer-s9-heres-how-to-switch-between-lpm-and-enhanced-lpm-programmatically-5109185

Cheers!

Siolim

newbie

Activity: 107

Merit: 0

Hi Patricke.
Tell me, please, is it possible to connect a miner without adding a line - no-watchdog? Some miners do not understand this version (for example https://github.com/xaya/ccminer/releases/tag/v0.1)

Thank you for the wonderful work.

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: trucobit on April 30, 2019, 02:54:01 AM

I just tried a rig with native OC + aftherburner for the fans and it's another world. The much lower temperatures.

The temperature change is such that now I can increase the OC, because the temperatures are very low.

It has to improve the temperature system of native OC. I already happened to Aftherburner to control the fans. We are talking about almost 10 degrees less per card with a car curve in Aftherburner.

Is this with the "Automatic fan control properties" in the Properties dialog of MSI Afterburner? I think this is a pure software periodic check for temperature that set a fan speed based on the curve - without being a feature in the nVidia drivers itself. Defining a high fan speed here will of course result in a lower temperature.

Awesome Miner can probably be extended do something similar. The question is where it should be applied. If it isn't a feature of the nVidia drivers, Awesome Miner would have to check for the temperature all the time and compare it what you defined in your profile. A specific GPU is however not linked to a clocking profile, as you can apply any clocking profile to a miner while it's running. So there needs to be a new concept of last applied profile. But what if you apply a clocking profile to a miner where the new profile no longer have any fan/temperature curve? It's getting complex quite fast here.

I see that MSI Afterburner only do this fan control on a global level, completely outside their profile concept. That's a quite easy approach but may not be flexible enough if you run a mix of GPU's where you want different fan/temperature settings.

A solution somewhere in between would be to introduce a new rule action that you can schedule to run every 15 seconds, where the action will apply different fan speed settings per GPU depending on a fan/temp curve (or table) you define in the rule. That would be a solution outside the clocking profile concept, but maybe easier to both implement and configure.

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: trucobit on April 30, 2019, 02:29:14 AM

Quote from: trucobit on April 29, 2019, 07:48:03 AM

At the moment this problem of the OC and temperatures is causing me great problems. there are already two RIGs, the rig of the RTX there is a card, which is more in the background that even reaches 87 and turn off the miner in security.

But I start observing the FAns in GPU, and I see that suddenly I'm at 84 and fans are lowered to 65% because it has picked up the temperature of another card, according to my rules at 84 degrees it would go to 90% fan, and repende is lowered to 65%, because that card reaches the maximum temperature of 87 and turns off the miner.

I hope you have a solution or I will have to drive MSI aftherburner again. But I really like this native solution. You should only take the value of the hottest card in the RIG and do not go changing card reading

At the same time I'm going to have to leave the fixed fans something I do not want, but of course it's a big mistake that I take the temperature data from different cards, so it can not be efficient.

Please, if you are not going to fix it, tell me already and I will change to the old system with Aftherburner or a fixed fan.

One of the two is wrong. Right now, like this one, you do not look at just one card, you look at all of them. Then a card, the hottest one that should be sent, is activated at 90% fan at 80 degrees, but now it turns out that another card of the same rig reaches 75 degrees and I lower the fans to 70% .. Is it more important to reduce 75 degrees or reduce 80 degrees?

Therefore the concept of temperature for a rig, should take into account only 1 card, the hottest. Because the change of speed is applied to ALL THE RIG. If the speed of the fans was independent by card, his vision would be accurate, but as it is not so, it is wrong.

I suppose I could use Atherburner only for the fans, its solution to put rules that jump at different temperatures is not valid. It can not be that I have a card at 84 degrees that would correspond to 100% of FAN, and suddenly because another card of the rig reaches 75 degrees, I lower all the rig to 75% of Fan. Obviously the card that is in 84 degrees will rise and to 86 I turn the miner to avoid problems of breakage by temperature.

Here there are only 3 solutions:

1- that the rules affect each card independently, it would be very good.

2 - Always take the value of the hottest card, this would be the optimal point, that always in the rules send the FAN the card with the highest temperature. This would be the best solution and faster in programming.

3.- re-use Aftherbuner at the same time as the native, only to control the fans.

You understand that as it is now, even with rules, if I have not activated the heat protection rule, I could have damaged cards. I like your native OC a lot, but the temperature should send the card with more heat, whatever it is inside the rig, and just follow that. If suddenly another card in the same rig exceeds the previous one in temperature, then that new card is the one that would take control of the entire RIG. TAl as it is now, yesterday I skipped the rigs every few minutes and they stopped. I could not give credit to my eyes, to see cards at 84 degrees to 100% and suddenly went down to 65% because another card had reached the goal of a rule and applied to the whole rig, that does not matter as you explain it But it's not good.

You give a greater control of fan as aftherburner or you guide by the card of more temperature of the rig, because if not, cards of those people who do not have rules of stopping the miner can be broken if it reaches 86 degrees as I have.

This kind of situations did not happen with the complete solution of aftherburner, although the connection with the main program is very bad, so I will use the native and I will see that I think so, use a fan speed curve in aftherburner, but this is already ahead of time It will be a problem for many as soon as the heat arrives.

The Device Temperature trigger is currently looking for the GPU with the highest temperature. If your trigger condition is 80 degrees, it will trigger as soon one of the GPU's hit this level. Any action will be performed on the miner itself.

If you have multiple Device Temperature triggers and two of them have met the conditions at the same time - there are no concept where Awesome Miner makes a guess which one of you actions that would make most sense to run - it will simply run the defined actions.

I think what you are asking for is basically a more specialized way to setup the clocking based on conditions, and the rules are very generic purpose way of doing operations and may not be refined enough for this level of per-device control.

As pointed out earlier, making the rules more device-aware could be a way forward in the future.

Update: Please also see my answer below that is a bit more solution-oriented.

trucobit

jr. member

Activity: 756

Merit: 2

I just tried a rig with native OC + aftherburner for the fans and it's another world. The much lower temperatures.

The temperature change is such that now I can increase the OC, because the temperatures are very low.

It has to improve the temperature system of native OC. I already happened to Aftherburner to control the fans. We are talking about almost 10 degrees less per card with a car curve in Aftherburner.

trucobit

jr. member

Activity: 756

Merit: 2

Quote from: patrike on April 29, 2019, 08:28:26 AM

Quote from: trucobit on April 29, 2019, 07:48:03 AM

At the moment this problem of the OC and temperatures is causing me great problems. there are already two RIGs, the rig of the RTX there is a card, which is more in the background that even reaches 87 and turn off the miner in security.

But I start observing the FAns in GPU, and I see that suddenly I'm at 84 and fans are lowered to 65% because it has picked up the temperature of another card, according to my rules at 84 degrees it would go to 90% fan, and repende is lowered to 65%, because that card reaches the maximum temperature of 87 and turns off the miner.

I hope you have a solution or I will have to drive MSI aftherburner again. But I really like this native solution. You should only take the value of the hottest card in the RIG and do not go changing card reading

At the same time I'm going to have to leave the fixed fans something I do not want, but of course it's a big mistake that I take the temperature data from different cards, so it can not be efficient.

Please, if you are not going to fix it, tell me already and I will change to the old system with Aftherburner or a fixed fan.

One of the two is wrong. Right now, like this one, you do not look at just one card, you look at all of them. Then a card, the hottest one that should be sent, is activated at 90% fan at 80 degrees, but now it turns out that another card of the same rig reaches 75 degrees and I lower the fans to 70% .. Is it more important to reduce 75 degrees or reduce 80 degrees?

Therefore the concept of temperature for a rig, should take into account only 1 card, the hottest. Because the change of speed is applied to ALL THE RIG. If the speed of the fans was independent by card, his vision would be accurate, but as it is not so, it is wrong.

I suppose I could use Atherburner only for the fans, its solution to put rules that jump at different temperatures is not valid. It can not be that I have a card at 84 degrees that would correspond to 100% of FAN, and suddenly because another card of the rig reaches 75 degrees, I lower all the rig to 75% of Fan. Obviously the card that is in 84 degrees will rise and to 86 I turn the miner to avoid problems of breakage by temperature.

Here there are only 3 solutions:

1- that the rules affect each card independently, it would be very good.

2 - Always take the value of the hottest card, this would be the optimal point, that always in the rules send the FAN the card with the highest temperature. This would be the best solution and faster in programming.

3.- re-use Aftherbuner at the same time as the native, only to control the fans.

You understand that as it is now, even with rules, if I have not activated the heat protection rule, I could have damaged cards. I like your native OC a lot, but the temperature should send the card with more heat, whatever it is inside the rig, and just follow that. If suddenly another card in the same rig exceeds the previous one in temperature, then that new card is the one that would take control of the entire RIG. TAl as it is now, yesterday I skipped the rigs every few minutes and they stopped. I could not give credit to my eyes, to see cards at 84 degrees to 100% and suddenly went down to 65% because another card had reached the goal of a rule and applied to the whole rig, that does not matter as you explain it But it's not good.

You give a greater control of fan as aftherburner or you guide by the card of more temperature of the rig, because if not, cards of those people who do not have rules of stopping the miner can be broken if it reaches 86 degrees as I have.

This kind of situations did not happen with the complete solution of aftherburner, although the connection with the main program is very bad, so I will use the native and I will see that I think so, use a fan speed curve in aftherburner, but this is already ahead of time It will be a problem for many as soon as the heat arrives.

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: trucobit on April 29, 2019, 07:48:03 AM

At the moment this problem of the OC and temperatures is causing me great problems. there are already two RIGs, the rig of the RTX there is a card, which is more in the background that even reaches 87 and turn off the miner in security.

But I start observing the FAns in GPU, and I see that suddenly I'm at 84 and fans are lowered to 65% because it has picked up the temperature of another card, according to my rules at 84 degrees it would go to 90% fan, and repende is lowered to 65%, because that card reaches the maximum temperature of 87 and turns off the miner.

I hope you have a solution or I will have to drive MSI aftherburner again. But I really like this native solution. You should only take the value of the hottest card in the RIG and do not go changing card reading

At the same time I'm going to have to leave the fixed fans something I do not want, but of course it's a big mistake that I take the temperature data from different cards, so it can not be efficient.

Please, if you are not going to fix it, tell me already and I will change to the old system with Aftherburner or a fixed fan.

The Triggers are currently only passing a list of miners to the Actions, not a list of devices. It's always a miner that is being triggered, not an individual device.

If you have a Trigger configured to look at the device temperature of 85C and one out of 6 GPU's reach this level it will run the Actions defined for the rule. The actions will run with a list of miners produced by the trigger.

The action can be anything like rebooting the computer and setting clocking parameters. The limitation is that the action only know the miner that cause the trigger, not if the trigger itself only fired for a specific GPU.

This is the reason why your trigger condition for a specific device will result in that the actions are executed on a miner level, not device level.

I can agree that it would be good to have a device-concept for the triggers as well. It may however be a bit complex in scenarios where you use multiple triggers and some of them are per-device while other are on a miner level. I don't have any quick solution to this as I need to investigate how this can be supported. It's no quick fix as the entire rule concept would have to be considered, while not breaking anything and keeping backwards compatibility.

Which MSI Afterburner settings are you using to get this behavior in the way you want? I know that Afterburner have the Voltage/Frequency curve dialog and on the 1000-series you only have Frequency/Voltage while the 2000-series GPU's also have Frequency/Temperature. Awesome Miner doesn't have these "curve" features yet.

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: slysir on April 29, 2019, 07:01:29 AM

Feature request:

Can you please add a Rules- Trigger for Miner power: watts

It is useful to take an Action like "Apply GPU clocking profile" to reduce/increase the power limit.

Thanks for the suggestion. I know that @joseph32 requested something similar a while ago so it's likely to be added in one of the next releases.

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