Hash Auger 2.9.7.5 Mining Manager and Switcher for NVIDIA GPUs

[trucobit]

I have done the full benchmark before optimizing my 10 protocols. Neoscrypt has not been made with DSTM and I have it marked, when the benchmark finishes I close the application so that the data is saved. Then I open, I choose to mine Equihash and it closes.

I leave a video where you will see that the RIG1 can not work DSTM, is 4x1060 will see how it closes, and does not do the bencmark, then I throw it in the RIG4 which is 1050 and there if it works, but PHI does not work

So there is something to improve, something has changed since 1.8.2 where that problem did not exist.

It is not a question of making the benchmark, it is that neither happens nor does it. And the strangest thing is that a rig behaves in one way, and another in a different way.

https://www.dropbox.com/s/pb62x4wmbk20sr9/IMG_2234.MOV?dl=0

DSTM has nothing to do with Neoscrypt since that miner only supports Equihash. If DSTM isn’t benchmarking, it is usually because the software skipped the miner because MiningPoolHub is not enabled. There is a warning message that appears that is pretty clear about this requirement. Also, each miner is benchmarked for a limited time, so if a rig doesn’t find a result during the specified time, the hash rate will be zero. Since the process is dependent on the capabilities of the current hardware and the pool's current difficulty level, it is reasonable to think that they will not always find a result for some algorithms during the time allotted to benchmarking process.  I made a couple of changes in 1.8.4 to how DSTM is benchmarked to account for these factors. Now that Equihash is available on Zpool - it wasn't when I first added DSTM to the software, it can be used to benchmark DSTM instead of MiningPoolHub. Also, the benchmarking time for DSTM will automatically increase if a result isn't found within the default time period. This way, the time it takes to benchmark won't be unnecessarily be extended for users with faster GPUs, but it still increases the likelihood that the miner will be successfully benchmarked during the first attempt.

As I mentioned previously, you could manually type in a hash rate for Equihash and re-select DSTM as the preferred miner and it would prevent the issue while I finish testing 1.8.4 - which fixes the issue. Again, the only issue here is based on trying to manually mine  an algorithm that hasn’t been benchmarked yet.

But because miningpoolhub, I have activated Zpool that has equihash (I was wrong before remembering the protocol). If I have activated Equihash in Zpool I do not know why I need miningpool hub. In the other rig he did and I have never activated mininpoolhub. Is it necessary to activate it to evaluate equihash ?, I can not believe it.

If the message I have repeatedly seen it down, but I thought it was another failure.

And what is not normal is that it closes suddenly. In the other rig I could not work with PHI, it always closed. In short, there are a series of problems that must be corrected and that still do not make me comfortable with it.

because it is not evaluated does not mean that it is suddenly closed, that is a programming failure, since it occurs in more than 1 miner and it did not happen in previous versions. Put a manual value is a fudge, should give an error on the screen warning perfectly, and I do not think to evaluate Equihash have to use necessarily mininpoolhub, when I have it in zpool

[HashAuger]

I have done the full benchmark before optimizing my 10 protocols. Neoscrypt has not been made with DSTM and I have it marked, when the benchmark finishes I close the application so that the data is saved. Then I open, I choose to mine Equihash and it closes.

I leave a video where you will see that the RIG1 can not work DSTM, is 4x1060 will see how it closes, and does not do the bencmark, then I throw it in the RIG4 which is 1050 and there if it works, but PHI does not work

So there is something to improve, something has changed since 1.8.2 where that problem did not exist.

It is not a question of making the benchmark, it is that neither happens nor does it. And the strangest thing is that a rig behaves in one way, and another in a different way.

https://www.dropbox.com/s/pb62x4wmbk20sr9/IMG_2234.MOV?dl=0

