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

Makes sense. Thank you.

Awesome Miner version 6.6.2

 ASIC mining
  - Feature to send custom web commands to an Antminer
 Mining software
  - Added mining software: NoncerPro 3.0.2
  - Nanominer 1.4.1
  - Miniz miner 1.4o
  - CpuMiner-Opt 3.9.5.1
  - Lolminer 0.8.3

Please note that we make many of the mining software updates available even before these releases - via the 'Update mining software definitions' feature.

Ha, never thought about those tricky hashrate multi-check-rules, but will do now Thanks!

Sometimes if AM switch from one miner to another, one or some devices are "lost" for a second and all the alarm rules will trigger. Maybe you have a better solution for this scenario, would be great.

For the hashrate, you can actually add multiple "Check statistics" triggers - one that is looking at the current value and one that is looking at the hashrate value 1 or 2 minutes ago. You can then set your rule to only trigger if it matches both these conditions. This makes it possible to not trigger it too frequently.

For Device Count there are no feature like this, but I understand your suggestion for this one as well. Thanks!

Hey Patrik,

sometimes rules like "Detect device hashrate, less than or equals: 0 kH/s" or "Detect device count, less than or equals: 2" or similar others will trigger, although actually not necessary because it is just a quick hashrate drop or a miner bug or anything else, but gone in the next second. But the rule is already triggered...

Is it possible to add a trigger like "For (at least): X Seconds"?

This doesnt make sense everywhere, but for a few rules it can be a great improvement. The 2 rules above would now look like:
"Detect device hashrate, less than or equals: 0 kH/s" "For: 10 Seconds"
"Detect device count, less than or equals: 2" "For: 30 Seconds"
In the case above the rules wouldn't have triggered because they are now in the limit.

The Temperature Limit you can define is a way to tell the nVidia drivers that they should enforce the limit. Awesome Miner has no control of how this limit is enforced. It's also the same as if you use other overclocking tools, they can also only set the limit but it's up to the nVidia drivers to do the actual work.

Like you point out it might be that the clock speed is lowered significantly. I suppose this is a balance between setting a low clock for a shorter period of time vs setting just a little lower clock for a longer period of time. I don't know if there even is a manual way to configure this behavior for nVidia.

You should be able to use Clocking Profile Groups (Options dialog, GPU Clocking Profiles section) to define for which GPU to apply a certain Clocking Profile.

In the past you could only specify by GPU ID or GPU Name (like 1080), but in recent version you can also specify by vendor (ASUS, MSI, ...) which might be of help here. You can for example have one overclocking profile set for all ASUS cards and another one for the MSI cards. If you have multiple types of MSI cards (Armor and Gaming) there are however no solution except using GPU ID's.

Unfortunately I don't have an answer to this - but there might be someone else in the community that are more experienced with extracting data from block explorers.

To run a miner as administrator, please right click on the miner, select Properties and then go to the Environment section where you can enable the Admin setting.

AMD is not reporting as accurate power usage values as nVidia do. For this reason Awesome Miner is by default adding 35% to the power usage to make it a bit more realistic. You can change this in the Options dialog, GPU settings section. If you set it to 0%, Awesome Miner should show the same value as nanominer - but I also think that would be less realistic.

Good that the overclocking is working better in general.

For this scenario you report, can you please send me both the Awesome Miner and Remote Agent log file. Please send via PM or e-mail to not share all log details to the public. Thanks!

https://www.dropbox.com/s/9l06keakjz9hqno/WhatsApp%20Video%202019-07-03%20at%2007.40.06.mp4?dl=0

@PAtrike watch the full video the surprise is right at the end, it lasts little.

If you see that rig you have one or two hot cards. They are already revised, I have done maintenance and I have even changed the heat sink kit for an Artic cooler IV, which is much better, but they are cards that are forced.

If you look at the second card, the 01. You will see how it changes too many times of core frequency, the fast changes feel very bad to the 1080ti, and at the end of the video you can see how in 3 seconds it goes to 1900 mhz and it suddenly drops to 900mhz.

That's like headless chicken, it goes a little crazy. Take the temperature in real time and act, and should have a bit of hysteresis.

