I access perfectly and I also have all the firewalls turned off, and I say all because the general and the defender are there, each one separately.

Rather it was commenting on if there was something easy but if you tell me it would be complicated, then I am satisfied. I'll look somehow the middle hash to put it by hand. I imagined that the auto profit was going to be difficult to modify by taking the benchmark reference. I leave a suggestion to see if it serves you. You can use an average of (benchmark + current hash) / 2 for Auto profit, so you have a very real average, you combine the saved hash + the hash generated at the moment divided by 2 to have a mean. It will always be a more real approach than just the benchmark. It's just a suggestion that I just came up with, it could be used for the whole year. The bad things are the algos that are extremely variable like x16r. Well it's just a suggestion, I understand how difficult it is and I understand that it is not done.

I am more interested in reducing power instead of Core, or even a mixed system, that works the same as the current temperature limit but primarily reduces Power and with less emphasis on Core. The point is to control the temperature with the lowest hash drop. There will always be a hash fall, it is inevitable, but according to my tests at hand, the hash suffers much less reducing power to that card, as it continues to maintain the CORE and is sometimes even able to keep the hash almost intact. But with the reduction of core the hash always falls.

The idea is as simple as putting another temperature limit option, that there are two, one for Core the current one and another for Power as I suggest, it has no more problem. Instead of 5 in 5 jumps it can be shorter steps like 2 in 2, or 3 in 3. But I tell you in tests that I have done by hand, many times the hash does not suffer just because the core is still intact and the temperature drops by power reduction. I also see it very interesting

As always I try to be constructive with my suggestions or criticisms, and I think that your system is the best in the market.

Finally, I still have some online interface problems but really if it is working, that is a direct problem with intelibrezee, I am already using windows 1903 which is quite stable. I have greatly reduced that error with this version but it still continues to appear and you have to restart once or several times until AM reads that remote well. Because I understand that this problem is remote.

OFF topic --- Someone knows of a technician in Europe to be able to send you two graphic cards, a 1070 and a 1080ti to repair. You have to be a good technician because here in Spain everyone does reballing and that is not the problem.

I ask here being off topic, because we are all miners and with many cards, surely someone knows someone who fixes the Nvidia. and it has to be in Europe for the shipping cost.

Thank you.

I'm more advanced in that, I usually get the difficulty and hashnet of the same explorer of each currency, and if I can not because some explorer are complicated, the apis of some Exchanges, this could also add patrike, and if not, then before that no calculator would use the Whattomine data. But whenever you can use the explorer data

For Eaternety:

Difficulty: https://whattomine.com/coins/297.json
query: difficulty

Hashnet: https://whattomine.com/coins/297.json
query nethash

For price:
https://www.binance.com/api/v3/ticker/bookTicker
query: [? (@. symbol == 'AEBTC')]. bidPrice

in this case this currency has an explorer that does not give api, so the most reliable I found was WTM, remember to customize the currency, put reward and lock time
I think it rewards 368 and lock time 180

And choose the formula that is not exponential.

The problem of Aeternety, are two: one that pay once a day in almost all pools, and the second that most exchanges can only sell a minimum. With which from mine until you sell can spend 1 or 2 days or more.

With those data, then you must put the profit at 0.90 because I already did the test. And with all this you will always be close to the price, with difficulty and hashnet almost in real time, but WTM is in this case the one that best gives the data for lack of a better place.

Then there is another secondary problem.

The auto profit does it according to the benchmark profile or to save the Hash.

But of course in my profile it puts 8.22 in cucka31, but in the day it does not even reach 7, but it does not change the currency because what it sends is the saved hash, not the hash that is being produced.

That is the important thing to be able to have a better solution for the temperatures, because it is not only the fact that it yields less, but also that it is more serious because the auto switch does not look at real parameters (impossible for X16r for example), but I want you to understand that problem