DSTM has nothing to do with Neoscrypt since that miner only supports Equihash. If DSTM isn’t benchmarking, it is usually because the software skipped the miner because MiningPoolHub is not enabled. There is a warning message that appears that is pretty clear about this requirement. Also, each miner is benchmarked for a limited time, so if a rig doesn’t find a result during the specified time, the hash rate will be zero. Since the process is dependent on the capabilities of the current hardware and the pool's current difficulty level, it is reasonable to think that they will not always find a result for some algorithms during the time allotted to benchmarking process.  I made a couple of changes in 1.8.4 to how DSTM is benchmarked to account for these factors. Now that Equihash is available on Zpool - it wasn't when I first added DSTM to the software, it can be used to benchmark DSTM instead of MiningPoolHub. Also, the benchmarking time for DSTM will automatically increase if a result isn't found within the default time period. This way, the time it takes to benchmark won't be unnecessarily be extended for users with faster GPUs, but it still increases the likelihood that the miner will be successfully benchmarked during the first attempt.

As I mentioned previously, you could manually type in a hash rate for Equihash and re-select DSTM as the preferred miner and it would prevent the issue while I finish testing 1.8.4 - which fixes the issue. Again, the only issue here is based on trying to manually mine  an algorithm that hasn’t been benchmarked yet.

But because miningpoolhub, I have activated Zpool that has equihash (I was wrong before remembering the protocol). If I have activated Equihash in Zpool I do not know why I need miningpool hub. In the other rig he did and I have never activated mininpoolhub. Is it necessary to activate it to evaluate equihash ?, I can not believe it.

If the message I have repeatedly seen it down, but I thought it was another failure.

And what is not normal is that it closes suddenly. In the other rig I could not work with PHI, it always closed. In short, there are a series of problems that must be corrected and that still do not make me comfortable with it.

because it is not evaluated does not mean that it is suddenly closed, that is a programming failure, since it occurs in more than 1 miner and it did not happen in previous versions. Put a manual value is a fudge, should give an error on the screen warning perfectly, and I do not think to evaluate Equihash have to use necessarily mininpoolhub, when I have it in zpool

Thank you for confirming what I have suspected for a while now: that you simply do not read my responses.  In the reply that you quoted, I explained that MiningPoolHub was the requirement because Zpool did not offer Equihash when I originally added DSTM. In that same reply, I also mentioned that I added Zpool as an alternative to MiningPoolHub when benchmarking DSTM in the next version.  Likewise, that same reply also includes my confirmation that there is an issue in the software (that will be fixed in 1.8.4) when you try to mine an algorithm that hasn't been benchmarked. This is the third time I have said this, but you have ignored it every time and continue to post videos of the same error. It is all right there in my message that you quoted had you actually bothered to read it.  The fact that you assumed a warning message was a programming error fits with your attitude about the software and your tendency to exaggerate errors and spread misinformation.  

[HashAuger]

Do you think you can give us a button to switch miners(software) if that happens when mining just to see if that solves it or not?

Instead of a button, I modified the handling of miner errors to automatically switch over to an alternative miner if the preferred miner has repeated problems with a particular algorithm. However, the software does wait a few minutes before identifying the situation you had with the miner not being able to find a result as quickly as it normally does.  Those situations are not as obvious as communication failures or miner executable crashes, so the software has to analyze the miner output for a while to determine that a problem is actually occurring.  Then, the software will attempt to restart the preferred miner a few times because the preferred miner is usually the fastest and most profitable to use.  But in worst-case scenarios, Hash Auger will now use an alternative miner if the problem keeps occurring with the preferred miner. Of course, this only applies to algorithms that can be mined with more than one miner.

[trucobit]

Ohhh how fast, of course you work a lot on this project. Many news and bugs, good work. I put myself right now with it. Let's see if it's stable enough to put it in all the rigs and do a 24-hour test.

