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

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.

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

Patrik,

I just want to say thanks for the new multi-GPU-benchmark. Extremely useful now, awesome!

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

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.

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.

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.

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

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.

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.

----
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 problem I see with the overclock groups is that I should do many, but many. I already have about 100 individual profiles, type

85 90 +400
85 85 +400
85 85 -400

PL - Core - MEM

and they are called like that, and then from each miner in each protocol or AL-GO to be able to choose an OC that just by reading the name on the OC that I am going to apply. But do 100 groups and customize card to card is not an idea, because then a group would only serve for a rig in question, for their cards and their independent oce. At the end there would be many more groups, a lot of extra work

I have no choice but to work with fixed speed, but it seems like a savage to have 80% a whole year a fan, that's why I like the automatic one more. What I propose are two easier solutions for everyone.

At the time of defining an OC, I know that I can choose either fixed or auto, but inside the car there could be a box marked something like "aggressive" where the AUTO is higher than normal. Or a rule that really works in real time with the rig GPU without resigning.

With aftherburner if you changed from auto to manual the fan, it did it without stopping to mine, because you can not do that AM through a rule ?. They have already passed the Nvidia documentation on the commands they use, sure there is a way to do it.

That will allow an automatic use of the fan, and only if a card exceeds the limit, raise the speed to the whole rig, without having to restart mining. Creating Groups is not feasible for me having more than 100 profiles already made of OC, and OC groups are taking into account card by card, which would be many more. There must be something simpler, Just for that reason I'm rethinking Aftherburner although I know it has problems, but I can define an aggressive line of Automatico and leave the problem aside, but then every X time does not work and I have to change the folder The remote server is very messy.

If all my rigs were equal, their option would be valid, but since each rig is different in card and power brands, I can not stop making OC groups that should be customized to that rig, and then other dozens of OC groups to another rig etc ...

Could this be that you have one default SSH username and password defined in the Options dialog, Mining Settings section, and then the SSH action is configured for another password? Leaving the username and password fields blank in the SSH action will result in the default settings being used.

The username and password can also be configured per miner if needed.

If you run into a failure with the reboot, you will typically see some details about the issue in the Awesome Miner log file. You can go to the toolbar Tools -> Log File right after you run into one of these failures to see if you find more details.

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.

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.

Thanks! I was looking too fast at the screenshot in the original question and only noticed the incorrect uptime. I didn't notice the more issue related to the personalization string as you pointed out. The next release of Awesome Miner will correct both these issues.

Hi Patrike
I have a problem with rebooting the external miners through rules. i guess this should have been answered already but the search didn't help and I'm not going to read through 470+ pages.
the problem is when I set rules to reboot my antminer S9 by ssh command->reboot system, the rule is triggered, even the notification which i have set for the action will pop up but the reboot action does not happen. more interesting is, when I select the miner and go through tools-> Antminer & ASIC-> reboot (via SSH), that works and the miner reboots pretty awesome!

would you or any other friend here help me with this problem? or could you please tell me how i should write the custom ssh command for the rule to reboot just like the "reboot (via SSH)" function?

thanks in advance

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

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.

See the recent dev releases, currently you can already add dynamic updates to difficulty, block reward and soon after next major release addition of nethash, block time + specifying calculation method will follow suit. so soon you can do this all in AM.

hi, you must set --peers auto. See image

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