Hash Auger 2.9.7.5 Mining Manager and Switcher for NVIDIA GPUs

[pizzaslut]

No results at all as the gpu is working but nothing is going on. But, I think it was just hmq1725 and x17 that was causing the problem for me. So far it is working okay atm.

[HashAuger]

No results at all as the gpu is working but nothing is going on. But, I think it was just hmq1725 and x17 that was causing the problem for me. So far it is working okay atm.

Sometimes it does take a pool a while to assign an appropriate difficulty level to your cards. That happened to me with C11 the other night on one pool - the pool kept changing the difficulty every thirty seconds or so for the first few minutes. If it keeps happening, you may want to switch miners for both of those algorithms and see if that helps.  X17 is mined by both Alexis and Tpruvot, while both Tpruvot and Nevermore mine hmq1725. Also, you could try disabling those algorithms for individual pools if the problem only seems to happen for an algorithm on one specific pool.  For example, if it takes a while to get started mining x17 on AHashPool, you could disable x17 just for that pool and the software will still mine x17 on the other pools that you have enabled.

[trucobit]

the option of "--cuda-sheduler 2" is not an option too thought for nvidia in windows, yesterday I was testing it in different rigs, both 4, 6 and 8 cards.

as I in manual I have everything very optimized, that option only gave me 1 more mhs, but leaves the computer fried. DA equals 4 that 8 cards, and imcluso with a card, it goes to 100% all the time the cpu, and does not deserve to have a RIG that is at 34% of cpu giving me 121mhs, that is always 100% cpu and get 122 mhs.

Reading a lot of information on that option, it is quite used in Linux rigs, but it is not used in Windows.

Also once you activate the rig becomes unstable, does not turn off or freezes, but becomes unstable even if you turn off the miner, you have to restart to leave the rig again well.

You who search according to say the greater stability has added an option that is the opposite of what you are looking for. If you want more performance, do not make the computer suffer by having one thread per card, because when I want to show it is not optimal or better.

[HashAuger]

the option of "--cuda-sheduler 2" is not an option too thought for nvidia in windows, yesterday I was testing it in different rigs, both 4, 6 and 8 cards.

as I in manual I have everything very optimized, that option only gave me 1 more mhs, but leaves the computer fried. DA equals 4 that 8 cards, and imcluso with a card, it goes to 100% all the time the cpu, and does not deserve to have a RIG that is at 34% of cpu giving me 121mhs, that is always 100% cpu and get 122 mhs.

Reading a lot of information on that option, it is quite used in Linux rigs, but it is not used in Windows.

Also once you activate the rig becomes unstable, does not turn off or freezes, but becomes unstable even if you turn off the miner, you have to restart to leave the rig again well.

You who search according to say the greater stability has added an option that is the opposite of what you are looking for. If you want more performance, do not make the computer suffer by having one thread per card, because when I want to show it is not optimal or better.

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).

[pizzaslut]

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?

