If a miner crashes, it does not stop normally. also does the reset of oc?

Another PAtrike suggestion. In the rules, which come by default use several, one that notifies me from time to time is when an RIG reaches a temperature of 80 degrees, although I stop mining to 84.

I do not feel like putting screenshot, but when it warns you it says something like

Rig5 High temperature warning

But, you can not improve that rule to tell me what AL-GO is. Many times I find that message, and I always think, what protocol would it have been? I do not know, or I'm in front of the computer when it gives the fault and know what protocol was undermining or I do not know anything. I only know that it warmed up a bit and it is already there, but I can not correct anything if I do not know that al-go was that temperature.

Thank you

Please do not take long to incorporate the solution please. I've had enough for the last 2 or 3 weeks.

I already found the RESET order, but make sure it also resets the millivolts, and that it is applied BEFORE starting to mine, because as I said, if it crashes, the output OC does not apply.

I personally would add this as something transparent. That is, the user does not have to configure or touch. That by default AM does it before starting to mine. The less the user has to learn, the fewer problems they will ask you.

First the miner reset, a few seconds later, the OC that has been selected for that Al-go is applied. It's something so simple and simple that you should not need a choice. Totally transparent to the user without doing anything, and we removed a lot of problems at once.

It seems good to me as you put it, a base OC or null that you specify it somewhere. And it will always be safer to run before mining, because it may end up crashing and not running, so having it reset before undermining and applying the user's OC is perfect. Make a normal stop or crash, when going to mine, along with the Start command the zero OC or reset and then the OC the user. The truth is that all this has driven me crazy.

Now for example if it crashes, it is very easy then not start well I have to be aware, and when the miner launches and before I fail, I give STOP to apply the OC output correcting the OC and millivolts.

I already have hardly any failures or problems. It has been hard for me to identify the problem. I do not have any fall of any miner, it could be considered normal But what happened to me until now was not normal, now I understand it and only those of us who handle so many options are exposed to have and discover failures.

Another failure. If I throw a coin with an OC that has a limitation of millivolts, and this miner crashes, the OC of stopping with the neutral OC does not apply. And therefore the limitation of millivolts of the previous currency remains again. When wanting to start mining again, as you go to another currency that needs more tension, the miner stays in offline miner in the AM interface

I think the most appropriate measure is to apply a neutral OC without limitation in millivolts before mining and before applying the OC that I have chosen. Then it will not matter if it has crashed.

After several hours trying to include an output OC with a limit of 1200mv volts 90 0 0 I no longer have the problem that both insisted and not many saw

It would be advisable that when you use functions for an OC, when you finish mining, return to a neutral state. This way you will get rid of questions and inconveniences for users.

Now I only have some miner failure due to OC times, I recessed and fixed it. But before if he used an OC with a low voltage, then he would stay, but when he switched from AL-GO to one that consumed more, he would not start the miners, and he would stay for hours and hours as seen in the previous captures, without giving an error , but without working.

Bug and solution

I have seen something curious doing tests. That does not have to happen to many if they do not use the OC module with all its options.

I explain. Imagine that I launch an al-go and this in your OC has a limitation of 700mv for example 700mv 80 power 80 core 500 mem.

When finishing this service, if I change to another one that does not have a volt limitation, for example 85 90 500, it turns out that AM, the limitation to 700mv is brought from the previous one. Since I have not specified a maximum limit, it continues with the previous one.

This forces me to put an OC to finish mining that has 1500mv 90 0 0 to make it more neutral, and if the next al-go has no limitation of volts, it has a very high limit.

I also notice that when changing OC in the tests, during the first reboots the data of the previous OC remains instead of the new selected one., I suppose that there will be some cache to support 20,000 platforms.
my doubt is that if AM should take the parameters of OC to normal, when it ends up mining an al-go, so that the next one does not have limitations that come from behind, or I will be forced to put the OC to finish with 1500 90 0 0, for me to leave the values ​​in normal numbers.

Those who use ASIC, do not have to use the OC, those who use free or small versions, do not have the control of advanced OC, and for that reason many people do not fail, they have an average OC in Afherburner and do not have this problem.

