Hash Auger 2.9.7.5 Mining Manager and Switcher for NVIDIA GPUs

[Zirillian]

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.

I haven't forgot about this.  I was going to start working on it a few days ago, but then one of the big pools went offline for a few hours and I took that as an opportunity to improve the way the software handles that type of error to minimize downtime.  Also, recent discussions inspired  me to look at ways to improve mining performance in general.  However, creating a centralized device manager is still one of my priorities for 1.9.  I want to accommodate users with mixed rigs (1070s, 1080s, etc) that may not want to apply the same set of settings to every card as well as users that only use the same type of card in the same rig.  Basically, my design intent is to replace the current list of device panels with a display that doesn't require as much scrolling. 

Yep sounds good. Thanks for addressing.

[1715081449]

1715081449

[1715081449]

1715081449

[1715081449]

1715081449

[1715081449]

1715081449

[1715081449]

1715081449

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

I haven't forgot about this.  I was going to start working on it a few days ago, but then one of the big pools went offline for a few hours and I took that as an opportunity to improve the way the software handles that type of error to minimize downtime.  Also, recent discussions inspired  me to look at ways to improve mining performance in general.  However, creating a centralized device manager is still one of my priorities for 1.9.  I want to accommodate users with mixed rigs (1070s, 1080s, etc) that may not want to apply the same set of settings to every card as well as users that only use the same type of card in the same rig.  Basically, my design intent is to replace the current list of device panels with a display that doesn't require as much scrolling. 

Yep sounds good. Thanks for addressing.

Cool.  Since it has taken me a little longer to implement this feature than I originally intended and it makes since to have all the device management enhancements grouped together in the versioning scheme, I will try to release 1.8.3 with this change in a few days.  Some of the other improvements I have planned for 1.9 may take a little longer to implement, so I don't want to hold this request back longer than necessary.

[trucobit]

I liked the update, I'm testing it in the small rig only in x17, Alexis makes a difference.

I did not know that before in the autochange pools, the disabled protocols worked equally. It is good to know that now it fulfills that condition.

I still think there are no miners, but I see that their intention is to add them more and more.

I'm going to tell you something that no software does and what they should do, a super optimization that would take many hours, but that would give the best performance for each protocol and card, something that you promise in this program.

You make the typical benchmark pass to know the HASH you have in each protocol. But what do you do to maximize that? . The process of manual optimization is very heavy, so it will be good for people with experience to save time and without experience. It should be optional. The default values ​​or what works for others may not be the best for me or my brand of card.

They should be two different steps, and should be launched separately on two buttons to avoid too many hours.

1 phase:
IMPORTANT in this phase, ignoring the OC values ​​completely, must be a pure test.

I would only do the optimization in the activated Protocols, those that are deactivated or must obviously be ignored. Or you could do one by one to each protocol, but I'm more interested in leaving it working hours and in the end having the best configuration

It would be based on the optimization of mining and intensity. Basically I will go to each protocol and all the miners of that protocol, and I say all that can be chosen, whether or not they are activated.

Image we have only activated X17, go to x17 and try the 4 miners there. Try the first one, for example Klaust and do the intensity test from 15 to 31 which is the maximum in jump ranges of 0.3. I would try klaust at 15 - 15.3 - 15.6 - 15.9 ....... until the failure or the maximum that is 31

If it fails, it repeats the test in that same fault intensity, and when it fails twice, it is the fault, for example in 19.6. At that point we took two jumps back, that is, 0.3 and 0.3 = 0.6, and the chosen intensity would be 19.

Then repeat the same procedure with miner 2, miner 3, miner 4 ...

at the end for that protocol, x17, it should self-select only the fastest miner of those that have been tested.

This first pass would choose the best miner for the selected protocol.

2 phase

Focus on intensity and OC at the same time, trying not to be too many steps, but there must be many steps.