A Rig produces X power in a Something, but when that Rig in summer by temperature yields 20% less, it does not take it into account. Somehow the programming of the auto switch should know if that rig has 1 or several cards of reduced core or power, and automatically apply to the hash saved a transparent reduction, so as to better guess with the hash changes produced by the heat. It would be something to keep in mind. It is clear that if 1 or more cards are in the limit of temperature, low pontencia and the hash they get is not the one that is saved as a reference, but knowingly, you can apply a transparent reduction to that hash when one or more cards are in maximum temperature, because they will not be producing their maximum. I hope you understand what I mean.

Right now the auto profit with the function of maximum temperature lowering the core and dropping the hash, is not realistic in its changes, and keeps me in currencies that are not the most profitable at that moment because of the heat.

Hello Patrike, I have more suggestions on temperature control, and problems.

I have suggested a double OC, but it would be too much, I suppose, for 4 months of heat, that is, 1/3 of the year.

I am using the maximum temperature in OCs, but it has a big problem. If I put a generous OC, many cards reach the limit and start falling from Core, and as a result the rig yields much less because when you lower the core, it yields less, much less. Only at night goes well when temperatures drop.

If I put a very smooth OC, I will not reach those temperatures day or night, but it would also be producing less hash.

Lowering the core is very effective but produces a too strong drop in the hash, so my suggestion is:

You can do the same but instead of downloading the core in real time, whatever you reduce is the TDP or power of the source to that card. That also reduces the temperature but does not produce such a strong hash drop. In fact, it can produce more because it does not heat up and the core is not lowered. Or a combined system, that lowers a bit of core and a little power or TPD from the source.

A real example, the same night rig Cucka31 8.22 mhs, day 6.2 mhs. If I put a soft OC so that neither day nor night comes, I would stay at about 6.7 -6.9 mhs

That's why I asked for double oc, but I think that a system that drops the Power to each card by independent in steps of 5, would be fine.

What is 80 power 90 core, 500 memory. Well I get down to 75 90 500, that is not enough I would lower 70 90 500. The lowering of electric power, does not drop the hash as much. But the same as the core, card by card. I do not know if you can, if you can please you can add it as an option in the OC.

And it is impossible to have a single CB that serves both the day and the night without losing hash.

nbminer
ttminer
gminer
t-rex
cryptodredge

The new version of nicehash has already appeared, although I have put the new wallet of the new version, it continues telling me in the previous version. I have seen that there is an api key in new.nicehash.com that I think is necessary to undermine in the new version, I do not know if I'm wrong.
@patrike could you check it?

Gminer already has several versions that does not work well in my rigti 1080ti and RTX 2080. It starts, detects the cards and randomly or stays stuck there for hours without undermining, or mine well. The only thing is reboot al rig. I am a user of Awesome miner and we recommend not using Gminer to the thousands of users of this program.

It occurs in the cucka and 150.5 and in some more, and it is not the OC, because it reboots and usually works with the same parameters.

Very much 2% Fee for such an unstable miner. I hope they can solve it because in the end the ones that lose the most are them, the less people use Gminer, the less they earn for the FEE. In its place for the Cucka I have to use nbminer that yields less but never fails.

I was able to save the Hashrate.

I do not blame you or AM for Gminer's problem, which is not your problem. But surely you can talk to the developer and tell him what happens, basically it happens in 1080t and RTX. You will pay more attention to it than if I post it in your forum, you represent thousands of users who stop paying the FEE for not using their miner.