A comment. I'm going to start using the selection of pools and protocols, to disable some. I know that the option is that if for example I have x17 in two pools like Ahashpool and Zergpool, the program of choice is supposed to be the most profitable. This can be true if I keep that protocol for a long time, so I have the review time in 20 minutes. The problem is that for example zergpool always marks a higher price, but a different percentage for each protocol, which almost always zergpool mine. As I said for me it is very important that the pool chosen is the one that has the most HASH. In the same time more blocks will be solved even if it has less reward. However, if you choose another pool with less hash, you may not find a single block and you will not get much benefit either.

Could explain what is based on choosing pool, or if possible, an option in the POOLS section, where it indicates that always change the pool with more hash in that protocol, it would be something easy, very easy.

I still have many doubts about a process and mining for each card, but they are only my conjectures. I have tests done in other programs, I'm looking forward to having a version stable enough to do 24 hours and compare results.

Very successful miner Enemy, very good., Thank you very much.

[trucobit]

First it fails without much importance. If you update from 1.8.3, no enemy is added, neither in the selection in the Protocols or in / miners /, it is solved by deleting / miners / they are discarded again all including the Enemy

Another small problem is weird. I have not selected bitcore on any card, I have looked at it one by one and used the general configuration, bitcore I do not have it selected. But then when choosing the protocols for each pool, the box is left to mark it or checked by default. It's a little nonsense

[trucobit]

https://preview.ibb.co/jkVqPH/Captura_de_pantalla_2018_04_30_a_las_18_23_48.png

Another error, enemy does not appear in the configuration screen of all GPUs, but if I go to the independent card if it appears in x16r. There is a lag between the configuration utility of all cards and go one by one. This problem is more annoying

while Bitcore is not marked in the configuration tool of all cards. By going one by one, Bitcore is still marked. That is another mistake

[trucobit]

please consider adding more miners, I leave you a capture of another program, look at PHI, simply duplicate the hash I get in HA, with that miner ccminer phi, as you will see there are many very specific and very valuable variants.
I leave it as an example of the variety that exists and how important it is. Simply in PHI it duplicates the result of HA

https://preview.ibb.co/eQdfrx/Captura_de_pantalla_2018_04_30_a_las_18_45_39.png

[trucobit]

I'm leaving failures. I am forced to go card by card because in the general configuration enemy does not appear.

If you look at this capture you will notice that IF I can edit the intensity in PHI in the first card, but not in the second, this light gray, it has remained the value that was before. But if I want to change the intensity of the second I just can not. These are silly mistakes that must be corrected

https://preview.ibb.co/cqgTdc/Captura_de_pantalla_2018_04_30_a_las_19_04_31.png

[HashAuger]

I'm leaving failures. I am forced to go card by card because in the general configuration enemy does not appear.

If you look at this capture you will notice that IF I can edit the intensity in PHI in the first card, but not in the second, this light gray, it has remained the value that was before. But if I want to change the intensity of the second I just can not. These are silly mistakes that must be corrected

https://preview.ibb.co/cqgTdc/Captura_de_pantalla_2018_04_30_a_las_19_04_31.png

The intensity value is disabled when Z-Enemy miner is selected as the preferred miner because I a still testing intensity support with that miner.  If you were to change the preferred miner back to Tpruvot or Nevermore, the Intensity box would be enabled again. Z-Enemy does appear in the GPU Manager as both a choice in the Preferred Miner List and as a benchmark setting for the four miners that support it. It is only missing when you try to load a saved template because the miner didn't exist when you saved the template. You could create a new template from an existing device, make your z-enemy changes and then save that new template.  In the next release, I will add support for automatically updating templates with new miners and algorithms.

The only thing that is silly is your attitude that any time the software does something you do not think it should then it must be an error. Most rational users ask questions if they are unsure about how something works, you just assume worst, make every effort to discredit the software and then pester me to include ever more fanciful features.

[HashAuger]

https://preview.ibb.co/jkVqPH/Captura_de_pantalla_2018_04_30_a_las_18_23_48.png

