Author

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

legendary
Activity: 3346
Merit: 1094
Hi Patrike,

we have many times the problem, that some miners (especially Antminer L3+) get the Status (in Red) Disconnected - API Access Denied
if we send the command: Reboot (via SSH), the miner is working fine again (after a reboot)

so we would like to make a rule for that event - but unfortunatly i don't find any trigger for this event?! there is the Trigger Offline detection... but no one for this specific event?! is there another option??

BR Ralf
Hi Ralf,

Thanks for your question. Unfortunately it can happen sometimes that Antminers stop responding to monitoring request requests. In some cases the Antminers are more sensitive to this problem when mining on specific pools, but in other cases it's more difficult to find an exact reason.

The predefined rule "Offline Detection" should be able to detect this scenario. By default it will only give a notification (only once, until you acknowledge the notification), but you can also add actions to perform a reboot or similar. Can you please try check if this rule detects the issue in your cae?

Hi Patrike,

thank you for your suggestion - actually the state Disconnected - API Access Denied is different to only Disconnected... but i will try with a rule, that execute only every 40 minutes for this problem.
allthough it would be helpfull, if one could choose the 2 different states in the rule-triggers...

BR Ralf

Hi Patrike,

we have to narrow the 40 minutes to 15 minutes - otherwise, the rule is not effective... but now the rule doesn't work well either... the problem is, that the rule is also triggering if you reboot a miner and he needs more then 15 minutes until actively mining - then the rule reboots him again and again and again...

so we would be very happy, if we could select the state "Disconnected - API Access Denied" in this case, we can run the rule without time-limit and in a stable way...

thank you in advance!!

BR Ralf
Hi Ralf,
I've looked into this earlier based on your previous feedback and I have now created a new Trigger type for you ("Detect Miner State") where you can detect this specific state.
Please let me know your feedback once the next version is released. Thanks!
newbie
Activity: 52
Merit: 0
Hi Patrike,

we have many times the problem, that some miners (especially Antminer L3+) get the Status (in Red) Disconnected - API Access Denied
if we send the command: Reboot (via SSH), the miner is working fine again (after a reboot)

so we would like to make a rule for that event - but unfortunatly i don't find any trigger for this event?! there is the Trigger Offline detection... but no one for this specific event?! is there another option??

BR Ralf
Hi Ralf,

Thanks for your question. Unfortunately it can happen sometimes that Antminers stop responding to monitoring request requests. In some cases the Antminers are more sensitive to this problem when mining on specific pools, but in other cases it's more difficult to find an exact reason.

The predefined rule "Offline Detection" should be able to detect this scenario. By default it will only give a notification (only once, until you acknowledge the notification), but you can also add actions to perform a reboot or similar. Can you please try check if this rule detects the issue in your cae?

Hi Patrike,

thank you for your suggestion - actually the state Disconnected - API Access Denied is different to only Disconnected... but i will try with a rule, that execute only every 40 minutes for this problem.
allthough it would be helpfull, if one could choose the 2 different states in the rule-triggers...

BR Ralf

Hi Patrike,

we have to narrow the 40 minutes to 15 minutes - otherwise, the rule is not effective... but now the rule doesn't work well either... the problem is, that the rule is also triggering if you reboot a miner and he needs more then 15 minutes until actively mining - then the rule reboots him again and again and again...

so we would be very happy, if we could select the state "Disconnected - API Access Denied" in this case, we can run the rule without time-limit and in a stable way...

thank you in advance!!

BR Ralf
legendary
Activity: 3346
Merit: 1094
Hi again Patrike

first thank you so much for answering the previous question, that was exactly what you guessed! Smiley

now I have another problem, hope you can shed some light on this too.

I just upgraded the firmware of my antminer s9 to the latest, and now the Awesome Miner cannot do anything with it except showing its hashrate, that's because the api access to it is shown to be restricted. I have tried configuring api access as explained in the software's tuts, it shows "Connection Failure" on the API access configuration window. this time i left the username, password fields blank but no help, also tried both "root-admin" and the web interface username-password too but those didn't work also, the same Connection Failure. I even tried the manual configuration using ssh commands, again no help!

I will be so grateful if you could help me out in this one too.
thanks again