I have reached a point that I had to change Gminer for NBminer for the cucka`s.

Please let the Gminer programmer know, because it works or does not work, but sometimes if and sometimes not, it's crazy.

Out of this, everything normal in AM, all good, fluid and without problems. The big problem is using Gminer in some algos.

https://www.dropbox.com/s/widgqqmljfd5fhw/Captura%20de%20pantalla%202019-07-08%20a%20las%2015.48.41.png?dl=0

I do not understand you completely Patrike.

Let's see, I AL-GO is only once in the list of algorithms, I did not add it, it was already 125.4 so it is not duplicated or tripled.

What I do have are 3 ZEL coins, old Zel 144.5, the manual added by me in 125.4 and the one that Cointomine added afterwards through its api.

It does not matter if you have 3 or 4 equal coins, if you are mining at 125.4 and I give save hashrate, do not record it, and I repeat as al-go there is only 1 that you added. I have no way to save the ZEL Hash

For me it is not a trauma, because ZEL with the new al-go that gives less hashrate and after measuring it 0.6 of profit, is a NOT PROFITABLE coin. But even so, I'm worried that the program will be full of small failures.

What do I have to do to erase the coins and leave only one ?, I have coins up to 4 times equal with 4 different wallets and I have not had any problems with them. As AL-GO, it is only once. so I do not understand the problem of not being able to save the Hashrate.

It does not make sense, no matter how many copies you have of the currency, you should keep your hashrate. I have already deleted all but one, the one that gives cointomine but with all the custom fields dynamically to have fresh data and not those of CTM that are late and now DO NOT WANT TO MIN.

It is the usual error, especially happens with Gminer in the machines, it remains as it is in the capture that I have put. Service offline, it stays what you see in the console, until it reboot the RIG. It is a problem that is making me very tired. Basically, it only happens with Gminer. has done reboot twice and the third has worked and is undermining. This is where we look more calmly because we still have problems


Now with only 1 ZEL if he has been able to save the HASH, but I see it as illogical. We continue with the problem of offline miner with Gminer, I'm pretty fed up.

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

As they say there is a problem when saving data with coins.

Zel has passed to 125.4 I have created the coin by hand from coins and also cointomine has already added it, but in both cases the least manual and dynamic data, (difficulty, nethash, price, etc.) but when I mine and give save hash, right button "save hasrate" if you save the HASH in the miner. I go to the miner I see 125.4 and save the hash. But the problem that the coins in COINS do not keep the hash, with which the auto profit is impossible.

There is some failure when saving the hash in the ALGO. As you will see in my capture, I have 3 zel, the old 144.5 and the two d 125.4, custom and cointomine. I have tried both, and in both I have saved the HASH, as I say in the miner I enter Equihash 125.4 and if the hash appears, but not in the coin as seen in the capture.

Please fix the problem.
---------

Another comment for some of above. The ZCOIN ccminer for MTP, is for nicehash, it is a compatible version for nicehash according to its gihub, but it really does not work on nicehash. I do not think the ETHpill is going to work because it is designed for Ethash algorithms, not for the MTP algorithm, I think you are a bit confused, the one that has said that, I do not think you have much idea of ​​what it does.

If we look at his Gihub says it gives problems in many mics and configurations, in my case failures in 1080ti and RTX. And I repeat is a ccminer adapted to nicehash, please read things before saying false claims. What does ETHpill have to do for Ethash algos with something MTP ?

I do not see the advantage of ccminer Zcoin for MTP. I'm using Cryptodredge. TTminer is faster than cryptodredge but less stable, but not rejected.

It gives many errors to connect, then it has many rejected with the same OC as cryptodredge. It is based on an old ccminer. And its performance is less than Cryptodredge, where is the advantage of using this ccminer?

It also gives validation errors per CPU and closes.

or really something I am doing wrong, but this is only link the miner and mine, does not have much else, unless there is some configuration that escapes me. I am using cuda 10.1 or this is the cuda that chooses, I have 9.2 and 10.1

In RTX I have i5 should not fail, in others I have G4400 or i3, I say this because of the notice in Github of the miner https://github.com/zcoinofficial/ccminer/releases that recognizes stability problems. Indicates that in some cases. Well I 4 of the miners that I can use for MTP, it does not work, from G4400 to i5, or 1080ti or rtx 2080 or 1070. So it does not seem at all stable, at the moment it starts, if it connects with nicehash or It gives a lot of reject or CPU validation error and always reboots itself. So I'm still in Cryptodredge.

If someone has information on how to solve it, I would appreciate help.

Hi PAtrike, you have added CCminer Zcoin for MTP, it comes out correctly in Options> managed software. But then it does not appear in the list of Mineros available in each rig. I've searched for it 1000 times and I do not see it. It is as if the miner had not gone over to the rigs in order to use it.

I think I'm not the only one who happens the same.

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

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.

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.