Another error, enemy does not appear in the configuration screen of all GPUs, but if I go to the independent card if it appears in x16r. There is a lag between the configuration utility of all cards and go one by one. This problem is more annoying

while Bitcore is not marked in the configuration tool of all cards. By going one by one, Bitcore is still marked. That is another mistake

You didn't provide many details for me to troubleshoot your issue, but I think found what you are referring to. Z-Enemy miner doesn't currently appear for saved templates because the miner didn't exist in the software when the template was saved. If you create a new template, then Z-Enemy is included. So you could copy the settings from your existing template to one or more devices and then create a new template based on one of those devices. That new template would have Z-enemy and all the original template's settings. In the next release, I will make sure existing templates are updated with new algorithms and miners automatically. Yes, there is an issue where disabling an algorithm in the GPU Manager does not fully disable the algorithm on the GPUs when there is more than one miner for that algorithm.  That will be fixed in the next release.

[trucobit]

Another failure I do not send capture or video makes me lazy.

I am optimizing card to card because if I use the option for all, there is no enemy. When I get to XEVAN, I only have the xevan miner. This miner does not know why he does not let me define the intensity manually, he appears in light gray. When I launch it to test, it makes auto intensity rises to 22 and the miners close, so all the time.

I am in the rig of 1050, now I pass to 1060, then 1070 and then to 1080ti.

I'm interested in Xevan. I do not understand why it does not let me define intensity, and then in autointensity I turn to 22 and it closes. It is totally unused

Enemy behaves great and improves the results thanks. I hope all these mini-bugs are fixed soon.

[HashAuger]

Another failure I do not send capture or video makes me lazy.

I am optimizing card to card because if I use the option for all, there is no enemy. When I get to XEVAN, I only have the xevan miner. This miner does not know why he does not let me define the intensity manually, he appears in light gray. When I launch it to test, it makes auto intensity rises to 22 and the miners close, so all the time.

I am in the rig of 1050, now I pass to 1060, then 1070 and then to 1080ti.

I'm interested in Xevan. I do not understand why it does not let me define intensity, and then in autointensity I turn to 22 and it closes. It is totally unused

Enemy behaves great and improves the results thanks. I hope all these mini-bugs are fixed soon.

Since not every miner supports intensity settings, the software disables that option by default.  I need to update the default configuration for Xevan to support custom intensity levels. That will be in the next release.

[trucobit]

I'm leaving failures. I am forced to go card by card because in the general configuration enemy does not appear.

If you look at this capture you will notice that IF I can edit the intensity in PHI in the first card, but not in the second, this light gray, it has remained the value that was before. But if I want to change the intensity of the second I just can not. These are silly mistakes that must be corrected

https://preview.ibb.co/cqgTdc/Captura_de_pantalla_2018_04_30_a_las_19_04_31.png

The intensity value is disabled when Z-Enemy miner is selected as the preferred miner because I a still testing intensity support with that miner.  If you were to change the preferred miner back to Tpruvot or Nevermore, the Intensity box would be enabled again. Z-Enemy does appear in the GPU Manager as both a choice in the Preferred Miner List and as a benchmark setting for the four miners that support it. It is only missing when you try to load a saved template because the miner didn't exist when you saved the template. You could create a new template from an existing device, make your z-enemy changes and then save that new template.  In the next release, I will add support for automatically updating templates with new miners and algorithms.

The only thing that is silly is your attitude that any time the software does something you do not think it should then it must be an error. Most rational users ask questions if they are unsure about how something works, you just assume worst, make every effort to discredit the software and then pester me to include ever more fanciful features.

I'll try what you tell me about the templates.

I think there may be a translation error, I'm sorry. I have not called you a fool, I have commented that you are making a silly mistake. Maybe the linguistic difference and the translation is not entirely correct.

I value your work and I have not called you foolish or underestimated.