[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?

Right now you can switch miners by changing the preferred miner on the device benchmark and then starting to mine again.  If this situation becomes more common, I'll consider adding a button, but I am hesitant to add buttons for features that may only be rarely used.

[HashAuger]

HA - thanks for your work on copying settings over between cards.  Putting one additional request out there...can you make a master "switch" list where you add the ability to turn (anything you can) on and off in totality? I specifically care about the ability to turn on/off algorithms that apply all at once to all 8 cards, rather than having to do it individually as it is now, but the concept could apply to quite a few other "switches" you have throughout the settings that could all be put in one place vs. having to individually tick things off for every instance. Having individual switches is great, but master overrides can be useful too.

So I added a new button to the Devices screen called GPU Manager. When you click on it, the individual device panels are replaced with a single panel that includes all the device settings.  At the top of this panel, you can either choose to load an existing template file (which you won't have any to start out with) or to create a new template file. To create a new template, press the New (Plus) button.  You can select a source GPU to be basis for the new template.  If you want to save the template to disk for later use, you check that option and provide a template name. 

In the middle section, you configure all the settings like you would a specific device. Once you are finished, you then select the GPUs that you want to copy those settings to. Finally, press the Apply button in the lower right corner. If you selected the Save option, the template file is created after you apply the settings.

If you get a chance to try it out, I'd be interested in your feedback. Since it is a new feature, there are probably some usability tweaks that could be made, but overall it really cuts down on the time required to configure devices. Thanks for the feedback.

[pizzaslut]

I noticed today that one of my gpus went below minimum earnings amount by a 75 cents. I closed the app and tried again, but did the same thing for 10 minutes before switching.

[HashAuger]

I noticed today that one of my gpus went below minimum earnings amount by a 75 cents. I closed the app and tried again, but did the same thing for 10 minutes before switching.

I found the issue. Thanks for letting me know. The fix will be in 1.8.4, which will be released in a couple of days.

[trucobit]

I really like the changes you have added, handle all the GPUs together and save templates. Or that there is a different price and hash for each pool, so you will know where to best mine a protocol.

I am now trying to mine the best algorithm in your pool, with the option of choosing protocols for each protocol, this is from the previous version.

I give ideas and I am critical, I am also a grateful person, Thanks for these new features that I like a lot.

I would like very much to be able to launch all the cards in a single process to the protocol that yields the most, instead of several threads and processes one for each card.

You should know that those of us with a high number of miners, we have small configurations with celeron, g4400 and sometimes with i3. Launching a miner for each card and different protocols is not being as efficient as I would like. This could be something optional with a selector, I do not see it complicated. Thus the rigs are lighter and are more efficient at the time of producing more HASH.

[trucobit]

I just tried the latest version and has problems. Now it is with the miners, for example in Neoscrypt Klaus closes me completely HA, even with 0 intensity and with the OC to 0, and trupovt which is the other one that can be chosen, it does not work well, it gets stuck and you have to lower the intensity a lot and keeps failing.

Right now I can not mine in any way neoscrytp.

Also it has happened to me that ALEXIS in some protocols like HSR I think I remember, I completely closed the program.

I'm using everything from the new GPU interface, it's very comfortable now. Please check because the miners do not launch well and close the program, I have restarted the rig several times. I am with other programs until the fix of these failures.

Tested at 2 x1050. For the tests I use that minirig, I'm not going to put the big rigs to do tests, I already tried last week with the 1080ti and I did not get the expected results. At least 1.8.2 the miners did not fail.

https://www.dropbox.com/s/crsdl79sgrpv5lx/IMG_2231.MOV?dl=0

[HashAuger]

I just tried the latest version and has problems. Now it is with the miners, for example in Neoscrypt Klaus closes me completely HA, even with 0 intensity and with the OC to 0, and trupovt which is the other one that can be chosen, it does not work well, it gets stuck and you have to lower the intensity a lot and keeps failing.

Right now I can not mine in any way neoscrytp.

Also it has happened to me that ALEXIS in some protocols like HSR I think I remember, I completely closed the program.

I'm using everything from the new GPU interface, it's very comfortable now. Please check because the miners do not launch well and close the program, I have restarted the rig several times. I am with other programs until the fix of these failures.

Tested at 2 x1050. For the tests I use that minirig, I'm not going to put the big rigs to do tests, I already tried last week with the 1080ti and I did not get the expected results. At least 1.8.2 the miners did not fail.

https://www.dropbox.com/s/crsdl79sgrpv5lx/IMG_2231.MOV?dl=0

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).

[trucobit]

I have some doubts. Now I am ready to install it on all computers for a 24 hour test compared to another soft.

I have had a lot of problems in some miners that close the program, restart and sometimes it is fixed and sometimes not. For example, I have not been able to configure PHI, it does not matter which of the two miners put in and remove the OC, it simply closes it, it is a rig with 1050 tests.

I have a doubt, I really like the idea of ​​being able to choose Something by pool, and also now you have improved the function of better switch, which according to comments is based on several factors. For me the most important is not the price, because the currency will be more or less the same, I am interested and much that I choose the pool with hash. If I choose X16s and it is in Ahashpool and Zergpool, I would be interested where there is more hash, because in the time that mine will be more blocks but less reward. Many times we mine in a pool where there is little hash and we lose time in a block that we do not solve and goes to another Something, with which the reward is ridiculous. It is not the same to mine X16s in a poo with 2ghs than another with 20ghs, I am interested in the latter.

I keep insisting on more specialized ccminers for PHI, xevan. Also others like hsrminer for neoscrypt, superminer x17 etc ...

The new way to optimize the whole rig is fantastic, just a small inconvenience. When I save the template, and then recover it, the GPU selection is not activated, I mean I have 6 cards, I choose all of them, I make the modifications, I synchronize them with the others and I save everything. Then when recovering that template, the GPUs are not selected as I left it in that template.

Yesterday I invested like 6 hours to configure 10 Algos, the only ones that I use, but as it closed continuously late very much. Because I try every miner available for the Something, then I play with the intensity and then with the OC, it would be fantastic something simple to help me optimize without having to be all the time in front of the computer.

I will comment my tests in a few days.

[trucobit]

the option of "--cuda-sheduler 2" is not an option too thought for nvidia in windows, yesterday I was testing it in different rigs, both 4, 6 and 8 cards.

as I in manual I have everything very optimized, that option only gave me 1 more mhs, but leaves the computer fried. DA equals 4 that 8 cards, and imcluso with a card, it goes to 100% all the time the cpu, and does not deserve to have a RIG that is at 34% of cpu giving me 121mhs, that is always 100% cpu and get 122 mhs.

Reading a lot of information on that option, it is quite used in Linux rigs, but it is not used in Windows.

Also once you activate the rig becomes unstable, does not turn off or freezes, but becomes unstable even if you turn off the miner, you have to restart to leave the rig again well.

You who search according to say the greater stability has added an option that is the opposite of what you are looking for. If you want more performance, do not make the computer suffer by having one thread per card, because when I want to show it is not optimal or better.

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).