For example, I set maximum temperature 76, when it reaches 74, it drops 100 MHZ, if it reaches 75 it drops another 100 MHZ, (always leaving a minimum time of 10 seconds between changes that gives time to the relog of the 180ti assimilate the changes), if it reaches 76, another 100 MHZ. And go looking for a frequency little by little so that the rest of the mining remains fixed, if at 1100 mhz it is stable between 75 and 76, there is no need to make changes unless it reaches 77 and you drop 100Mhz (100mhz it's an example).

Its objective that once reached the temperature more or less limit, stays more or less stable in a fixed frequency, and not changing to the crazy thing. Look at the other cards that do not heat up as they stay within a small range.

What can not be that when you lower two degrees, release again and go to the maximum in this case 1900 mhz and suddenly fall again in 3 seconds to 900. As a result the Rig falls often, some cards after a restart miner, they stay at 0. THE source of food suffers with such drastic changes

You should look for the best way to try that when you reach the temperature limit go down the MHZ of the core, giving ample time (about 10 seconds) between changes of MHZ, and never a change to more or less, be as huge as 900 mhz. And look (you will have to improve the programming) a core that in that situation remains more or less stable. It may take 5 or 10 minutes to get it, but it can be done.

Small changes in advance and with time to spare between them, to find a core to leave it more or less fixed. What I see are abysmal leaps. That card usually works at 1400mhz and the rest at 1200, that's one reason why it heats up, another reason is the model itself. But two rigs that I have with 1080ti have the same bad behavior, and I'm sure that if many people use this function, it will have problems like me constant restarts when I reach the temperature limit. There to give more stability. The idea is good but you have to develop it better. I'm sorry to be critical, but it's to improve your product.

It seems that people only know how to complain but they do not look for the problems and they do not report them through the forum, nor do they want the people of my telegram channel

I have people who complain to me every day and I always tell them to post here with images and data to give you information, but it seems that I am the only one in the group that does it.

I hope that the video encourages you to see that Core is a bit of control and that destabilizes the rig, being many and fast, and some of a lot of difference, you have to look for a more or less optimal value and leave it almost fixed, you can not oscillate so much. IN the 1070 is not a problem, but the 1080ti are super delicate with this, that's why we have delay options when we apply OC to start the miner.

I want to give more data on the limitation of temperature and its bad behavior in 1080ti. I have already commented on some problems

Now I add that sometimes it makes cards disappear. Reboot all the cards come out, it works, it restarts several times the miner when it arrives and it is for a while at the temperature limit (only 1 card) and after a few reboots cards are lost. It's like going crazy to the power source.

The only way to correct it is to go in person, turn off the power supplies and wait a while. Then you turn on and on again all the cards

In another rig after a few restarts, leave a card at 0, always mark 0 temperature, but if mine and gives HASH but without temperature. With which you can not control the temperature.

So for now the limitation of temperature has to improve and it does not work for the 1080ti, it should make the changes smoother and little by little and not so much change of big core and also many changes of core constantly. It is normal for the source (RMX 1000W corsair x2) to run out

NOTE; it does not happen in the 1070 or in the RTX for now, I have only observed it in 1080ti, but they are the hottest cards of all the ones I have.

I just tried and it works well. If it is true that controls the core for each card to control the maximum temperature. But it does it in a very abrupt way, it goes from 1600 to 900 suddenly, then it goes up to 1200, then it goes down to 900, and so for a while.

As a result the Rig with so abrupt change of core at the end falls and is interrupted continuously. It stops the miner, then starts (without failing notifications), and of course it is worse. I'm talking about a restart every 4 or 5 minutes on a constant basis.

I think the idea is good but it has to be a bit more refined, to do it in a softer way to avoid so many big core changes continuously, and to be able to find a core value quickly that works to maintain the temperature, could make more changes small of core, not 500 mhz of blow, perhaps 100 in 100 and leaving a few seconds in between.

The 1080ti are problematic and very delicate. For example in MTP I invest in 85 90 500, now I am with 70 50 300 and limitation to 76 degrees, but the core of the hot cards changes so much and so fast that it produces multiple falls of the mine, it recovers at the moment, but not It can be like this.

@patrike you could debug this maximum temperature function. The idea is very good but I think the changes are very big and frequent, it could be softer, but little by little. I hope you consider it.

regards

I did not know that the OC temperature limit option was to limit. I mean I understand that if a card reaches the limit of temperature that you mark. automatically only that card lowers the frequency?

I am going to try

that's some crazy temps. why don't you just set your Temperature limit at 70-75 degrees?
then your GPUs will throttle itself and decrease the core clock after reaching that temp.

Hello Patrike, I have a doubt in the auto profit mode with the OC.

I have rigs that are multi-brand, each card is a different brand but they are all 1080ti, but there are some brands that go with too much factory OC.

So the problem that I have that only one OC for all the cards is not valid for me. While some are at 65 degrees another one reaches 84 and stops. They are the MSI ARMOR with a special Artic ventilation kit, and I can not use them. They have a very high CORE. If under the core so that only that card is not hot, in the end the rig produces me less, I have a card at 77-78 degrees and the others at 65 or less.

I do not see that there is a way to save OC profiles, in which each card can have its own core, memory, power, limitation. I think in managed if you can, but in Auto profit no.

I think this is a situation that can be given to many people, that one card gets hotter than the rest and you have to lower the general OC, instead of defining for example a profile for "Rig5 MTP" "RIG5 X16R" with which could reduce the core of MSI armor but leave the others with more power because they do not heat up as much.

It would be a perfect scenario to make totally personalized profiles, and it is as easy as making a general one and when you have it, you modify it card by card, going to the one that gets hotter and only that lowering the core enough so that it does not overheat. And the average hash of the Rig would be greater than if under the OC to all the cards.

I have changed the thermal paste, the thermal pads, I have put the best air cooling kits that is Artic Cooler IV with huge rear heat sink. But seeing Clocking in AM, I see that these cards are 100mhz higher in the core than the other models. This is a huge difference.

It is a lot of work to make fully customized profiles to several RIGS for each al-go, but the work does not scare me, so there is no possibility of doing what I ask. It would be the perfect option to finish the OC, even forgetting about the double OC that I asked, because this is a much more serious problem for me. In winter there are no problems with this because the air of the street is very cold, but in summer you can notice that difference of OC in a single card.

Hello

How to get the complexity and the current nethash from the Explorer https://explorer.web.sero.cash via a get request?

Whats the easiest way to run the nano miner as admin through AM? when i turn the software on, it says i should do it.

im also getting 2 different power output readouts on the graphics card. AM says a card will be 90w, but nanominer says 67w. which would be more accurate?

https://www.dropbox.com/s/xtdn96v5x0pb8ti/Captura%20de%20pantalla%202019-07-02%20a%20las%2013.40.52.png?dl=0

The general problem of OC has gone well, well I still have the OC of outputs set to 90 0 0 1200MV, but I will remove them.

Now if we can focus on some small problems that are still better.

Here I leave you in the capture, RIG6 "offline interface" but it is working. It is not always like that, sometimes it does not work. But you can throw hours like that, working but at a slow pace. It occupies so much CPU that it does not allow me to enter the RIG remotely. In this case and the lack of information, I only know that it was Gminer but I do not know the al-go that was being mined.

But note that neither temperature, nor profit, nor anything, everything in a vacuum but working. I have activated the default rule in AM for devide offline, but sometimes it goes into a loop several times.

It is a lesser evil compared to before, now it is possible to work better, but they are problems that a few months ago did not exist, and it is not a rare miner, it is Gminer. The rig is the RTX, but after restart everything goes correctly. But I'm worried that it will stay that way and go at a slower speed, I already commented that it occupies so much CPU that it does not let me enter the RIG by remote, with which its mining performance is also lower when this happens.

Yes, no matter if the miner crashes or is stopped manually, the OC parameters will be reset. So if the miner crashes Awesome Miner will first reset the OC, then re-apply the OC settings you have defined for the miner/algorithm as "Start profile" and then start the mining software again.