Yes, every time I see an error or something that I think is an error, I will comment. Because for want of a manual, the one that I comment it and you will answer it, will make that the threads of this post are INFORMATIVE for all the world when it is with the same problems that I.

I always congratulate you and I always tell you what I think is a mistake, I may be wrong, but I have the best intention in the world. I hope everything is fine now. And I will also do a video in Spanish explaining its advantages and configuration with all those strange details of this software, and I hope this helps, but first I have to do my performance tests on ub software that does not have many small problems. That is normal for it to be because you are building a very friendly interface.

I am going to promote your program in the telegram groups that I am admin and they are mining, I have already mentioned it, but they are waiting for me to tell them that it is stable. Consider all my comments as a great help to improve your software.

You should consider general usability for all users, not the usability that you like. We are not fortune tellers

[HashAuger]

First it fails without much importance. If you update from 1.8.3, no enemy is added, neither in the selection in the Protocols or in / miners /, it is solved by deleting / miners / they are discarded again all including the Enemy

Another small problem is weird. I have not selected bitcore on any card, I have looked at it one by one and used the general configuration, bitcore I do not have it selected. But then when choosing the protocols for each pool, the box is left to mark it or checked by default. It's a little nonsense

I test both upgrades and new installs for every release on several machines before releasing it. I haven't seen any problems with z-enemy downloading when upgrading from 1.8.3.  After the upgrade, z-enemy won't be the preferred miner for any algorithm because it has not been benchmarked yet.  But when the user upgrades, the software will only benchmark those miners and algorithms that haven't been benchmarked instead of requiring all the miners to be benchmarked again. If you are referring to your concern that z-enemy does not appear when saved templates are loaded into the GPU Manager, then that is addressed a couple of times in my previous responses.

Yes, what you noticed is a UI refresh issue. The pool algorithms are not currently refreshed when algorithms are enabled and disabled for devices.  If you were to restart the software, you would see that Bitcore would be disabled for the pools that use it.  Since Bitcore is not enabled on any device in your example, the software will not use it regardless of whether or not it is enabled on the pools. However, I will fix this display issue in the next release.

[HashAuger]

I'm leaving failures. I am forced to go card by card because in the general configuration enemy does not appear.

If you look at this capture you will notice that IF I can edit the intensity in PHI in the first card, but not in the second, this light gray, it has remained the value that was before. But if I want to change the intensity of the second I just can not. These are silly mistakes that must be corrected

https://preview.ibb.co/cqgTdc/Captura_de_pantalla_2018_04_30_a_las_19_04_31.png

The intensity value is disabled when Z-Enemy miner is selected as the preferred miner because I a still testing intensity support with that miner.  If you were to change the preferred miner back to Tpruvot or Nevermore, the Intensity box would be enabled again. Z-Enemy does appear in the GPU Manager as both a choice in the Preferred Miner List and as a benchmark setting for the four miners that support it. It is only missing when you try to load a saved template because the miner didn't exist when you saved the template. You could create a new template from an existing device, make your z-enemy changes and then save that new template.  In the next release, I will add support for automatically updating templates with new miners and algorithms.

The only thing that is silly is your attitude that any time the software does something you do not think it should then it must be an error. Most rational users ask questions if they are unsure about how something works, you just assume worst, make every effort to discredit the software and then pester me to include ever more fanciful features.

I'll try what you tell me about the templates.

I think there may be a translation error, I'm sorry. I have not called you a fool, I have commented that you are making a silly mistake. Maybe the linguistic difference and the translation is not entirely correct.

I value your work and I have not called you foolish or underestimated.

Yes, every time I see an error or something that I think is an error, I will comment. Because for want of a manual, the one that I comment it and you will answer it, will make that the threads of this post are INFORMATIVE for all the world when it is with the same problems that I.

I always congratulate you and I always tell you what I think is a mistake, I may be wrong, but I have the best intention in the world. I hope everything is fine now. And I will also do a video in Spanish explaining its advantages and configuration with all those strange details of this software, and I hope this helps, but first I have to do my performance tests on ub software that does not have many small problems. That is normal for it to be because you are building a very friendly interface.