There are many tests for a single protocol. Following the previous example, I would have selected X17 and Alexis, probably over 19 (I know because I've tried it).

The variabesl that I am going to give you, I have thought about them for a long time and it is like work, but of course I leave many steps because I have to do it one by one by hand. And with this even if it takes a day, you have the best result.

Intensity: we have the before, in this case 19, because tests will be done in 18 - 18.5 and 19

Core: -20 to +200 in breaks of 10. bone -20, -10, 0, +10, +20 .....

memory, from -200 to +400 in steps of 100, are 6 steps

TP, power supply, from 70 to 100 in jumps of 5. Again there are 6 steps.

To reduce the time, it would be done in two subprocesses. First optimization of the combo (intensity and core), all steps, failures are controlled and are not valid, but you have to do all the steps to know which yields more.
The second subprocess would also be using the core, but the number that we already have before, for example, has given the number 90 of core. Well we will use that number + - 10, in this case 80 - 90 - 100, and the formula would be

(core as I have explained, mem, prower supply), all the steps are done, the errors are ignored, and you only keep the results, choosing the one that more HASH provides.

And it would be optimized. It can be improved more, and it is not only taking into account only the HASH, but also the number of actions taken. Sometimes a very high intensity, because here it affects above all the intensity that is the one that adds more or less load to the nuclei. Well, it is not the same to do at the same time 5 hashes confirmed at 12 mhs, that 8 hash at 11 mhs. Although the Hash is smaller (11mhs) there have been more shares. And you must if you can, because here I think you can not do with those that you can not read, but it would be interesting if you can have both data, well 3.

Test time, maximum hash, number of shares

The idea is that at the same time the combination of shares + HASH is superior. This fits only with intensity, so it may or may not be easy.


I said I was not going to try it, but I see so much potential, and I fully understand that being a single programmer with limited time, do not develop as fast as we would like.
I mention this from the point of view of contributing ideas and suggestions, especially of some things that ALL others do not have.

If I had to choose between what to prioritize, if more miners or if you like the idea of ​​super optimization, choose the super optimization.

Nobody else has it, make the most of each card and each configuration, save time for experts and help newbies. And from the point of view of programming I think it would be easier to super optimize, I really think it is more difficult to explain than to program it. The programming would be about what is already there, because you do not have to change anything, just add those extra steps for those who want to lose a whole day and have the perfect configuration, and if it is not, it will be very close. And at this point I would add that a final control point, also optional, would be obligatory, and that optimized configuration will work for at least 10 minutes in a row, if it passes ok, and if not, it goes back to the previous point of optimization and repeats discarding if you get the same result

With this you will maximize your software before taking the next steps, it will stand out as the main quality against your competition and most importantly, the best daily profit rate. It is important to have intensity and OC adjusted for something, it is the key to profitability.

Once done, it would be a great platform to scale your software with new functions or miners, it is best to take advantage of what is already there, and make the tests as long as it takes to maximize profit.
I think that is just what it takes to be unique and really useful. Do not put ma configurations almost at random and settle for the result. I think that can silence many voices that say they say it does not pay.

Nice hash is hard to beat in benefits but some programs do. Some very good ones like AW lack optimization by protocol and card, and neither a super opcimizacion, also you have to pay for advanced functions. Others are more difficult and data is lost in each update.

You have a lot of auto change groups and to mine directly. You can mine with auto change and at the same time a coin. It has a good profit but it must adjust very well, it has intensity settings, and more important of OC for each protocol and card. Basically it has everything, it can be improved with more functions and pools etc .. But from my humble opinion you need a software that is able to get the best possible configuration for each machine, whatever this machine, have plenty of memory or it lacks, it has more or less CPU and with certain intensities it drowns. For me the super optimization would be the serious takeoff of Hash Auger, that every day I like more.

Regards

Note:
I forgot the tests should be done with all the cards at once. Not for saving time. It is because in real mining they will all be working at the same time creating bottlenecks in some points. It would not be appropriate to do the test with independent cards or one at a time. The test should be how it would be more or less the use when it is mined and not all have the same memory, motherboard and CPU equal.

[trucobit]

In the auto exchange pool configuration, there is the option to exclude protocols. But again, it's one on one. It would be good options to copy from another pool, or even copy to all pools that selection of protocols.

In the auto exchange pool configuration, there is the option to exclude protocols. But again, it's one on one. It would be good options to copy from another pool, or even copy to all pools that selection of protocols.

You may want to have all the same, but in some pool I can make a different change, but it would be punctual. It should be easier to copy that configuration to other pools easily, as you did in the graphics card section

[HashAuger]

In the auto exchange pool configuration, there is the option to exclude protocols. But again, it's one on one. It would be good options to copy from another pool, or even copy to all pools that selection of protocols.

In the auto exchange pool configuration, there is the option to exclude protocols. But again, it's one on one. It would be good options to copy from another pool, or even copy to all pools that selection of protocols.

You may want to have all the same, but in some pool I can make a different change, but it would be punctual. It should be easier to copy that configuration to other pools easily, as you did in the graphics card section

In the auto exchange pool configuration, there is the option to exclude protocols. But again, it's one on one. It would be good options to copy from another pool, or even copy to all pools that selection of protocols.

In the auto exchange pool configuration, there is the option to exclude protocols. But again, it's one on one. It would be good options to copy from another pool, or even copy to all pools that selection of protocols.

You may want to have all the same, but in some pool I can make a different change, but it would be punctual. It should be easier to copy that configuration to other pools easily, as you did in the graphics card section

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.

[jbeck]

If you go too far with super optimization and and the program becomes buggy and I end up losing a half day because i cant get back to restart, the little 3 or 4% gain is not going to be worth it to me.  Dont get baited into making something too complicated. 

[HashAuger]

If you go too far with super optimization and and the program becomes buggy and I end up losing a half day because i cant get back to restart, the little 3 or 4% gain is not going to be worth it to me.  Dont get baited into making something too complicated. 

You bring up a good point. Even a moderate increase in hash rates isn’t going to offset lost earnings due to downtime if a system is pushed to the point of instability. My development priority will always be stability, so any settings that may boost performance at the risk of stability will be disabled by default. Similarly, I like to see how new mining software is received and evolves before I add it to the software. It took me a while to find a version of Alexis that appears to be stable on modern cards. Also, it is important to keep in mind that hash rates aren’t the only factor that affects earnings. A 5% increase in hash rates means little if you are mining coins at a 10% lower price than what you could be. Therefore, I try to improve the software in a more balanced aproach rather than just focusing on any one aspect.

[jbeck]

A bit unrelated.  I was looking into a hard wallet like trezor.  I currently am using hashauger with blazepool.  I set blazepool to pay into my exodus wallet.   I have both some litecoin and some bitcoin in there.  Blazepool only pays in bitcoin.  Is there a way to receive my payment from blazepool directly to my hard wallet.   Reason I ask is the fees that are charged on exodus are a bit high.   You guys have more experience than me.  I dont know if exchanging my bitcoin to litecoin in exodus then transfer my litecoin balance to my trezor is cost efficient.  Or should I send both coins to my hard wallet and find another exchange site to exchange later.   BTW I made more money today with the increase in altcoins than I mined.  Yay..

[HashAuger]

A bit unrelated.  I was looking into a hard wallet like trezor.  I currently am using hashauger with blazepool.  I set blazepool to pay into my exodus wallet.   I have both some litecoin and some bitcoin in there.  Blazepool only pays in bitcoin.  Is there a way to receive my payment from blazepool directly to my hard wallet.   Reason I ask is the fees that are charged on exodus are a bit high.   You guys have more experience than me.  I dont know if exchanging my bitcoin to litecoin in exodus then transfer my litecoin balance to my trezor is cost efficient.  Or should I send both coins to my hard wallet and find another exchange site to exchange later.   BTW I made more money today with the increase in altcoins than I mined.  Yay..

I’m glad to hear that your earnings are getting better. Hopefully the worst of the slump is behind us. For security reasons, most hard wallets are not connected to the Internet all the time, but it looks like Trezor has some services that act like temporary wallets until you connect your hard wallet to the network. So you should be able to use the Trezor wallet address for your mining and the Trezor software should handle moving the funds between the software and hardware wallets. Maybe somebody using that setup can comment on whether there are any fees involved. I’m not sure if that transaction between the Trezor soft and hard wallets is on the network and subject to fees or not.

Concerning exchange fees, you may want to compare the rates Exodus charges with other exchanges and see if you can reduce costs by using a different exchange (Like CoinBase, Poloniex or Kraken) or by exchanging a larger amount less frequently. If you don't want to keep too much of your earnings in an exchange wallet for security reasons, you could use a software wallet such as Electrum to temporarily hold your BTC payments from the pool until you accumulate enough to do a more cost-efficient exchange or to time your trade when the price of LTC is low compared to BTC. Then you could have the exchange deposit your LTC into the Trezor wallet. Of course, you'd have to pay transaction fees every time you move your earnings, so it is usually best to minimize transfers/exchanges as much as possible. However, keeping a little in BTC might help you diversify your holdings in case both coins don't appreciate in value at the same rate.

If you do change wallet addresses on the pool, you will have to plan the switch around the pool’s payout schedule to make sure the earnings linked to the old wallet address are above the pool’s minimum payout.

[trucobit]

I answer everyone for this post.

It can be complicated, I just explain an idea, it can be made easier or lighter, but something that helps to look for better optimization. It can be with fewer options and making it protococolo to protocol choosing which to optimize.

A good optimization is not 3 or 4% more, of course not. That would be in another product where the OC is the same in all protocols, the best thing about HA is the OC for each protocol, but it takes a lot of time to do it by hand, a lot .. I prefer that I do it alone while I do other things. I do prefer to lose a whole day and have a good OC, which would surely be a benefit greater than 10%. There are protocols that have very different combinations of OC to other protocols.

In the same way this would add stability that this is also what is sought. Leaving a general OC for all defined is not optimal. Putting OC data more or less at random does not maximize revenue either.

As I said and explain, I would vote for a better optimization on the basis that it is already done. It has a lot of potential and it can be easier than I explain. And above all, it would give a comparative value to better HA compared to its competition, which none have.

It is Spain there is a refrain that says, (To see how it is translated). Better skill than strength . In this case it would not be to put more miners or more pools, the software has everything and can be improved but it is not the most important from my point of view. The skill would be the ease of the software to optimize itself to a better point, if one wants, it would be optional.

POder have a good fit for each protocol, both in intensity and OC, it would be much more than 3 or 4%, rather more, apart from being more stable, as long as self opmice discard the combinations that give error or produce restarts.

It is just an idea, that at least I worry about giving ideas to add value to the product. I take my time, I report errors and I give my ideas based on the experience. and as I say it could be totally optional for whoever wants, but highly recommended to do it.

I thank the programmer for the effort and wish him the best. Also say that I would even be willing to pay slightly more in dev fee if the product is modernizing and trying to be a real alternative to other products that are expensive like AW and that lacks some functions that exist in HA

[trucobit]

In the auto exchange pool configuration, there is the option to exclude protocols. But again, it's one on one. It would be good options to copy from another pool, or even copy to all pools that selection of protocols.

In the auto exchange pool configuration, there is the option to exclude protocols. But again, it's one on one. It would be good options to copy from another pool, or even copy to all pools that selection of protocols.

You may want to have all the same, but in some pool I can make a different change, but it would be punctual. It should be easier to copy that configuration to other pools easily, as you did in the graphics card section

In the auto exchange pool configuration, there is the option to exclude protocols. But again, it's one on one. It would be good options to copy from another pool, or even copy to all pools that selection of protocols.

In the auto exchange pool configuration, there is the option to exclude protocols. But again, it's one on one. It would be good options to copy from another pool, or even copy to all pools that selection of protocols.

You may want to have all the same, but in some pool I can make a different change, but it would be punctual. It should be easier to copy that configuration to other pools easily, as you did in the graphics card section

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.

[HashAuger]

I answer everyone for this post.

It can be complicated, I just explain an idea, it can be made easier or lighter, but something that helps to look for better optimization. It can be with fewer options and making it protococolo to protocol choosing which to optimize.

A good optimization is not 3 or 4% more, of course not. That would be in another product where the OC is the same in all protocols, the best thing about HA is the OC for each protocol, but it takes a lot of time to do it by hand, a lot .. I prefer that I do it alone while I do other things. I do prefer to lose a whole day and have a good OC, which would surely be a benefit greater than 10%. There are protocols that have very different combinations of OC to other protocols.

In the same way this would add stability that this is also what is sought. Leaving a general OC for all defined is not optimal. Putting OC data more or less at random does not maximize revenue either.

As I said and explain, I would vote for a better optimization on the basis that it is already done. It has a lot of potential and it can be easier than I explain. And above all, it would give a comparative value to better HA compared to its competition, which none have.

It is Spain there is a refrain that says, (To see how it is translated). Better skill than strength . In this case it would not be to put more miners or more pools, the software has everything and can be improved but it is not the most important from my point of view. The skill would be the ease of the software to optimize itself to a better point, if one wants, it would be optional.

POder have a good fit for each protocol, both in intensity and OC, it would be much more than 3 or 4%, rather more, apart from being more stable, as long as self opmice discard the combinations that give error or produce restarts.

It is just an idea, that at least I worry about giving ideas to add value to the product. I take my time, I report errors and I give my ideas based on the experience. and as I say it could be totally optional for whoever wants, but highly recommended to do it.

I thank the programmer for the effort and wish him the best. Also say that I would even be willing to pay slightly more in dev fee if the product is modernizing and trying to be a real alternative to other products that are expensive like AW and that lacks some functions that exist in HA

I thank you for your suggestion.  I do not doubt that auto-tuning of overclocks would be a very useful feature.  As you noted, many miners choose a less than optimal general overclock because they do not want to invest the time in finding the optimal overclock for each algorithm. However, there is a saying that "the devil is in the details" -  a concept can appear to be simple, but on closer inspection it is much more complicated than it first appeared. A human can easily determine if a video card is becoming unstable (visual artifacts on the screen, for example), but the software cannot.  Also, as I mentioned before, the software would have to recognize system crashes so that it avoids using those settings again. There is also a big difference in a miner being stable for a few minutes versus hours or days.  Most users would want the auto-overclock tool to complete in a reasonable amount of time, but the tool would have to test multiple clock settings for many algorithms, limiting the duration of each individual stability test and increasing the potential that the software incorrectly assumes an overclock to be stable when it really is not.

Again, I'll use EVGA's auto-overclock tool as an example.  I have never been able to get it to work on EVGA cards and many of its users report similar issues.  If a graphics card manufacturer cannot reliably find  an optimal gaming overclock for their own products, think of how much more difficult it would be to calculate optimal overclocks for different types of cards using different algorithms and miners within a period of time that most users would tolerate. While it wouldn't be impossible, it would be a significant investment in development time that would come at the expense of most other improvements to the software.

[quantummining]

I am using this personally on some of my miners.  Working excellent 5 - 12 gpu rigs (nVidia) - On our pool at www.QuantumMiningPool.com

I am a single coin miner, I HATE when someone converts my work to BTC... (fees, not timed right, coin collector, etc...)

[trucobit]

I'm having a performance problem with Alexis. In the previous version its performance was as expected, now with x17 gives values ​​lower than normal.

I have tried activating the ccminer cache or whatever that option is called that greatly increases the use of cpu, and without the option marked. when before it reached 18mhs in x17 now I do not exceed 16 mhs. In these last days I changed the g4400 for an i3, and added better sources to the rig to force the maximum, and as a consequence now I see that version 1.8.2 alexis does not perform well.

He has considered adding some option so that a rig with all its cards only mine a protocol in a single process. You comment that it is more efficient to do it for each card. But I in x17 with alexis with manual configuration I do 122 mhs with all at once, which is more than 20 mhs per media card. With your program and one process per card, the performance is lower, I'm not sure of the efficiency at all.

Also comment that in the zergpool post in bitcointalk ANN, the owner of the pool indicates that zergpool is not very suitable for auto exchange because they update prices very slowly. It is not that they put a better price, is that they do not update frequently and usually cheats bots like this one with inadequate prices that can not be corrected with the% price option.

It would not be advisable not to use it, I leave it as a comment more

[pizzaslut]

Okay for some reason it's mining, but nothing is actually happening. Like hash is at 0, and profits are 0 even after waiting for 5 minutes for all three of my gpu(cpu didn't hit the threshold). One gpu is on zergpool, one on zpool, and one on ahashpool. I am not sure how often this happens as I am work during the day, but this has me a bit concerned.

