Hash Auger 2.9.7.5 Mining Manager and Switcher for NVIDIA GPUs

[HashAuger]

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.

Thank you. I sincerely appreciate the support. Trying to provide support to an international user base can be challenging, especially given the constraints of message boards and misunderstandings in language use.  I'm looking into setting up a Discord channel to make it easier to provide support.

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?

If the miners were benchmarked, then they must have installed correctly and can be started by the software, so the software shouldn't have blocked the miners unless it encountered a number of errors.  I tried mining Lyra2v2 on AHashPool with both miners and there doesn't seem to be any incompatibilities. That leads me to think your issue was a temporary communications issue with that pool. The software will stop mining on a pool if too many communication errors occur and then try the pool again after an hour. However, there may have been a cascading error that caused the software to block each miner due to these communication errors in addition to blocking the pool.  I'll have to dig a little deeper into recreating that situation and see if there may be some path in the logic that causes both error types to be triggered. Currently the software won't automatically attempt to reuse blocked miners because it assumes those issues can't be resolved without user intervention.  If you restart the software, the Preferred Miner for those algorithms shouldn't have changed because the list of blocked miners is maintained separately.  If a preferred miner did change for whatever reason, you can manually change the Preferred Miner using the drop-down list instead of having to re-benchmark.

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.

I'm sure you've picked up on some of my skepticism about some older mining software in the past. If it wasn't for the significant boost in performance for certain algorithms, I wouldn't have bothered with it.  I had a rig that would crash once a day always on Alexis, always on the same card, but with different algorithms.  It was a 1080ti with a slight overclock.  Once I removed the overclock on just that card for only the few algorithms that use Alexis, I stopped having issues.  You may need to watch CCMiner-Phi for similar reasons because it based on the Alexis code base.

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.

I really need to type up a document about the GPU Manager; we programmers don't like taking time to write documentation, but it definitely makes things easier for everyone. My apologies for any misunderstandings about the feature's use.  The design intent was to make it easy to copy the same set of settings to multiple devices, so a template only contains a single set of settings, not a separate list of settings for each device.  If you were to copy benchmark data from multiple devices, then the template will only have the data from the last device and not the other seven. If you wanted to save benchmark data for each card, you would unfortunately need a separate template for each GPU. If you want to backup your existing benchmark data, you could copy the individual GPUx.xml files in your Hash Auger directory instead of creating templates.

The benchmark data really complicates what should be a relatively simple process otherwise - in some scenarios users want it copied so they don't have to benchmark all devices and in other cases the hash rate data should be ignored because it would overwrite existing data that may not apply to a card.  The Include Hash Rates option handles both cases when copying the data from a template, but that doesn't apply to updating the template itself. Currently, the software adds any missing miners and algorithms to a template that was created before the miners/algorithms were added, but it doesn't try to copy hash rates from any device when it does so - leaving the hash rates for the new miners/algorithms as zero on the template itself unless you use the Copy button like you mentioned.

If you are trying to prevent existing benchmark data from being overwritten, then you should be able to use the GPU Manager without the Include Hash Rates option enabled.  When that option is off, the copy process doesn't overwrite the hash rates on the device, but it may reset the preferred miner if one of the new miners is now the preferred miner on the device and not on the template. I'll need to think about how to handle that facet in a way that doesn't further complicate the process. I can already foresee situations where the Preferred Miner should be recalculated and other times when the user doesn't want it to be changed.

[1715093762]

1715093762

[1715093762]

1715093762

[1715093762]

1715093762

[1715093762]

1715093762

[1715093762]

1715093762

[HashAuger]

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?

Here's a follow-up on this issue after some testing.  The error messages were not as clear as they could have been and made it seem that the problem was with the miner and not the pool. It was probably just a coincidence that the error occurred with these two new miners based on that they both tend to benchmark pretty high with Lyra2v2.  I have been mining on AHashPool with both miners and haven't had an issue yet. Basically this situation happens in response to a stratum connection failed.  Unfortunately, the current settings might be a little too aggressive at responding to this type of error. I'm going to adjust the error messages and increase the tolerance a bit to better handle brief interruptions in connectivity. As I noted before, the software will automatically resume using an algorithm or pool suspended due to a communication error an hour after the most recent error occurred.

[Zirillian]

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?