I am going to promote your program in the telegram groups that I am admin and they are mining, I have already mentioned it, but they are waiting for me to tell them that it is stable. Consider all my comments as a great help to improve your software.

You should consider general usability for all users, not the usability that you like. We are not fortune tellers

I don't expect users to be fortune tellers. There is a setup guide on my website and try to make usability adjustments that make the software easier to use when users have concerns. I appreciate all feedback, including criticisms.  I think it is fair to say that I am pretty responsive to bug reports. However, when someone keeps mentioning the same issue three times after I confirm that is a problem in the software that I am going to fix, it appears to be more of an attack than a genuine bug report.

[jbeck]

sigh....

[HashAuger]

sigh....

J, I sent you an email with a script that may help with the issues you've been having with those two miners on your machine. Let me know if you have any questions.

[HashAuger]

If anyone has had issues with some of the miners not installing correctly, please let me know. The majority of these issues are related to Windows Defender and other anti-virus programs incorrectly flagging some miners as threats. However, there have been exceptions.  I am currently testing some improvements to error handling during the miner installation/update process and would appreciate your feedback so I can test as many different scenarios as possible.

[HashAuger]

Just a friendly reminder to all users who are using the Price Spike Limit feature to prevent time wasted mining coins at absurd prices (like yesterday's Lyra2v2 spikes). Now that prices for many coins are rising again, it is a good opportunity to review any Price Spike Limits that were defined in the dark days a few weeks ago and perhaps adjust the limits so they are more inline with current prices.

[Zirillian]

Nicely done on the recent updates, HA. I've been running pretty darn smooth for the past 4-5 days. Normally I'd have some sort of miner crash that would cause some heartache (usually in the middle of the night while sleeping), but I've been running quite smooth the last few days with no major issues at all.  I really like the recent improvements with the GPU Manager, additional miners added, etc.

I do have some feedback/questions for consideration with your ongoing development:

1) You're valiant efforts at trying to maintain a level head despite the criticism here/communication issues are not going unnoticed lol.  Try not to get too bogged down in it; you are very loyal to your users but have to draw a line somewhere.

2) Just downloaded 1.8.6 this morning. Some time after benchmarking the new ccminer-phi and nanashi algos, I got a message saying that both algorithms cannot communicate with ahashpool while trying to mine lyra2v2, and would stop mining with those miners. Looking at the benchmarks now, it seems those miners benched higher than tpruvot and thus won out. Not sure what the issue here is, but say it's a fix on your end...does HA go back and try using those miners again at some other time to see if the issue is fixed, or do I need to manually rebenchmark at some point?

3) Side note from a few versions back when you reenabled alexis, and this is also in response to others posting on this thread...I do realize alexis benches higher sometimes but HA is right that it is inherently unstable. It crashes for me (not all the time, on occasion). I disabled it on all algos and no issues with crashes anymore...I had to check the logs to figure out why the hell HA would crash in the middle of the night and miss out on several hours of mining. Alexis was it.

4) Real life scenario here of helping me understand the new GPU manager.  So a couple days ago I recently did a full refresh on all benchmarks, saved it as a profile in the GPU manager, and let it go.  Now, after having updated to 1.8.6 with new miners to benchmark...are those results going to get added back in to my template in the GPU manager? Right now it's not looking like they are auto added back, and I'm confused on the appropriate way to go about doing that that doesn't override all the actual rate benchmarks for my 8 GPUs that have been accumulating since the template creation.  Here is my guess at how to do this..please tell me if I am right. A) in the GPU manager go to benchmarks section, B) copy benchmarks in from GPU0 and in the bottom "Apply template to these devices" click GPU0 ONLY, C) repeat the same operation from GPUs 1-7 one by one, then resave the template.

Keep up the good work.