[HashAuger]

Okay for some reason it's mining, but nothing is actually happening. Like hash is at 0, and profits are 0 even after waiting for 5 minutes for all three of my gpu(cpu didn't hit the threshold). One gpu is on zergpool, one on zpool, and one on ahashpool. I am not sure how often this happens as I am work during the day, but this has me a bit concerned.

You can check your wallet at each of those pools to see your activity for the last 24 hours.  What are the miner panels/windows showing? Any errors?  Is the miner getting work but not finding results?  For more accurate earning estimates, the hash rate is based on results, not the hash rate in between results and the numbers will stay at 0 until the first result has been found.  Sometimes it can take a few minutes before the first result has been found. In these cases, the miner text often shows a lot of messages indicating new work and changes in difficulty.

[HashAuger]

I'm having a performance problem with Alexis. In the previous version its performance was as expected, now with x17 gives values ​​lower than normal.

I have tried activating the ccminer cache or whatever that option is called that greatly increases the use of cpu, and without the option marked. when before it reached 18mhs in x17 now I do not exceed 16 mhs. In these last days I changed the g4400 for an i3, and added better sources to the rig to force the maximum, and as a consequence now I see that version 1.8.2 alexis does not perform well.

He has considered adding some option so that a rig with all its cards only mine a protocol in a single process. You comment that it is more efficient to do it for each card. But I in x17 with alexis with manual configuration I do 122 mhs with all at once, which is more than 20 mhs per media card. With your program and one process per card, the performance is lower, I'm not sure of the efficiency at all.