Most of the miners use a minimum of 6 graphics cards and a celeron, pentium g4400 and some like me up to i3, and it always takes 100% of the CPU, I get more HASH if I have it unmarked. You should warn by selecting it the same thing you do when activating the OC, a good warning. Because many can give you a bad experience and have a wrong idea about your program.

You can also see how many cores the processor has and how many cards there are in the rig, and to allow it to be selected or not, that would be optimal.

I in 4 different rigs, in the 4 I had problems. In other words, the vast majority do not need them, warn them well of the problems they can give or only allow them to select it if they have more cores than cards.

I do not even a serious miner spend $ 300 on a micro, when with a micro $ 80 intel g4400 you have left to mine.

THE option has its function, and will serve especially those that only have 1 card and a lot of CPU, for example a gamer that wants to enter the cryptos. But the more appropriate it is for everyone, including the group that most interests you, the medium and large miners, the more useful it will be and the more it will gain.

I'm not saying that the option is bad, only that it should better warn or control the number of nuclei to allow it to be used or not, so it will be much easier for newcomers or new people in the Soft.

[trucobit]

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

[trucobit]

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.

[trucobit]

I just tried the latest version and has problems. Now it is with the miners, for example in Neoscrypt Klaus closes me completely HA, even with 0 intensity and with the OC to 0, and trupovt which is the other one that can be chosen, it does not work well, it gets stuck and you have to lower the intensity a lot and keeps failing.

Right now I can not mine in any way neoscrytp.

Also it has happened to me that ALEXIS in some protocols like HSR I think I remember, I completely closed the program.

I'm using everything from the new GPU interface, it's very comfortable now. Please check because the miners do not launch well and close the program, I have restarted the rig several times. I am with other programs until the fix of these failures.

Tested at 2 x1050. For the tests I use that minirig, I'm not going to put the big rigs to do tests, I already tried last week with the 1080ti and I did not get the expected results. At least 1.8.2 the miners did not fail.

https://www.dropbox.com/s/crsdl79sgrpv5lx/IMG_2231.MOV?dl=0

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).

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.

[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

[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.

[HashAuger]

the option of "--cuda-sheduler 2" is not an option too thought for nvidia in windows, yesterday I was testing it in different rigs, both 4, 6 and 8 cards.

as I in manual I have everything very optimized, that option only gave me 1 more mhs, but leaves the computer fried. DA equals 4 that 8 cards, and imcluso with a card, it goes to 100% all the time the cpu, and does not deserve to have a RIG that is at 34% of cpu giving me 121mhs, that is always 100% cpu and get 122 mhs.

Reading a lot of information on that option, it is quite used in Linux rigs, but it is not used in Windows.

Also once you activate the rig becomes unstable, does not turn off or freezes, but becomes unstable even if you turn off the miner, you have to restart to leave the rig again well.

You who search according to say the greater stability has added an option that is the opposite of what you are looking for. If you want more performance, do not make the computer suffer by having one thread per card, because when I want to show it is not optimal or better.

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).

Most of the miners use a minimum of 6 graphics cards and a celeron, pentium g4400 and some like me up to i3, and it always takes 100% of the CPU, I get more HASH if I have it unmarked. You should warn by selecting it the same thing you do when activating the OC, a good warning. Because many can give you a bad experience and have a wrong idea about your program.

You can also see how many cores the processor has and how many cards there are in the rig, and to allow it to be selected or not, that would be optimal.

I in 4 different rigs, in the 4 I had problems. In other words, the vast majority do not need them, warn them well of the problems they can give or only allow them to select it if they have more cores than cards.

I do not even a serious miner spend $ 300 on a micro, when with a micro $ 80 intel g4400 you have left to mine.

THE option has its function, and will serve especially those that only have 1 card and a lot of CPU, for example a gamer that wants to enter the cryptos. But the more appropriate it is for everyone, including the group that most interests you, the medium and large miners, the more useful it will be and the more it will gain.

I'm not saying that the option is bad, only that it should better warn or control the number of nuclei to allow it to be used or not, so it will be much easier for newcomers or new people in the Soft.

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.