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

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?

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.

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.

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.

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.

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. 

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

So which pool do you suggest?

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.

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.   

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.

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.

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.


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.


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.


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.

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

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

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

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

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

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

Keep up the good work.

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

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

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

sigh....

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