Also comment that in the zergpool post in bitcointalk ANN, the owner of the pool indicates that zergpool is not very suitable for auto exchange because they update prices very slowly. It is not that they put a better price, is that they do not update frequently and usually cheats bots like this one with inadequate prices that can not be corrected with the% price option.

It would not be advisable not to use it, I leave it as a comment more

As I mentioned before, running each miner in its own process provides efficiency improvements for some algorithms, but that depends on the hardware and the algorithm. Running each GPU with its own process also increases error tolerance and allows each GPU to run a different algorithm when it is more profitable to do so.  Since you changed your hardware at the same time, I am not sure how you can attribute the decrease in hash rate on solely the new version of the software. Hash rates depend on different factors, especially algorithms such as x16r and x17 that run a series of algorithms to produce a single result.  Multiple pools are included in the software so that users can find ones that they like and none of them are enabled by default.  If a user doesn't like Zergpool, they don't have to use it.

[HashAuger]

I am using this personally on some of my miners.  Working excellent 5 - 12 gpu rigs (nVidia) - On our pool at www.QuantumMiningPool.com

I am a single coin miner, I HATE when someone converts my work to BTC... (fees, not timed right, coin collector, etc...)

Thanks for the feedback. I definitely encourage any miner who doesn't auto-exchange to take a look at your pool.  Based on just your selection of coins as well as the geographic coverage and performance of your servers, you have a lot to offer, not to mention the accessibility of pool admins on Discord.

