Topic: Hash Auger 2.9.7.5 Mining Manager and Switcher for NVIDIA GPUs - page 18. (Read 8796 times)

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.

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

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.

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.

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.

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'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

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

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

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

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.

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.

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.  

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

I've introduced another CPU-related optimization in 1.8.4 that is automatically disabled based on the number of CPU cores. However, the CUDA Scheduler is device-specific, so even a user with a low-powered CPU could still enable it for certain cards and not others. For example, someone with a 1080 and a 1060 powered by a i3 CPU could enable the CPU Cuda Scheduler for just the 1080 and not have a considerable CPU usage penalty. I also disagree about your assertions about the impact that this feature has on CPU usage.  On my development machine, which is an i7, I often code, mine on a 1070ti and a 1080 with the CPU Cuda Scheduler feature turned on and run BOINC on several CPU cores and do not exceed 70% CPU utilization. I also use the CPU Cuda Scheduler on my rigs that have more GPUs and Ryzen 5 CPUs and their CPU usage is still low enough to also run Folding@Home on those systems. The only reason reason why this feature fully utilized your CPU is because you decided to enable it for all of your GPUs at one time on a CPU that doesn't have many cores.

I understand that some people who spend considerable money on GPUs want to save a little money on the CPU. However, whether or not they are mining with all GPUs as a single process or as individual processes, any miner (such as CCMiner) that validates results on the CPU before sending it to the pool will have to block the mining thread while that work is being done.  The slower the CPU, the longer the time it takes for that work to be done, holding back the other GPUs from submitting their work. CPUs with more cores can also process results for more GPUs simultaneously.   For really under-powered CPUs that only have a couple of processing cores,  it is best to use an operating system like Linux that has lower latency and less greedy background processes than Windows 10.  

That is why, despite your numerous pleas, I am not going to be rewriting my software to group devices into a single miner process. I made an informed design decision to assign each GPU to its own miner process because it offers lower CPU latency, better customization of the individual devices and miners, the ability to select different algorithms on rigs with different types of GPUs and has a higher fault-tolerance since a failure with one device/miner won't affect other devices.  As with every design decision, it is compromise between multiple factors and there may be some cases where it is not the optimal implementation for a given algorithm on a specific hardware configuration. However, no single piece of software can ever be the ideal solution in every situation.  There are no upfront costs to trying my software and it offers a variety of configuration options so that users can tune it to fit their hardware. Most reasonable users can make a rational decision as to which mining software works best in their situation.

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.

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

Even if it benchmarks, it almost always fails. Anyway I will be attentive to this point. But in any case it would not matter if the benchmark had been made or not.

I keep counting problems. In another rig DSTM does not run, they are 1060. I have deleted the folder miners and they have downloaded again. But when I select only to mine Equihash that I can only mine with dstm, the hit program is closed.

On the other hand there is another small problem with data storage. They are in many cases different, as when doing the GPU benchmark, I pass it whole and it gives me values, then I launch the miner with DSTM it closes at once. When the program was started again, the result of the benchmark and profit had not been saved.

I believe that you keep all the information when the program is closed. But if the program closes unexpectedly, that data has not been saved. It happens for example also with the configuration OC of the protocols, if it closes unexpectedly the last changes have not been saved, I mean the new panel to opimize all the gpu at the same time.

But the most serious problem I see in the problem of launching some miners. I have already said that PHI in the other rig I have left without activating because it did not matter the miner, it was closed. Now DSTM in another rig, always closes. It happens with different miners in different protocols. It's a bit random, sometimes a restart solves it, sometimes it's impossible. There's something wrong that needs to be checked. I spend almost an hour fighting with these problems in this other rig.

A small contribution for all users, not only will they be complaints on my part.

In the autochange mode, it is important to look at all the pools, if you do you will see that most have few miners, which is not advisable, and for example miningpoolhub does not have good coins.

Which pools you choose will be a big part of the success. I advise you to use maximum 3, and the best 3 right now in number of Protocols and number of miners are, ahaspool, zergpool and zpool. The others are not worth it or try it, because mining X17 in a group with 2 miners is not the same as mining where there are 2000 miners, the 2000 will be more profitable.

For example X17 only in ahaspool, but X16s and x16r in zergpool and Ahaspool at the same time, and I suppose that the auto change will choose the most profitable in number of miners. Neoscrypt in zergpool and zpool, in Ahashpool there are hardly any neoscrypt miners.

That way it takes longer to reach the minimum of each pool, but you get more satochis per hour because mines where you will solve more blocks. Assuming the autochange does it well.

You can use in pools the option to select the protocols in each pool in the configuration of these.

My test is going to be based on what I have explained, with only 10 protocols and in those 3 pools, we hope that the switch chooses the best pool when there are two for the same protocol, I will monitor it, it imporates me that only goes to the one that hash has

If I know that zergpool has a tendency to mark a higher price, I expect some advice from HAshauger that% suggests me to put in the pool configuration to more or less fix it. For that I say that a measure that can not be falsified is the number of miners, or the amount of HASH of that protocol in that pool. It's the first thing I notice when I look at a pool, if it does not have a high hash it's not worth mining there.

Please can show in the panel the amount of satochis for each pool in the statistics, now only shows the total of all without specifying pool