I have 5 restart and reboot in rig 6, which I have set to all the logs the output OC to 1500 90 0 0, and now it does not fail.

I think you're already having more clues to the problem. I have noticed looking at the profile of OC and although it had the normal values, in that OC I did not limit the Volts, but if I marked the limitation of 700mv of another OC different. And there goes the problem.

6 restart anf reboot, I have no problems. Please check the OC module and please, if a following OC has no mv limitation, do not leave it as it was before, because that is what is causing the problem.

after 6 manual reboot, and without changing anything. Run cucka29 with gminer in nicehash. without changing anything. This is what I mean, it's driving me crazy.

try with 1080ti or rtx2080 Cucka29 with gminer 1.47 the same one that you incorporate, with the Windows updated to stop. In 1070 it happens very rarely.  It happens a lot also with nbminer

That equipment is I5 with 4 GB (also fails in the 1080ti with 8 gb ram), ssd and left over.

Acabao to do manual reboot and again is with cucka29 gminer 1.47 in "online interface" and does not start. But it happens with MTP, but if you want to try, you can use cucka29 or 31 or cuckcycle but try better with cuckca29 since it is the most recurrent.

I understand that the online interface is that somehow the connection with the machine is lost, but even if the connection is lost, the miner does not start seeing it on the remote screen.

As I mentioned, it occurs with rtx and 1080ti to a greater extent. I have installed all the updates including the last corrected version of 10.1 of cuda, I also have the 9.2, all the visual etc ... Everything is fine and at times it goes well and at long intervals it goes wrong.

I have tried even with OC of 50 0 0 and leaving everything to 0. If it does not start, it is no longer a problem of OC, nor temperature, that no one else recommends me to look because I am not a novice and all that I have already reviewed.

The 1705 creator versions, for what they have told me in the group, work, less hash, but it works. It's the ones we installed 1809, and there's still another version that I have not installed because it does not leave me, the 19xx

I can not be seeing that some or miners, I use very few, right now tell you that I only use Nicehash with 7 algos, to minimize changes
cucka29
cucka31
MTP
cucacycle
x16r
equihash 150.5
zhash 144.4

I only use 3 or 4 miners, cryptodredge, tt-rex, gminer, Nbminer

When more happens it is with Gminer and Nbminer, in the Cucka and MTP

In the capture puts 82% of time of mining, is unreal, all the time that is as in the previous capture, online interface counts as valid. That's the restarts. That rig is RTX and today it would have had more than 50 reboot

I am writing you this 2 message and still follow the RIG 6 with online interface and it does not restart ... I am fed up with this situation.

This is not an error by OC, nor by heat, nor anything that affects me. Deactivated the antivirus and Firewall completely. This is just an example of a rig, it happens to me in more rigs, it happens to more people in more RGIS.

When it is in that state, it does not fail, it does not give notification, it does not freeze the machine, if the machine were frozen the whatdog by USB would restart it. You can stay for hours, until I realize and reboot, and even after reboot sometimes does the same and we are in the same failure.

It does not communicate well the remote with AM, it can be the administrator mode, or it can be the last updates.

I repeat, it does not leave error notification because basically until I do not reboot it does not leave there, it can stay hours and hours.

This is killing me, some machines do it more, others do less. But especially the 1080ti and the rtx 2080, although to a lesser extent also in the 1070.

The admin mode matches me (this affects the fan curve and the limitation of volts), if I do not affect the administrator mode.

This failure is happening a lot and it is making me lose a lot of time every day. I had to create specific rules that if there is no HASH during X seconds, reboot, but sometimes it does so many times until at the end a miner starts.

As I said, it's not OC, it's not heat, it's not my configuration, it's an Intelibreeze failure.

this is crazy. Now the remote fails me the installation in some machines, the other day in one, today in two. And the only way to fix it is to erase everything from awesome miner of REGEDIT, restart and install, otherwise, it will not let me.

Intelibreeze is accumulating errors, the program is becoming increasingly unstable and the proof is that I have never had problems with the updates but if lately.

When you want to realize, there will be many problems to solve.