[pizzaslut]

Okay for some reason it's mining, but nothing is actually happening. Like hash is at 0, and profits are 0 even after waiting for 5 minutes for all three of my gpu(cpu didn't hit the threshold). One gpu is on zergpool, one on zpool, and one on ahashpool. I am not sure how often this happens as I am work during the day, but this has me a bit concerned.

You can check your wallet at each of those pools to see your activity for the last 24 hours.  What are the miner panels/windows showing? Any errors?  Is the miner getting work but not finding results?  For more accurate earning estimates, the hash rate is based on results, not the hash rate in between results and the numbers will stay at 0 until the first result has been found.  Sometimes it can take a few minutes before the first result has been found. In these cases, the miner text often shows a lot of messages indicating new work and changes in difficulty.

Stats window is showing it is on a pool and coin, but hash is 0 and accepted is 0 out of 0. Odd.

[HashAuger]

Okay for some reason it's mining, but nothing is actually happening. Like hash is at 0, and profits are 0 even after waiting for 5 minutes for all three of my gpu(cpu didn't hit the threshold). One gpu is on zergpool, one on zpool, and one on ahashpool. I am not sure how often this happens as I am work during the day, but this has me a bit concerned.

You can check your wallet at each of those pools to see your activity for the last 24 hours.  What are the miner panels/windows showing? Any errors?  Is the miner getting work but not finding results?  For more accurate earning estimates, the hash rate is based on results, not the hash rate in between results and the numbers will stay at 0 until the first result has been found.  Sometimes it can take a few minutes before the first result has been found. In these cases, the miner text often shows a lot of messages indicating new work and changes in difficulty.

Stats window is showing it is on a pool and coin, but hash is 0 and accepted is 0 out of 0. Odd.

Can you copy and paste an example of the miner output?  Are there accepted results in the miner window? Which miner is it?