Here's a follow-up on this issue after some testing.  The error messages were not as clear as they could have been and made it seem that the problem was with the miner and not the pool. It was probably just a coincidence that the error occurred with these two new miners based on that they both tend to benchmark pretty high with Lyra2v2.  I have been mining on AHashPool with both miners and haven't had an issue yet. Basically this situation happens in response to a stratum connection failed.  Unfortunately, the current settings might be a little too aggressive at responding to this type of error. I'm going to adjust the error messages and increase the tolerance a bit to better handle brief interruptions in connectivity. As I noted before, the software will automatically resume using an algorithm or pool suspended due to a communication error an hour after the most recent error occurred.

Yeah it definitely looked like a pool error and not a miner error...probably just coincidence but thought I'd mention since I had never seen before and coincidentally had very recently turned on the two new miners.

[HashAuger]

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?

Here's a follow-up on this issue after some testing.  The error messages were not as clear as they could have been and made it seem that the problem was with the miner and not the pool. It was probably just a coincidence that the error occurred with these two new miners based on that they both tend to benchmark pretty high with Lyra2v2.  I have been mining on AHashPool with both miners and haven't had an issue yet. Basically this situation happens in response to a stratum connection failed.  Unfortunately, the current settings might be a little too aggressive at responding to this type of error. I'm going to adjust the error messages and increase the tolerance a bit to better handle brief interruptions in connectivity. As I noted before, the software will automatically resume using an algorithm or pool suspended due to a communication error an hour after the most recent error occurred.

Yeah it definitely looked like a pool error and not a miner error...probably just coincidence but thought I'd mention since I had never seen before and coincidentally had very recently turned on the two new miners.

I totally understand; the timing was very suspect. I'm glad you asked about it because it gave me some extra motivation to clarify those error messages and put a little more tolerance into handling these types of connectivity errors.  The changes will be in the next release, which will most likely be in a few days as 1.8.7.   

[HashAuger]

While the software supports several auto-exchange pools and a number of pools that do not auto-exchange, the following pools have some specific options that new Hash Auger users may not be aware of.

MiningPoolHub