Much development for Asic but you are leaving aside the windows and the errors that many people are reporting. I am dissatisfied lately of the resolution of failures in Windows and it is affecting me. Even if you lower the OC, or even if you leave it neutral 100 0 0 or 90 0 0, some rigs still remain in offline service or similar problems that did not happen 2 months ago.

Windows advances with its updates and the remote is giving problems, I mean intelinreeze.

I already answer you. It's not the OC, nor are the risers. It is the damn windows and its updates, something has to improve in AM to control this.

You can not undermine and indicate "miner offline" and reboot rig. It also happens directly by mining, PLASH and reboot if notice. And this already reducing the OC a lot.

Insluso some miners of abnormal form occupy 100% of CPU, so much that it makes the system fail. I have seen several times already Intelibreeeze the remote AM program, hanging using more than 30% of CPU (depends on the model, this almost i3)

It's not me, it's not the other guy, there are many of us who are reporting these errors and it's not my first summer with AM undermining, I know what I'm talking about. Low OC, a lot of ventilation, air extractors, direct air to the platforms, but they can be at 50 degrees and suddenly reboot for no reason or stay in offline miner and restart by the rule.

Obviously everything he suggests we have done. and Obviously we have to have a low OC that can withstand the hot hours, but the machines lower temperatures a lot at night and can
take advantage of those cirscuntancias.

You have already seen the temperature graphs the oscillations are 20 degrees less.

Point one that uses CTROL + C, where I activate that in AM, because I do not understand it in any other way. DOndende have to put it?

The pauses are long, since it stops until you mine again, it passes more than 1 minute for the delays to the change of OC, waiting time before mining etc ... We give time for the clocks to return to their place. We already know that high OC = problems, but that is not the case right now. And at a lower temperature lower OC, less mv, but being able to mine 15% more at night, because it seemed a waste not to do it well. PAra that I want now at night the cards to 58 degrees ??, that if, of day they are between 68-76 Degrees, something that I consider acceptable.

We have an OC of summer and another of winter, but we do not have a double OC for these changes brucos that we have in summer in the center of Spain.

Help me , very hot day    

Apart from dobe OC, both I and most of the people in my telegram have stability problems with the RIGS, are frequently restarted on Offline or simply when the currency changes, depending on what the miners will be, they stay offline and by a rule reboot miner ..... I hardly use the auto profit to avoid currency changes, and just the auto profit is one of the great qualities of AM.

I still think it's a Windows problem, but we'll have to adapt what needs to be fixed.

we talk about not complicating, I think my suggestion is much simpler to handle, without more. I will only have to update these schedules 2 or 3 times a year. Then in each AL-GO if I only have 1 OC defined it would always be the OC of the day that would work, if I have defined OC for the night, it would be activated with the time that you specify for the night in options.

I do not need more features on this and basically you will have the best OC module in the market, with functions that Aftheburner does not provide for example. The heat has to be fought. Right now it's 18 degrees at 2:48 am, and we've reached 36 during the day, it's just half the temperature.

Patrike tip in case you decide to put double OC Day / Night

It's just in case you do it. I think that when defining the hours of night and day, only do it in a single place in options. And do not do al-go to al-go.

So in this way changing the time to all OCs at night or day would be done only from one place and not one at a time.

It's just in case you decide to do it. You can add it in Options the choice of night / day schedules.

GMiner v1.46 available for download

v1.46
+ added ZelCash Equihash 125,4 algorithm for Nvidia cards
+ improved Grin29 / Swap / Aeternity performance on Nvidia cards, specially on GTX 1080 Ti, also improved hashrate on pool side

Download links:
GitHub: https://github.com/develsoftware/GMinerRelease/releases/tag/1.46

I just tried the fan curve system for OC, and say that it goes silky, perfect, now if you consider each card separately.

Those who use Aftherburner for the fans, you can already remove them. I have already done it and I only use the AM system, the fewer things installed in the rig better.

Thanks Patrike for your continued effort. I'd love to see the double OC night / day, but that's your decision.

PAtrike already sent you 2 internal messages with 3 logs so you have all the possible information.

I'm pretty sure that the failures are causing the latest security version of windows version 1809. It is easy to ask here if those who have older versions of Windows like the 1705 have problems with restarting the machines and if those who have updated the windows today have the problem.