No help for that (yet), latest s9(i,j etc) firmware has a locked SSH access so AM can't communicate with miner as it use to. I also hope there will some workaround regarding this issue but for now:

DO NOT UPGRADE YOUR BITMAIN ASIC MINERS TO LATEST 2019 FIRMWARE !!!!
Your observation is correct, it looks like Bitmain start to lock down their ASIC miners more with the recent firmware upgrades.

With SSH access disabled, Awesome Miner cannot connect and reconfigure the API access. This is the reason for the "Connection failure".

Update:
I've previously had a short conversation with Bitmain regarding the disabled SSH on Antminer S15, but it has not yet resulted in any solution being provided. I've reached out to them again on this topic to ask for a way to enable Privileged API access. Even if the SSH access still will be disabled, I would like to see the API setting being configurable in the web interface for the Antminer as an alternative solution.

The worst part is you can't revert S9 to previous firmware so until they provide you with a solution AM is just a monitoring tool
In addition, I know that a number of Awesome Miner users already contacted Bitmain about providing a solution where their miners can be managed (via the Privileged API concept). It should be in Bitmains interest to let their customers can manage their miners in a good way.

I would actually encourage users of Antminers to contact Bitmain on this topic to push for a solution. Even if Bitmain want to disable SSH for some reason, they should still add a setting in their web interface to allow the user to enable Privileged API access.
member
Activity: 277
Merit: 23
Hi again Patrike

first thank you so much for answering the previous question, that was exactly what you guessed! Smiley

now I have another problem, hope you can shed some light on this too.

I just upgraded the firmware of my antminer s9 to the latest, and now the Awesome Miner cannot do anything with it except showing its hashrate, that's because the api access to it is shown to be restricted. I have tried configuring api access as explained in the software's tuts, it shows "Connection Failure" on the API access configuration window. this time i left the username, password fields blank but no help, also tried both "root-admin" and the web interface username-password too but those didn't work also, the same Connection Failure. I even tried the manual configuration using ssh commands, again no help!

I will be so grateful if you could help me out in this one too.
thanks again

No help for that (yet), latest s9(i,j etc) firmware has a locked SSH access so AM can't communicate with miner as it use to. I also hope there will some workaround regarding this issue but for now:

DO NOT UPGRADE YOUR BITMAIN ASIC MINERS TO LATEST 2019 FIRMWARE !!!!
Your observation is correct, it looks like Bitmain start to lock down their ASIC miners more with the recent firmware upgrades.

With SSH access disabled, Awesome Miner cannot connect and reconfigure the API access. This is the reason for the "Connection failure".

Update:
I've previously had a short conversation with Bitmain regarding the disabled SSH on Antminer S15, but it has not yet resulted in any solution being provided. I've reached out to them again on this topic to ask for a way to enable Privileged API access. Even if the SSH access still will be disabled, I would like to see the API setting being configurable in the web interface for the Antminer as an alternative solution.

The worst part is you can't revert S9 to previous firmware so until they provide you with a solution AM is just a monitoring tool
legendary
Activity: 3346
Merit: 1094
https://www.dropbox.com/s/6i4nu2mjviw3y67/Captura%20de%20pantalla%202019-04-13%20a%20las%206.35.30.png?dl=0


You will see the Xfox currency and its estimate of more than 7000 coins in a day (rigti 1080ti). But it's wrong, I think the formula of your profit is not very accurate and I can say it because we measure and test all the currencies / pool and elprofit is between 0.70 to 0.95 90% of the time, but it's not what same mine to 0.80 that to 1.

In this case, this Xfox coin has a blocking time of 2 minutes and has a reward of 2.79 (removing fee from the pool), the maximum coins per day is from 2008, it does not matter how many machines and the hash is the same because the difficulty it adjusts itself, the maximum is 2008 coins per day.

With which his estimate is completely wrong in this currency and slightly deviated in many others, but it is no longer a question of data, it is a question of formula.
The formula itself is correct and gives the exact same results are WhatToMine and CoinCalculators in general. There can however be specific coins that do something differently where you manually need to adjust the profit factor as it's not possible to compute the number of coins per day the standard way.

You must take into account block time, reward and nethash, to have a more accurate profit. It is a more complex formula, more data to take into account and we must take into account the maximum coins per day for the estimates offered by AM