• If you are using the pool's auto-exchange feature, the Subtract Exchange Fee option on the pool's Pricing tab can be used to include cost of auto-exchanging in the algorithm-switching calculations when comparing estimates for different pools.
• Users with many GPUs may want to try enabling the Include Auto Switch Port option (also on the pool's Pricing tab) to mine on MPH's 17xxx ports. These ports tend to have a higher difficulty than the 20xxx ports Hash Auger uses, but may be profitable for users mining with significant hashing power.

NiceHash

• Use the Subtract Exchange Fee and Wallet Type options on the pool's Pricing tab to deduct these fees from NiceHash price estimates. This helps to provide more accurate comparisons to other pools that do not charge these fees.

Zergpool

• Consider enabling the MC Parameter on the Pricing tab to mine specific coins on Zergpool versus mining on just the auto-switch ports. You can still auto-exchange to BTC or LTC, but the software will calculate the most profitable coin per algorithm instead of using the pool's auto-switch port. Since these coins are not always the same ones currently mined by the pool's auto-switch ports and have differing levels of usage, they are sometimes more profitable.
• The Include Auto-Switch Ports option can be used to enable or disable use of Zergpool's ports that automatically switch coins for each algorithm. Hash Auger users can enable both options to have the software compare prices between both individual coins and the auto-switch ports to see which has the best prices. Alternatively, the auto-switch ports can be disabled when the MC Parameter is used to avoid mining on these more heavily-used ports.

[preda]

The following are some pool-specific options that new Hash Auger users may not be aware of:

The following are some configuration tips that can help new users setup Hash Auger for use with pools that have unique configuration options.

MiningPoolHub

• If you are using the pool's auto-exchange feature, the Subtract Exchange Fee option on the pool's Pricing tab can be used to include cost of auto-exchanging in the algorithm-switching calculations when comparing estimates for different pools.
• Users with many GPUs may want to try enabling the Include Auto Switch Port option (also on the pool's Pricing tab) to mine on MPH's 17xxx ports. These ports tend to have a higher difficulty than the 20xxx ports Hash Auger uses, but may be profitable for users mining with significant hashing power.

NiceHash

• Use the Subtract Exchange Fee and Wallet Type options on the pool's Pricing tab to deduct these fees from NiceHash price estimates. This helps to provide more accurate comparisons to other pools that do not charge these fees.

Zergpool

• Consider enabling the MC Parameter on the Pricing tab to mine specific coins on Zergpool versus mining on just the auto-switch ports. You can still auto-exchange to BTC or LTC, but the software will calculate the most profitable coin per algorithm instead of using the pool's auto-switch port. Since these coins are not always the same ones currently mined by the pool's auto-switch ports and have differing levels of usage, they are sometimes more profitable.
• The Include Auto-Switch Ports option can be used to enable or disable use of Zergpool's ports that automatically switch coins for each algorithm. Hash Auger users can enable both options to have the software compare prices between both individual coins and the auto-switch ports to see which has the best prices. Alternatively, the auto-switch ports can be disabled when the MC Parameter is used to avoid mining on these more heavily-used ports.

So which pool do you suggest?

[HashAuger]

The following are some pool-specific options that new Hash Auger users may not be aware of:

The following are some configuration tips that can help new users setup Hash Auger for use with pools that have unique configuration options.

MiningPoolHub

• If you are using the pool's auto-exchange feature, the Subtract Exchange Fee option on the pool's Pricing tab can be used to include cost of auto-exchanging in the algorithm-switching calculations when comparing estimates for different pools.
• Users with many GPUs may want to try enabling the Include Auto Switch Port option (also on the pool's Pricing tab) to mine on MPH's 17xxx ports. These ports tend to have a higher difficulty than the 20xxx ports Hash Auger uses, but may be profitable for users mining with significant hashing power.

NiceHash

• Use the Subtract Exchange Fee and Wallet Type options on the pool's Pricing tab to deduct these fees from NiceHash price estimates. This helps to provide more accurate comparisons to other pools that do not charge these fees.

Zergpool

• Consider enabling the MC Parameter on the Pricing tab to mine specific coins on Zergpool versus mining on just the auto-switch ports. You can still auto-exchange to BTC or LTC, but the software will calculate the most profitable coin per algorithm instead of using the pool's auto-switch port. Since these coins are not always the same ones currently mined by the pool's auto-switch ports and have differing levels of usage, they are sometimes more profitable.
• The Include Auto-Switch Ports option can be used to enable or disable use of Zergpool's ports that automatically switch coins for each algorithm. Hash Auger users can enable both options to have the software compare prices between both individual coins and the auto-switch ports to see which has the best prices. Alternatively, the auto-switch ports can be disabled when the MC Parameter is used to avoid mining on these more heavily-used ports.

So which pool do you suggest?

I hesitate to make specific suggestions since there a number of factors that influence the decision for each user. Some users prefer earnings consistency versus maximizing potential payouts. Similarly, some users prefer pools with relatively low minimum payout amounts while others are willing to keep higher unpaid balances on a pool if the pool offers other advantages. Preferred payout coin, the location of the pool servers to the miner and the miner’s preferred algorithms/coins are also important considerations.

Since Hash Auger supports several auto-exchange pools and many more pools that don’t auto-exchange, my advice is to look at what other miners are saying about each pool in the Pools child board of this message board. Then, choose two or three pools that seem to be the most compatible with your personal mining goals and strategy. BlazePool is really popular right now if you want to auto-exchange to BTC, so perhaps you would like to beigin your research there, but I recommend reviewing at least a few pools to see how they all compare.

[pizzaslut]

I don't think the app(latest version) is working correctly as it's going below the minimum earnings for my gpu and does nothing with the cpu. When I choose a coin manually like cryptonightV7 it works and is above the min earnings. One would think it should work in auto switching, but that is not the case. Thank you.

[HashAuger]

I don't think the app(latest version) is working correctly as it's going below the minimum earnings for my gpu and does nothing with the cpu. When I choose a coin manually like cryptonightV7 it works and is above the min earnings. One would think it should work in auto switching, but that is not the case. Thank you.

I'm having trouble reproducing your issue.  If I set the minimum earning level higher than what my GPUs can earn ($10 for example), the Profitability grid is blank (because all the estimates have been filtered out since they are below the minimum) and nothing is mined. If I revise the Minimum Earnings Amount to a more realistic level ($2), then the profitability grid shows only those algorithms that have an estimated earnings higher than that amount and will mine whichever has the highest value. If I set the Minimum Earnings Amount to 0, then I see all enabled algorithms that are supported by the pools I am currently using.

The same thing happens with the CPU. If I set the Minimum Amount to $1.25, the software won't use the CPU because there currently isn't an algorithm that offers that kind of a return on an i7.  However, if I lower the estimated earnings to .25, then there are a couple of CPU algorithms that have higher estimated earnings and there were not any problems mining those algorithms on my machine.

I should point out that the Minimum Earnings Amount only prevents an algorithm with a low estimated earnings from being mined in the first place, but it is not used during mining to stop the current work. You may occasionally see the estimated earnings for the current mining job fall below your minimum amount.  This can happen if the device's current hash rate is below the device's benchmark and historical rates for that algorithm.  The software won't stop mining that algorithm when the price falls below the minimum amount because those dips are usually temporary. You would most likely lose more profits stopping work and switching to something else when your estimated earnings dipped below the minimum for a minute or two than if your cards just kept mining the algorithm despite the lower than expected rate. 

[pizzaslut]

I have gpu set to $1 and cpu to .65 cents. It was on that really low earning(.55 cents) for one gpu for the whole 25 minutes before switching. I have to manually select with cpu just to get it mining at .75 cents on NiceHash on cryptonightV7 for example). On another note I also had the app crash on me two days in a row when I was not home. Not sure what time it crashed but it did. Overnight it was fine.

[HashAuger]

I have gpu set to $1 and cpu to .65 cents. It was on that really low earning(.55 cents) for one gpu for the whole 25 minutes before switching. I have to manually select with cpu just to get it mining at .75 cents on NiceHash on cryptonightV7 for example). On another note I also had the app crash on me two days in a row when I was not home. Not sure what time it crashed but it did. Overnight it was fine.

The software only switches work if there is an algorithm with an estimated earnings that is greater than the current algorithm plus the Minimum Switch Percent, so it won't always switch at the frequency you have set in the settings. You should compare the benchmark rates for the GPU to your actual hash rates and see if the GPU is mining lower than what it was benchmarked at.  If the hash rates are considerably different, you may need to benchmark again or change the preferred miner for that algorithm.

Similarly, what's your benchmark rate for CyrptonightV7 on your CPU? Considering that there is only ten cents difference between your minimum amount and the actual amount, it wouldn't take much difference in hash rate for the software to calculate estimated earnings below your minimum amount, preventing it from mining that algorithm on your CPU automatically. You must have a really good CPU because my i7 is estimated to earn only 10 cents a day mining Cryptonight on NiceHash.

Sorry to hear that some of the new miners may be causing issues on your system. As mentioned earlier in this thread, some users have had issues with Alexis miner on some GPUs, especially ones that have been overclocked. Since ccminer-phi is based on Alexis, it may have some similar effects.  If you send me a copy of your log files, I can take a look to determine which algorithm and GPU may be causing the stability issue on your system. You could also try disabling Alexis and/or ccminer-phi for the few algorithms that use either of these miners or if you are overclocking, you could try lowering the overclock settings for any algorithm that uses either of those miners as its preferred miner.

[pizzaslut]

I have a Ryzen R5 1500x, maybe why I'm getting solid hashrates(Gen1 R7 users are saying they are getting a little over a $1). I will have to see if it's alexis miner causing the issue.

[HashAuger]

I have a Ryzen R5 1500x, maybe why I'm getting solid hashrates(Gen1 R7 users are saying they are getting a little over a $1). I will have to see if it's alexis miner causing the issue.

That must be it, Ryzens always did better than Intel CPUs at Cryptonight.  I'll have to try to mine again with my own to see if they will do better now than they were doing before the fork. You may want to disable Alexis and ccminer-phi temporarily for any algorithms that currently use them as their preferred miners and see if that helps your stability. You could then re-enable each miner for one algorithm at a time and see if that causes any issues before enabling the next. Or if you prefer, you could just disable both miners, especially if their performance is not muc better than the alternatives for the algorithms you are interested in.

[DirkGroenewald]

What is the best setting for Pool Refresh Rate. Short time 10min or 30 min. Can I make the refresh rate short 10 and the price switch 15. Will that work?

[HashAuger]

What is the best setting for Pool Refresh Rate. Short time 10min or 30 min. Can I make the refresh rate short 10 and the price switch 15. Will that work?

Good question. Which value you prefer for the Pool Refresh Rate depends on your mining strategy.  A shorter refresh rate is good if you prefer small shares in coins with the highest estimated earnings. That will help spread your mining work around and help reduce the risk of investing too much time in a coin whose value drops after you mine it, but before the pool pays your share for it. A longer refresh rate can help you earn bigger shares in a smaller number of coins.  That can pay off for high-value coins that are not mined quickly, like Raven. However, the downside is that you are more at risk for losing productivity to orphan coins and those coins whose values are falling.  I've been doing some experimenting with my own rigs and have found 10-15 minutes seems to have the best average earnings per day for my setup (mostly 1080s).

For a ten minute refresh rate, I definitely recommend at least a 10% price switch based on the fact that the process of switching algorithms will probably cost you a minute of mining time by the time the new mining work reaches full productivity.  But ten percent only covers the cost of that lost minute, so it is often better to use a price switch of at least 12% or 15% to make sure it is profitable (rather than just breaking even) to switch than continue mining the current coin.  

You may also want to consider setting a Price Spike Limit on your GPUs to filter out coins whose prices are just too high to be realistic.  Unfortunately, there are a few situations, such as orphan coins and sudden changes in the coin's pricing data that can cause a pool to temporarily provide an inaccurate estimate of a coin's worth.  Not only will the payout be much lower than the estimate in these situations, a lot of other programs will switch miners to these coins simply because the price is the highest, which drives up the coin's difficulty and lowers your potential payout even more. I find it best to just ignore these coins, so I set my Price Spike Limits to be a few dollars of what the average for a GPU usually is. For example, right now for a 1080, I might have a spike limit of $6.00 or $7.00.  That way, there is still flexibility to take advantage of appreciating coin values while not having to worry about wasting time mining any coins whose earnings briefly spike over that amount.

Thanks for trying out the software. Please let me know if you have any other questions or feedback.


 

[DirkGroenewald]

Thanks for reply and a good program. I update the program to the new version 1.8.6.
For the last 3 days the program stop to work during the night.

I do the following for the program to start automatic:-
1. press Windows (on keybord the windows flag left bottom) and r at the same time.
2. Type Shell:startup.
3 Copy shortcut (HashAuger – Shortcut)  to autostart the mining file in the mining directory.

The start app is also on in the mining program.
This do not work. What can I do?

[HashAuger]

Thanks for reply and a good program. I update the program to the new version 1.8.6.
For the last 3 days the program stop to work during the night.

I do the following for the program to start automatic:-
1. press Windows (on keybord the windows flag left bottom) and r at the same time.
2. Type Shell:startup.
3 Copy shortcut (HashAuger – Shortcut)  to autostart the mining file in the mining directory.

The start app is also on in the mining program.
This do not work. What can I do?

If you have User Access Control enabled on your computer, the UAC prompt is mostly likely preventing the software from starting.  I have instructions on how to create an administrator level task for Hash Auger that bypasses the UAC prompt and automatically starts the application on startup. These instructions are included in the first item on the FAQ page: https://hashauger.com/faq.html.  Once the UAC dialog is bypassed, the application should start mining automatically if you have that setting turned on.

As for the stability issues, some users are having issues with the Alexis and CCMiner-Phi mining software.  While these miners are fast at few algorithms, they tend to cause more device driver issues that require reboots. If you turn on Hash Auger's log setting, you can see what algorithm your system was mining when the problem occurred and then change its preferred miner.  Alternatively, you could change the preferred miner for all of the algorithms that currently use either Alexis or ccminer-Phi if you would rather not use those two at all.

[HashAuger]

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?

1.8.7 improves the tolerance of communication failures with the pools so that brief failures will be less likely to cause a pool to be temporarily suspended. I also reworded the warning messages for clarity and to better distinguish them from other types of warnings.

[jbeck]

whats is the names of the new miners?

[HashAuger]

whats is the names of the new miners?

1.8.7 updates existing miners. Z-Enemy is updated to version 1.09 and SPMod-Raven is updated to 4a. Both of these updates promise better x16r hash rates than previous versions. Also, the new version of Z-Enemy adds support for Xevan.