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.

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.

You did find a bug in 1.8.3, but not with the miners. Neither Klaust nor Tpruvot were changed.  The issue occurs only when you select an algorithm that has not been benchmarked yet -  in your video the hash rates for Equihash are zero.  I will fix this in 1.8.4, which will be released sometime tomorrow. This issue does not affect the algorithm-switcher, only when you are manually selecting an unbenchmarked algorithm. In the meantime, you can workaround this bug by either doing a full benchmark or by typing in an hash rate for Equihash and then re-selecting DSTM as the preferred miner (you must do both even though DSTM is already selected as the preferred miner).

Sorry, but you are mistaken.  Cuda-Scheduler works on both Windows and Linux.  Klaust added it to the Windows version of his miner in 8.21 and it was in Tpruvot before that.  On a rig where the CPU has more processor cores than there are video cards, it can boost GPU performance because it reduces the amount of time that the miner process has to wait for a thread on either operating system. You can read more about Cuda Scheduler here: https://stackoverflow.com/questions/11953722/how-to-reduce-cuda-synchronize-latency-delay.



As you mentioned, it can overburden the CPU if a rig has more GPUs than CPU cores or the CPU itself is under-powered. That is why the option is off by default. Users can choose to enable it when it makes sense on their system and they do not have to enable it for every card (which is another benefit of using a separate mining process for each GPU - you can tune the miner for each GPU instead of applying the same settings to all cards).

About the difficulty of programming, I think it is more work to write code than to think how to do it.

I do not say an OC as EGVA, I have given you a very detailed idea, you on that basis of my idea, valuing the difficult / easy, and other factors, you can do an optimization totally different in other steps and more simple, I just I say what I need.

And what I need is needed by many professional miners who know about the shortcomings of other products. One of the main characteristics of your product is card by card, that is, a process for each card, and also you can easily optimize the OC and the intensity for each protocol. That's a breakthrough, but I tell you it takes a long time.

If you are able to develop something that is not as complete as I have described, but that helps me optimize faster, I am sure that many people who have many machines will be very grateful

Miners of few cards is not so important, BIG MINING will give you a very interesting dev fee, it is not the same 1% of 1000 that of 100,000.

I do not demand anything, I just suggest and give the complete idea well explained, now it is you who must choose the best ideas of the other miners, but almost nobody contributes anything.

I hope to see the following improvements, I will continue testing it in the small test rig that I have

I also suggested that the coins to be mined directly had the option of being able to mine if the diff falls below X, which also seems like a good idea, because if the difficulty is very high I prefer to go in auto change, and if it falls from X that I define, then mine that currency, so I take better advantage of time looking for the greatest number of profits.

Maybe some of my suggestions are strange because they have not been seen in other proghramas, but that does not mean they are not good ideas.

Over time I would like HA to be able to manage platforms remotely, but this I think is far from the initial idea of ​​a programmer and I understand it.

The Hash Auger software disables algorithms for pools for a variety of reasons.  Unlike some programs that use predefined lists, the software uses each pool's rate information to determine the coins and algorithms that each pool supports. If a pool adds a coin or an algorithm, Hash Auger can use it automatically without an update as long as the algorithm is supported by one of the included miners. Conversely, the software will not attempt to use an algorithm on a pool that doesn't support it. For example, neither MiningPoolHub nor NiceHash currently support Phi, so Hash Auger won't try to use Phi on either pool.

Next, Hash Auger won't use any algorithms that are disabled on all devices - those are the algorithms that cannot be enabled or disabled in each  pool's algorithm list. For example, both Qubit and Quark are disabled by default, so Hash Auger will not use either algorithm for any pool unless the user enables them on their devices and benchmarks these algorithms first.

By default, the software will compare prices for all device-enabled algorithms for all auto-exchange pools. Version 1.8.2 adds support to disable individual algorithms for auto-exchange pools in cases where the user does not want to mine specific algorithms on that pool. For instance, last night I disabled C11 on one pool because it always takes that pool a relatively long time to provide valid work for this algorithm.  I still want to use C11 on other pools, so I do not want to disable it completely, I just don't want the software to use it on this one pool regardless of what the earnings estimate may be.

I understand that being able to copy these preferences could save a little time in some circumstances, but the time savings will be considerably less than that from copying device settings.  Unlike the device settings which often apply to every GPU, the algorithms list is specific to each pool.  Copying settings for Phi to MininingPoolHub or NiceHash wouldn't have any affect since those pools do not support that algorithm.  Also, since the software automatically excludes algorithms that are disabled on all devices, the use case of disabling an algorithm on every pool is already handled.  Finally, most users don't enable every auto-exchange pool, so the need to copy these settings to every pool is limited.

As for your suggestions about an auto-tuning feature, I agree that in theory it is an intriguing idea.  However, given the poor reputation that existing products such as EVGA's auto-overclocking software have, reliably implementing such a feature is a bit more challenging than the concept implies.  Trying to balance tuning time with overall reliability would be problematic as overclock settings may appear to be stable after a few minutes, but then fail after a few hours.  Also, if the overclock settings corrupt the device driver and require a restart, the whole OS would be frozen, preventing the software from recording the failure to avoid using those settings in the future. Thus, the tuning process would keep repeating the same tests that lead to system freezes. Due to issues such as this, if I ever decide to include any auto-tuning features, they will probably be focused on intensity settings only.