It is only a constructive criticism, we customize all fields, difficulty, recommensa, price of exchanges directly (that's why it would be good to cache results between requests)

It's just an example where the formula is not right. Neither can it be to mine ZEL when its real profit is 0.65 and so many currencies. You imagine mining ZEL to profit 1, but then only receive 65% of the mined. That's why I recommend everyone to do pool and coin tests, if you change the pool you have to repeat the test.
Yes, the plan is to add support for the "NetHash" way of doing the calculations as well, where Block Time is one of the factors. The idea is also have this configurable per coin so if you run into a coin where the standard way of doing the calculations doesn't give the expected results, you should be able to switch to this other mode.


Last detail, the benchmark. When I do a 2 or 5 hour test, what value does it give?

The last value he had at the end of the test
The highest peak of hash
The average of the hash of those 5 hours (This would be the correct one)
@patrike should average the benchmar hash, if not, the benchmark is totally useless for AL-GOS that change subalways, it just is not worth it.

@PAtrike is there no way to average the hash value of 2, 5 or 10 hours, during a benchmark?
It should be the average but excluding a few samples in the beginning as those first samples are typically too low. However, I did notice an issue here with long running benchmarks so I will make a correction for that case. Thanks for finding it.

Update - coin properties:
I've just finished the implementation for Network Hashrate and Block Time in the Coin Properties, together with a setting where you can select one of the following calculation methods:
- Difficulty, Block Reward and Exponential factor
- Network Hashrate, Block Reward and Block Time
legendary
Activity: 3346
Merit: 1094
Hi again Patrike

first thank you so much for answering the previous question, that was exactly what you guessed! Smiley

now I have another problem, hope you can shed some light on this too.

I just upgraded the firmware of my antminer s9 to the latest, and now the Awesome Miner cannot do anything with it except showing its hashrate, that's because the api access to it is shown to be restricted. I have tried configuring api access as explained in the software's tuts, it shows "Connection Failure" on the API access configuration window. this time i left the username, password fields blank but no help, also tried both "root-admin" and the web interface username-password too but those didn't work also, the same Connection Failure. I even tried the manual configuration using ssh commands, again no help!

I will be so grateful if you could help me out in this one too.
thanks again

No help for that (yet), latest s9(i,j etc) firmware has a locked SSH access so AM can't communicate with miner as it use to. I also hope there will some workaround regarding this issue but for now:

DO NOT UPGRADE YOUR BITMAIN ASIC MINERS TO LATEST 2019 FIRMWARE !!!!
Your observation is correct, it looks like Bitmain start to lock down their ASIC miners more with the recent firmware upgrades.

With SSH access disabled, Awesome Miner cannot connect and reconfigure the API access. This is the reason for the "Connection failure".

Update:
I've previously had a short conversation with Bitmain regarding the disabled SSH on Antminer S15, but it has not yet resulted in any solution being provided. I've reached out to them again on this topic to ask for a way to enable Privileged API access. Even if the SSH access still will be disabled, I would like to see the API setting being configurable in the web interface for the Antminer as an alternative solution.
member
Activity: 277
Merit: 23
Hi again Patrike

first thank you so much for answering the previous question, that was exactly what you guessed! Smiley

now I have another problem, hope you can shed some light on this too.

I just upgraded the firmware of my antminer s9 to the latest, and now the Awesome Miner cannot do anything with it except showing its hashrate, that's because the api access to it is shown to be restricted. I have tried configuring api access as explained in the software's tuts, it shows "Connection Failure" on the API access configuration window. this time i left the username, password fields blank but no help, also tried both "root-admin" and the web interface username-password too but those didn't work also, the same Connection Failure. I even tried the manual configuration using ssh commands, again no help!

I will be so grateful if you could help me out in this one too.
thanks again

No help for that (yet), latest s9(i,j etc) firmware has a locked SSH access so AM can't communicate with miner as it use to. I also hope there will some workaround regarding this issue but for now:

DO NOT UPGRADE YOUR BITMAIN ASIC MINERS TO LATEST 2019 FIRMWARE !!!!
jr. member
Activity: 756
Merit: 2
Last detail, the benchmark. When I do a 2 or 5 hour test, what value does it give?

The last value he had at the end of the test
The highest peak of hash
The average of the hash of those 5 hours (This would be the correct one)

I do not know exactly what data is the one that shows and saves the benchmark.

I will answer my previous question. It does not matter 2 hours, 5 hours or 10 hours, it will always give you the last value of the last share. It does not average

So it does not work to put x16r, x16rt, x16s, X17 and the other X, because it will not make an average hash, it will only take the last hash sent after 5 hours.

So far I do it manually, I set to mine x16R I leave it at least 2 hours, I take captures every 10 minutes and then average the hash value of all the captures. That is a very heavy work, and more when each rig is different.

@patrike should average the benchmar hash, if not, the benchmark is totally useless for AL-GOS that change subalways, it just is not worth it.

@PAtrike is there no way to average the hash value of 2, 5 or 10 hours, during a benchmark?
newbie
Activity: 2
Merit: 0
Hi again Patrike

first thank you so much for answering the previous question, that was exactly what you guessed! Smiley

now I have another problem, hope you can shed some light on this too.

I just upgraded the firmware of my antminer s9 to the latest, and now the Awesome Miner cannot do anything with it except showing its hashrate, that's because the api access to it is shown to be restricted. I have tried configuring api access as explained in the software's tuts, it shows "Connection Failure" on the API access configuration window. this time i left the username, password fields blank but no help, also tried both "root-admin" and the web interface username-password too but those didn't work also, the same Connection Failure. I even tried the manual configuration using ssh commands, again no help!

I will be so grateful if you could help me out in this one too.
thanks again
jr. member
Activity: 756
Merit: 2
https://www.dropbox.com/s/6i4nu2mjviw3y67/Captura%20de%20pantalla%202019-04-13%20a%20las%206.35.30.png?dl=0


You will see the Xfox currency and its estimate of more than 7000 coins in a day (rigti 1080ti). But it's wrong, I think the formula of your profit is not very accurate and I can say it because we measure and test all the currencies / pool and elprofit is between 0.70 to 0.95 90% of the time, but it's not what same mine to 0.80 that to 1.

In this case, this Xfox coin has a blocking time of 2 minutes and has a reward of 2.79 (removing fee from the pool), the maximum coins per day is from 2008, it does not matter how many machines and the hash is the same because the difficulty it adjusts itself, the maximum is 2008 coins per day.

With which his estimate is completely wrong in this currency and slightly deviated in many others, but it is no longer a question of data, it is a question of formula.

You must take into account block time, reward and nethash, to have a more accurate profit. It is a more complex formula, more data to take into account and we must take into account the maximum coins per day for the estimates offered by AM

It is only a constructive criticism, we customize all fields, difficulty, recommensa, price of exchanges directly (that's why it would be good to cache results between requests)

It's just an example where the formula is not right. Neither can it be to mine ZEL when its real profit is 0.65 and so many currencies. You imagine mining ZEL to profit 1, but then only receive 65% of the mined. That's why I recommend everyone to do pool and coin tests, if you change the pool you have to repeat the test.


Last detail, the benchmark. When I do a 2 or 5 hour test, what value does it give?

The last value he had at the end of the test
The highest peak of hash
The average of the hash of those 5 hours (This would be the correct one)

I do not know exactly what data is the one that shows and saves the benchmark.

I feel so critical, it's a huge job, full of great difficulties, all this is normal.

Your current formula can be used in some way for the autoexchanges, because there you do not know what currency mines or their data, and there their formula makes sense.

To mine direct currencies, it is not adequate, it can and must be improved.

What produces maximum to the day (block and reward). What is the total hashnet, how much do I contribute (my participation), therefore how many coins per day can I get x price of the currency (profit)

And take into account the maximum daily production of coins per day, so as not to give strange numbers very high as in the example I have set.
member
Activity: 1558
Merit: 69
You dont need another 100's of clocking profiles, you just need 1 profile with your fixed 80% speed. Nothing else. Apply it with a rule to your miners, nothing else will be changed.

I think you're wrong in what you say. Although I create another profile, if I leave the other values at 0, in the end it will be 100PL 0 core 0 memory and fan speed.

When you apply an oc profile, the entire complete profile is applied, not just one parameter.

If I'm wrong, leave me here a screenshot of how I should leave the OC profile, but before you try it, it really works.

lol you are wrong. You need only 1 Profile, with only fan 80%, unmark the other properties. It worked perfect, we have 200 GPU, every card with a single profile.
20 People work with you and no one get this to work?

Look at GoRdiE uploaded pic, nothing more to say. https://i.imgur.com/JdzQr6P.jpg
member
Activity: 418
Merit: 21
Patrik,

I just want to say thanks for the new multi-GPU-benchmark. Extremely useful now, awesome!
newbie
Activity: 162
Merit: 0
You dont need another 100's of clocking profiles, you just need 1 profile with your fixed 80% speed. Nothing else. Apply it with a rule to your miners, nothing else will be changed.

I think you're wrong in what you say. Although I create another profile, if I leave the other values at 0, in the end it will be 100PL 0 core 0 memory and fan speed.

When you apply an oc profile, the entire complete profile is applied, not just one parameter.

If I'm wrong, leave me here a screenshot of how I should leave the OC profile, but before you try it, it really works.

https://i.imgur.com/JdzQr6P.jpg

Tienes que entrar enGPU Clocking->Cambiar el FAN de cualquiera-> Y cuando grabes el profile, marcar solo el FAN. Así ya tienes el profile 80% FAN
jr. member
Activity: 756
Merit: 2
You dont need another 100's of clocking profiles, you just need 1 profile with your fixed 80% speed. Nothing else. Apply it with a rule to your miners, nothing else will be changed.

I think you're wrong in what you say. Although I create another profile, if I leave the other values at 0, in the end it will be 100PL 0 core 0 memory and fan speed.

When you apply an oc profile, the entire complete profile is applied, not just one parameter.

If I'm wrong, leave me here a screenshot of how I should leave the OC profile, but before you try it, it really works.
member
Activity: 418
Merit: 21
You dont need another 100's of clocking profiles, you just need 1 profile with your fixed 80% speed. Nothing else. Apply it with a rule to your miners, nothing else will be changed.
jr. member
Activity: 756
Merit: 2
Use rules, fixed fans and 2 or more profiles. If the temperature reach 70°C for example make a rule to change to another profile with faster fixed fans. I think it is the easiest way. And in my opinion, if you mining, never use automatic fan control.

It is not feasible to do so, power can be, but it is not appropriate. I have 6 rigs, and I use about 20 Algos. I have established about 100 OC profiles.

What you are saying is that you make another 100 OC profiles with a fixed fan speed. I'm sorry but that's Chinese work.

There must be simpler options than what is proposed, which for an RIG may be worth and even so, there would be several profiles, at least 2 for each SOMETHING.

When you use the GPU Clocking dialog and select Save As, you can specify which GPU parameters to save to the profile. You can for example save only the fan speed property set to a value like 85%. I can agree that the usability should be improved a bit here.

You can then have a rule to apply this "Fan 85%" clocking profile to a running miner. It will not change the Clocking Profile permanently, but it will change the fan to 85% for a running mining.

It should be possible to use the Clocking Groups to combine different Clocking Profiles as well. Not only about having different Clocking Profiles for different GPU types, but also to apply multiple Clocking Profiles to the same GPU - where one profile could apply Fan speed only and another one the GPU/mem clocking.

@Patrike, in the rules, you can know the temperature of the cards and put a rule. But I do not see that it works. The rule can detect the temperature, 80 degrees in my case, and I indicate that the fan works fixed at 80%, but it does not. It seems to me that this one more thought for asic, surely it would have to restart miner in GPU, but to do it also it lowers the temperature and the rule does not shoot.

There some way to do what I indicate, and to apply a fixed speed to all the cards of the rig, without having to restart miner ?, would be an ideal solution for this situation, and summer is near.
If this is the "Device command" action, it's only operations intended for ASIC miners and SgMiner - not for GPU mining in general. This is where you need to apply clocking profiles instead.




----
When you use the GPU Clocking dialog and select Save As, you can specify which GPU parameters to save to the profile. You can for example save only the fan speed property set to a value like 85%. I can agree that the usability should be improved a bit here.

You can then have a rule to apply this "Fan 85%" clocking profile to a running miner. It will not change the Clocking Profile permanently, but it will change the fan to 85% for a running mining.

-----------

as you say in those two paragraphs. What I propose is to create two equal profiles, one with AUTO and another with a fixed speed fan, and by a rule use it. I do that when the temperature reaches 84 degrees and change to a very smooth OC and if it reaches 85 the miner stops.

But when applying a rule I can only choose an OC to change. Whatever my OC, the rule will only change to an OC that I choose. It is not the solution I am looking for, since I use multiple OCs according to the AL-GO and the miner in question, I would have to make hundreds of rules, one for miners and for each personalized OC.

If you already know that you can change the OC in real time and really use it to protect the cards. I do not understand why there can not be a rule that only changes the FAN regardless of the OC configuration that you are using, which are many. It is only the FAN is not complicated, the rule can take the current data of the OC that is in progress and only change the value of the FAN of AUTO to a fixed Speed, as easy as that.

I hope you have explained me well.
The solution available today to set fan speed to 85% for a miner via the rules:
- Use rule action "Apply clocking profile", where you have a Clocking Profile set to 85% fan speed for example. That's the only property of the clocking profile so all this action will do is to change the fan speed and nothing else. No matter if you have few or many Clocking Profiles in general, you need one extra profile for setting only the fan speed to 85% in this case.

This could be simplified into the following in the future:
- Use a new action concept to "Apply clocking setting" where you could select that you want the "Fan" property to be set to 85% for example. This would remove the need of the Clocking Profile containing the 85% fan speed property.

There are no difference in behavior between these two ways, it's just that the second one doesn't require you to create a Clocking Profile for each fan speed level you want to set. In both cases, it's only the fan speed that is changed an no other overclocking settings.

through modification of profile clocking, I must choose another complete profile that has the quality of 80% of fixed FAN. But that's what I say. If I have 100 OC profiles, I have to make another 100 equal ones that only change from automatic to one with fixed speed. It is not an option for me. I work with more than 20 people, I work with 1060, 1070, 1080ti and RTX, you know how many OC profiles I have. To think that I have to duplicate all of them and have another with fixed speed does not work for me.

I hope that ne future add a rule option in which only change the speed (internally load the chosen profile or change the car to a fixed number determined by me), I do not see it complicated. And with only one rule I have everything solved.


https://www.dropbox.com/s/e2icft05d0cll2b/Captura%20de%20pantalla%202019-04-11%20a%20las%2019.19.51.png?dl=0

That option of the image, as you said is for ASIC, but it would be perfect as is for GPU, that respects the OC of Pl, Core and MEM, and that only changes the FAN. As I already have other rules that if it reaches 82 degrees it changes to another profile, it works very well and if it reaches 84 it turns it off. I do this in case fans are broken, the miner shuts down.

I hope you add it someday, something as simple as capture and work in GPU. Internally the rule would throw the same OC just by changing the fan.
legendary
Activity: 3346
Merit: 1094
Awesome Miner Version 6.3

 ASIC mining
  - Updates to Antminer T15 support to include temperatures
 GPU mining
  - Benchmark improved to allow selection of multiple GPU's to use
  - Added additional algorithms
 Features
  - Define custom data sources for coin properties; Difficulty, Block Reward and Exchange rate. Use expressions to load values from any JSON data source or plain value source.
  - The Reboot button in the main toolbar will be available for External Miners as well, performing a reboot over SSH
  - Updates to the built-in web interface, including a new dark theme (configurable in the Options dialog, Web section)
  - Custom filter expressions configurable per User Group when accessing the local web interface
  - Added menu entry to the Log File menu to only return the most recent log entries
  - Added additional options for duration of benchmark
  - Improved accuracy of device selection for benchmark in systems with mixed GPU types
 Integration
  - Added additional exchanges to the coin exchange filter feature
  - Automatically setup Phoenix Miner pool parameters when using with Zergpool ProgPow
  - Adjustments to CuckaRoo29s calculations
  - Adjustments to new API for CoinCalculators.io
  - Updated Exponential Factor for ARRR coin
 API
  - Added notes to API for Managed Miners and External Miners
  - Added Profit Factor to API for pools (/api/pools)
 User interface
  - Coins with modified properties will be indicated with a blue color for the coin name on the Coins tab, even when running in Compact List mode
  - Updated coin images
  - Mining software list visual updates
  - Negative mining profit can be displayed even if the revenue is zero or unknown
  - Added additional coin images
  - Network scan IP address range saved
 Mining softare
  - Added mining software: Nanominer 1.1.1
  - Added mining software: Miniz 1.2m
  - Added mining software: RhMiner 1.5 for RandomHash
  - SrbMiner 1.8.2
  - WildRig Miner 0.15.4 preview 18
  - CryptoDredge 0.18.0
  - NBMiner 21.4
  - TeamRedMiner 0.4.3
  - Bminer 15.4
  - TT-Miner 2.2.1
  - PhoenixMiner 4.2c, including ProgPow support
  - Gminer 1.37
 Corrections
  - Correction to the path used by the built-in web interface
  - Correction to worker name display when mining with TT-miner
  - The combinaton of using CoinCalculators.io, non-default exchange rate mode and exchange filtering could result in incorrect exchange rate for BTC.
  - Correction to JCE GPU Miner selection of GPUs to use
  - Correction to Bminer command line for specific combinations of pool algorithms
  - Improved detection of mining software crashes and recovery for the Managed Profit Switcher
member
Activity: 1558
Merit: 69
You need only so much oc profiles, how much fan speeds you want. only save oc profile with only fanspeed in it. You can use this profile for every miner you want. So you need only 2 or 3 rules in my opinion for all miners.
legendary
Activity: 3346
Merit: 1094
Use rules, fixed fans and 2 or more profiles. If the temperature reach 70°C for example make a rule to change to another profile with faster fixed fans. I think it is the easiest way. And in my opinion, if you mining, never use automatic fan control.

It is not feasible to do so, power can be, but it is not appropriate. I have 6 rigs, and I use about 20 Algos. I have established about 100 OC profiles.

What you are saying is that you make another 100 OC profiles with a fixed fan speed. I'm sorry but that's Chinese work.

There must be simpler options than what is proposed, which for an RIG may be worth and even so, there would be several profiles, at least 2 for each SOMETHING.

When you use the GPU Clocking dialog and select Save As, you can specify which GPU parameters to save to the profile. You can for example save only the fan speed property set to a value like 85%. I can agree that the usability should be improved a bit here.

You can then have a rule to apply this "Fan 85%" clocking profile to a running miner. It will not change the Clocking Profile permanently, but it will change the fan to 85% for a running mining.

It should be possible to use the Clocking Groups to combine different Clocking Profiles as well. Not only about having different Clocking Profiles for different GPU types, but also to apply multiple Clocking Profiles to the same GPU - where one profile could apply Fan speed only and another one the GPU/mem clocking.

@Patrike, in the rules, you can know the temperature of the cards and put a rule. But I do not see that it works. The rule can detect the temperature, 80 degrees in my case, and I indicate that the fan works fixed at 80%, but it does not. It seems to me that this one more thought for asic, surely it would have to restart miner in GPU, but to do it also it lowers the temperature and the rule does not shoot.

There some way to do what I indicate, and to apply a fixed speed to all the cards of the rig, without having to restart miner ?, would be an ideal solution for this situation, and summer is near.
If this is the "Device command" action, it's only operations intended for ASIC miners and SgMiner - not for GPU mining in general. This is where you need to apply clocking profiles instead.




----
When you use the GPU Clocking dialog and select Save As, you can specify which GPU parameters to save to the profile. You can for example save only the fan speed property set to a value like 85%. I can agree that the usability should be improved a bit here.

You can then have a rule to apply this "Fan 85%" clocking profile to a running miner. It will not change the Clocking Profile permanently, but it will change the fan to 85% for a running mining.

-----------

as you say in those two paragraphs. What I propose is to create two equal profiles, one with AUTO and another with a fixed speed fan, and by a rule use it. I do that when the temperature reaches 84 degrees and change to a very smooth OC and if it reaches 85 the miner stops.

But when applying a rule I can only choose an OC to change. Whatever my OC, the rule will only change to an OC that I choose. It is not the solution I am looking for, since I use multiple OCs according to the AL-GO and the miner in question, I would have to make hundreds of rules, one for miners and for each personalized OC.

If you already know that you can change the OC in real time and really use it to protect the cards. I do not understand why there can not be a rule that only changes the FAN regardless of the OC configuration that you are using, which are many. It is only the FAN is not complicated, the rule can take the current data of the OC that is in progress and only change the value of the FAN of AUTO to a fixed Speed, as easy as that.

I hope you have explained me well.
The solution available today to set fan speed to 85% for a miner via the rules:
- Use rule action "Apply clocking profile", where you have a Clocking Profile set to 85% fan speed for example. That's the only property of the clocking profile so all this action will do is to change the fan speed and nothing else. No matter if you have few or many Clocking Profiles in general, you need one extra profile for setting only the fan speed to 85% in this case.

This could be simplified into the following in the future:
- Use a new action concept to "Apply clocking setting" where you could select that you want the "Fan" property to be set to 85% for example. This would remove the need of the Clocking Profile containing the 85% fan speed property.

There are no difference in behavior between these two ways, it's just that the second one doesn't require you to create a Clocking Profile for each fan speed level you want to set. In both cases, it's only the fan speed that is changed an no other overclocking settings.
jr. member
Activity: 756
Merit: 2
Use rules, fixed fans and 2 or more profiles. If the temperature reach 70°C for example make a rule to change to another profile with faster fixed fans. I think it is the easiest way. And in my opinion, if you mining, never use automatic fan control.

It is not feasible to do so, power can be, but it is not appropriate. I have 6 rigs, and I use about 20 Algos. I have established about 100 OC profiles.

What you are saying is that you make another 100 OC profiles with a fixed fan speed. I'm sorry but that's Chinese work.

There must be simpler options than what is proposed, which for an RIG may be worth and even so, there would be several profiles, at least 2 for each SOMETHING.

When you use the GPU Clocking dialog and select Save As, you can specify which GPU parameters to save to the profile. You can for example save only the fan speed property set to a value like 85%. I can agree that the usability should be improved a bit here.

You can then have a rule to apply this "Fan 85%" clocking profile to a running miner. It will not change the Clocking Profile permanently, but it will change the fan to 85% for a running mining.

It should be possible to use the Clocking Groups to combine different Clocking Profiles as well. Not only about having different Clocking Profiles for different GPU types, but also to apply multiple Clocking Profiles to the same GPU - where one profile could apply Fan speed only and another one the GPU/mem clocking.

@Patrike, in the rules, you can know the temperature of the cards and put a rule. But I do not see that it works. The rule can detect the temperature, 80 degrees in my case, and I indicate that the fan works fixed at 80%, but it does not. It seems to me that this one more thought for asic, surely it would have to restart miner in GPU, but to do it also it lowers the temperature and the rule does not shoot.

There some way to do what I indicate, and to apply a fixed speed to all the cards of the rig, without having to restart miner ?, would be an ideal solution for this situation, and summer is near.
If this is the "Device command" action, it's only operations intended for ASIC miners and SgMiner - not for GPU mining in general. This is where you need to apply clocking profiles instead.




----
When you use the GPU Clocking dialog and select Save As, you can specify which GPU parameters to save to the profile. You can for example save only the fan speed property set to a value like 85%. I can agree that the usability should be improved a bit here.

You can then have a rule to apply this "Fan 85%" clocking profile to a running miner. It will not change the Clocking Profile permanently, but it will change the fan to 85% for a running mining.

-----------

as you say in those two paragraphs. What I propose is to create two equal profiles, one with AUTO and another with a fixed speed fan, and by a rule use it. I do that when the temperature reaches 84 degrees and change to a very smooth OC and if it reaches 85 the miner stops.

But when applying a rule I can only choose an OC to change. Whatever my OC, the rule will only change to an OC that I choose. It is not the solution I am looking for, since I use multiple OCs according to the AL-GO and the miner in question, I would have to make hundreds of rules, one for miners and for each personalized OC.

If you already know that you can change the OC in real time and really use it to protect the cards. I do not understand why there can not be a rule that only changes the FAN regardless of the OC configuration that you are using, which are many. It is only the FAN is not complicated, the rule can take the current data of the OC that is in progress and only change the value of the FAN of AUTO to a fixed Speed, as easy as that.

I hope you have explained me well.
Jump to: