Hash Auger 2.9.7.5 Mining Manager and Switcher for NVIDIA GPUs

[HashAuger]

I;ve been mining for a while now, bt curious to know how payout works? Like it is it automatic or do I have to go to like zpool and transfer it?

The pools control the payouts and while they all offer automatic payouts, the minimum requirements and payout schedule vary per pool. In the case of Zpool, the website says that it will pay out balances greater than .01 BTC once a day and balances greater than .0025 several times a week. Once your balance reaches the minimum, the payout is automatically sent to the BTC address you have been using. Many user limit the number of pools that they mine to just a few to reduce the time it takes to reach the minimum payout balance at any one pool.

[1715388313]

1715388313

[1715388313]

1715388313

[1715388313]

1715388313

[1715388313]

1715388313

[1715388313]

1715388313

[1715388313]

1715388313

[HashAuger]

I understand their explanations but for what a benchmark serves that ignores my configurations and also freezes the order, clarify that only happened to me with the 1080ti. If I already know that I do not benchmark if you respect my changes, but there is so little information.

The benchmark is to make those control points, but I should also respect my configuration, I want to give me the result of my configuration. What is the usefulness of a car's Bencmark intensity that, in doing so, fails in some algorithms due to excessive intensity? It has no use.

You say that a process by card is more efficient than a process that includes all the cards to mine. but there are problems with this. It requires MUCH more cpu, and the lack of specialized miners makes the result of HA low.

Example I with the version of Alexis suitable in X17 doing manual, I get 120-125 mhs, an average of 20 mhs per card, and it is a whole process.

If I do it with Trupovt or klaust and from HA, each card only reaches 15-16 mhs at most, although each card has its own process and requires much more CPU, the overall result is much lower than using a more appropriate miner and a process for all cards. That makes 5mhs lost by 6 cards = 30 MHS, I lose a lot of power comparing HA with the only process in the right miner.

The GPU0 card is slower although I use RCP, windows remote desktop, which does not use the gpu. And it does not happen to me when I launch a process with all the miners directly.

I have made modifications to the benchmarking process so that it will use custom intensity settings to help in situations where the default intensity setting may be causing issues on certain GPUs. I'm in the process of testing these changes now. Unfortunately, the testing is taking a little longer than anticipated because certain algorithms were causing other problems when benchmarked individually rather than as part of the miner's default benchmark routine. However, I still plan on releasing 1.8.1 later today - but it may be tomorrow for you considering the difference in time zones.

CPU usage depends greatly on the type of CPU that you are using. However, on contemporary CPUs, including budget Ryzen 5s, each miner process uses only .5% of the CPU. All my mining rigs are running CPU-intensive software such as Folding@Home while mining and not incurring any performance penalties from running each GPU in its own process.  Even on a system with eight cards, the combined CPU usage of all those miners should be less than 10% of the system total. It may be higher on older CPUs and admittedly the RAM usage is higher using separate miner processes than a single process. However, that is part of the trade-off of being able to run the most profitable algorithm for each device (which is important in systems that use different types of GPUS) and increased fault-tolerance. Towards the end of your video you show how that one GPU couldn't benchmark but the other GPUs were mining. That would be impossible to do if all the cards shared the same miner process.

I have done tests of certain miners, such as Tpruvot that show an increase in hash rate during actual mining - not benchmarking - for certain algorithms when running in separate processes. For example, even on a system with only two cards, there is an increase of 1 MH/s per card in Lyra2v2 when each GPU is run in its own miner process compared to when they are mining the same pool in a single process.  However, this depends on the algorithm as similar testing showed only a slight increase in Neoscrypt performance.

As for your GPU0 issue, even though you are using RDP, Windows is still using the local machine's graphics card to render the desktop before sending the image to the remote connection as described here: https://msdn.microsoft.com/en-us/library/aa383015(v=vs.85).aspx. In fact, in terms of mining performance, using RDP may be worse than if you had a monitor connected directly to the machine because Microsoft is using its own RDP display driver - which is probably not tuned for performance - and not the NVIDIA device driver. This decrease may not be as evident when you are running all the cards in a single process due to the way the mining software calculates averages for each card.

In regards to Alexis and other miners, I will point out that Hash Auger only uses the mining software's accepted hash rate and not the total hash rate for more accurate pricing estimates.  More often than not, the total hash rate is at least 10% higher than the accepted hash rate because it includes the hash rate of all the low-difficulty jobs that were run when the miner and pool began coordinating work. You can see the total hash rate in the miner output window, but Hash Auger only displays the accepted rate and then uses that rate to revise benchmarks.

My concern with Alexis and other older variants of CCMiner is that they have not been updated in a long time and may have comptability issues with newer versions of the NVIDIA device driver.  Early versions of Hash Auger included the Nanashi miner which was slightly faster in some algorithms than Tpruvot.  However, it caused system freezes for users that had more than a few GPUs in their systems. While Alexis may work fine on your system, as a developer, I have to maintain reliability and stability for the entire user base. Often, that means not including miners that are no longer maintained or that some significant stability issues.

[HashAuger]

The freezing does not occur if Trupovt produces it since it leaves the BLACK screen and I have to restart it.

I only know that it only happens with the 1080ti, and seeing the log, I get the impression that the auto intensity Benchmark in some cases puts it so high, that I freeze the computer.

You know how peculiar are the 1080ti, they are very powerful but very susceptible to being frozen or even restarting the machine as you force a little more than necessary. That's not a good idea Auto intensity in Benchmark or that is lower in 1080ti to avoid just what happens to me.

I'm sorry to have to say it but I'm going back to the time temporarily until this project matures. And I really like your project in addition to a good interface, but the interface is not everything if the rest is not up to par.

Since it has added some miners with no information output to the screen, add Alexis and some more specialized, there are many special CCminer for certain ones. Ccminer asaltadorminer is only for lyra2vz, there is also version for HSX and XVG, there is special version for X16r that works much better than the neverminer etc ...

Since this is a program of auto change to BTC, it does not make sense that it yields less than if I do it manually. I know that such a program is always normal that it does not perform as much as a specialized one, but lose 30 mhs by mining X17, comparing its HA against the ALEXIS with a single process for all the cards. The difference is much, it's like having 1.2 less power cards. It is not the same to overcome the 120 mhs that almost do not reach 100mhs with the same machine and cards.

I've addressed your concerns about Alexis and the auto-intensity benchmarks in my reply to your other post.  I did notice your mention of miners that do not output to the screen.  As I have recently mentioned in this very thread to another user and as described in the FAQ page on my website, Klaust miner does not allow the software to redirect its screen output as it is mining.  This is an incompatibility due to how Klaust miner has been programmed that I have no control over. That is why the panels say "Mining Stats Unavailable" and the miner windows are minimized to the task bar instead of hidden completely.  Once Klaust has finished mining, the software is able to copy its output to the Miners  tab.  This is not ideal, but it is a compromise that allows the use of Klaust miner instead of being limited to only Tpruvot.

Also, the software allows for more than just auto-exchanging to BTC as users can add wallets for any supported coin and mine those coins directly. As I previously stated, I appreciate all your feedback and suggestions. While you have found some important issues involving the use of custom intensity settings and copying benchmarks from one device to another, I believe that some of your other issues are misunderstandings in how the software works. Perhaps that is due to a lack of documentation on my part, but  you can look at the other threads concerning similar software on this site and see that users are having much more significant issues with those programs than the issues you described here.

[HashAuger]

Since it has added some miners with no information output to the screen, add Alexis and some more specialized, there are many special CCminer for certain ones. Ccminer asaltadorminer is only for lyra2vz, there is also version for HSX and XVG, there is special version for X16r that works much better than the neverminer etc ...

As previously mentioned, Klaust is included in the Miner tab, but not in real-time due to how that miner has been programmed. The other miners do output to that tab, but their windows are hidden (not minimized) because the text is redirected to my program and would be blank, black boxes if they were kept visible.

Now that I have released 1.8.1, I will test Alexis to see if it has the same pool-side hash rates as it shows on your rig. I'm sorry, but I have my doubts about a miner that has not been updated in 2 years and is optimized for Cuda 7.5.  As for the x16r miner, are you referring to the Enemy Miner?  If so, I hesitate to use that miner because it's official file repository has been removed and it is impossible to know if some of the versions being distributed have been tampered with.  Different users may have different tolerances for risk, but as the developer of software that others are using, I need to hold the mining software I include in my product to a higher standard.   

[trucobit]

https://www.dropbox.com/s/lzeu0jaj3ygqamx/IMG_2221.MOV?dl=0

To start thanks for the fixes and changes, now if it is easy to configure the cards, just configure the GPU0 when duplicating it takes all the values, everything from the protocols, intensity and other options. THANKS is very useful and saves me time

I've seen another bug, I saw it on other days but I did not give it importance, please watch the video. I give the example with x16r and it does not always happen. If you look at GPU0 I can not configure the OC, even if I check the option, it will not let me put values. I do scrool and I show you the GPU1, it's a 1050 like the other, same brand. On GPU1 if you let me apply the OC, but not on GPU0. And if I copy GPU1 to GPU0, the OC options are not added.

This is what I see, but what I do not see, is the problem of the gpu0 always yield less. I hope you keep this error in mind for the next update, it happens in several protocols and not in all.

Now I'm getting more performance to the program, for me it is important 2 values, 15% for gain changes, and refresh data and consult again every 20 minutes, so at least I know that for 20 minutes at least will be in that protocol avoiding Many changes that is where you do not earn money if there are many.

I hope to get more software failures as you use it more, although right now I only use 2 pools. I do not want to complicate my life anymore, until the basics of the program no longer have so many failures. But you surprise me it's really fast with the updates

[HashAuger]

https://www.dropbox.com/s/lzeu0jaj3ygqamx/IMG_2221.MOV?dl=0

To start thanks for the fixes and changes, now if it is easy to configure the cards, just configure the GPU0 when duplicating it takes all the values, everything from the protocols, intensity and other options. THANKS is very useful and saves me time

I've seen another bug, I saw it on other days but I did not give it importance, please watch the video. I give the example with x16r and it does not always happen. If you look at GPU0 I can not configure the OC, even if I check the option, it will not let me put values. I do scrool and I show you the GPU1, it's a 1050 like the other, same brand. On GPU1 if you let me apply the OC, but not on GPU0. And if I copy GPU1 to GPU0, the OC options are not added.

This is what I see, but what I do not see, is the problem of the gpu0 always yield less. I hope you keep this error in mind for the next update, it happens in several protocols and not in all.

Now I'm getting more performance to the program, for me it is important 2 values, 15% for gain changes, and refresh data and consult again every 20 minutes, so at least I know that for 20 minutes at least will be in that protocol avoiding Many changes that is where you do not earn money if there are many.

I hope to get more software failures as you use it more, although right now I only use 2 pools. I do not want to complicate my life anymore, until the basics of the program no longer have so many failures. But you surprise me it's really fast with the updates

Thank you for the video, it really helps to see what is going on.  I am still testing the issue. Is the Use OC Settings box checked on the Hardware tab for GPU0?  The overclock settings for the individual algorithms should only be disabled when the device's Use OC Settings option is also off. However, there may be a subtle bug in the interface related to copying the benchmarks that is only partially enabling these controls.   You may want to try switching the Use OC Settings box on and off to see if that allows you to enter overclock settings for each algorithm.  There has to be a default overclock setting on the device so the software knows which settings to use if an algorithm doesn't have its own overclock setting. For example, if you only enter overclock settings for x16r, the software will use the device settings for all the other algorithms.

Unfortunately, the software doesn't use any special settings for GPU0. It considers that card to be just like any other graphics card and only uses the settings that the user provides. That is why I was wondering if the Windows RDP graphics driver was affecting the performance of that card.  You said that the performance issue only occurs with certain algorithms, do those algorithms use the same miner (Klaust, Tpruvot, etc) or different miners?

[HashAuger]

I've seen another bug, I saw it on other days but I did not give it importance, please watch the video. I give the example with x16r and it does not always happen. If you look at GPU0 I can not configure the OC, even if I check the option, it will not let me put values. I do scrool and I show you the GPU1, it's a 1050 like the other, same brand. On GPU1 if you let me apply the OC, but not on GPU0. And if I copy GPU1 to GPU0, the OC options are not added.

I have fixed this issue with the algorithm overclock settings not enabling/disabling correctly. This only occurs when you copy the benchmark settings from one device to another and there are certain differences in how the devices have been setup for overclocking.  This is mainly a user interface issue and it can be corrected if you go to the Hardware tab and toggle the Use OC Settings option.  Since there is a quick workaround and the issue isn't severe, I don't want to burden users with another update so soon after 1.8.1.  I will release 1.8.2 - which will include this fix as well as a few other tweaks - tomorrow.

[trucobit]

If there was the option of OC marked on that card in the other tab, I also let me change other OCs of other algorithms in the same card, but not in that one.

It is a mistake that comes out sometimes and I have not given importance before, but since you are debugging the interface and every time everything is much simpler and faster, because I already sent you what I find.

Well if you fixed it for 1.8.2, it will be a simple error. Right now I'm mining a coin directly, but on the weekend I'll try it again in the small rig, my idea is to gradually set it up in all the rigs once it's all a little better.

I ask you to please reconsider the option of being able to save the configuration in a zip to be able to quickly restore after reinstalling windows or any other thing that happens to me or any user. As you can see, I spend time optimizing each protocol one by one according to the rig, and for that I would like to be able to save the configuration of each rig in my dropbox.

Implementing with time Alexis would be a great advance.

Simply to thank him for putting up with my criticisms and faults that I sent him, is already a good product and it will be even better with the passage of time.

I also encourage any user who finds faults to be communicated to the programmer, is the best favor you can do.

[trucobit]

Since it has added some miners with no information output to the screen, add Alexis and some more specialized, there are many special CCminer for certain ones. Ccminer asaltadorminer is only for lyra2vz, there is also version for HSX and XVG, there is special version for X16r that works much better than the neverminer etc ...

As previously mentioned, Klaust is included in the Miner tab, but not in real-time due to how that miner has been programmed. The other miners do output to that tab, but their windows are hidden (not minimized) because the text is redirected to my program and would be blank, black boxes if they were kept visible.

Now that I have released 1.8.1, I will test Alexis to see if it has the same pool-side hash rates as it shows on your rig. I'm sorry, but I have my doubts about a miner that has not been updated in 2 years and is optimized for Cuda 7.5.  As for the x16r miner, are you referring to the Enemy Miner?  If so, I hesitate to use that miner because it's official file repository has been removed and it is impossible to know if some of the versions being distributed have been tampered with.  Different users may have different tolerances for risk, but as the developer of software that others are using, I need to hold the mining software I include in my product to a higher standard.   

If it is true that the original alexis has not been updated for a long time, but only some protocols make them better, and it does not matter if you ask for cuda 7.5 I use it with the cuda 9.1 without problem. There are also several alexis fork optimized for a protocol, basically they remove all the remaining code and leave only the protocol that they want to enhance.

I know that the part of integrating the miners is a compromise between hash / stability, so I do an independent optimization for each protocol, to avoid those failures.

But it is also true that for some protocols I currently get better results by mining directly with the right miner and all in one process. The example that I put of X17 is real, I lose 30 mhs using its software and it is faster the Alexis for HXS and X17 that exists as a fork. When a single card gives 20 mhs, losing 30 mhs is losing the power of more than one card. And the optimization in HA I make it personalized, and if I force it, it fails more.

I do not want to seem demanding, I leave all my ideas and thoughts, you are free to consider them or not, it is your software.

With the changes of 1.8.1 has gained a LOT in configuration speed, I thank you, for me it has been a relief to configure.

[pizzaslut]

How does one know if the number we see is correct and not because of it being manipulated or something wonky going on? I ask because what I am minin on my 1070 ti is at $3.33; so, it's at a price that could be plausible, but one could never know. Which is why I am starting to really like the idea of allowing is move to the second most profitable coin. Maybe like have a button that lets us do that when prices are mistakenly high for whatever the reason could be. Thank you.

[HashAuger]

How does one know if the number we see is correct and not because of it being manipulated or something wonky going on? I ask because what I am minin on my 1070 ti is at $3.33; so, it's at a price that could be plausible, but one could never know. Which is why I am starting to really like the idea of allowing is move to the second most profitable coin. Maybe like have a button that lets us do that when prices are mistakenly high for whatever the reason could be. Thank you.

You are correct that there a lot of factors that could exaggerate pool prices. That is one reason I included the Price Spike Limit to prevent the software from wasting time mining coins with unrealistically high prices. As you noted, the price in your example is plausible. However, the only way to confirm that the pool's estimate is reasonably accurate is to look at your actual earnings on that pool. Unfortunately, there are a lot of accusations out there concerning various pools and their prices estimates.  Sometimes issues with orphan coins or volatile coin values can look like manipulation and sometimes manipulation does occur.  For example, people always complain about temporary orders on NiceHash that are quickly replaced by low orders once a large number of miners have switched over to an algorithm based on the artificially high price. That is why I  include a variety of pools so that users can try to find ones that they like and trust. I also encourage everyone to research what others are saying about each pool in the Pools forum on this site.

The ability to choose a coin that isn't the most profitable is an interesting idea and I am considering ways to implement it in a reliable, user-friendly way. My concern is that there may be unintended consequences for the user's profitability.  For example, what happens if the second most profitable coin has a value 25% less than the most profitable? Some users would then want to take a chance on the most profitable coin instead and others may not in that situation. Accommodating both types of user would require additional parameters to limit when the feature is used.  While a button that allows users to manually switch to the next profitable coin may avoid a lot of the configuration issues, it would require users to sit and watch their rigs all the time.

I'm currently considering ways to give users more control over the coins that are evaluated for profitability. However, due to the various factors and complexities involved, it is most likely going to be a combination of features instead of one single feature that does everything.  In addition to the Price Spike Limit, currently users can disable pools that you don't like and you can also set price adjustments on the pools that you want to adjust their estimates to better reflect your actual earnings.

[HashAuger]

Since it has added some miners with no information output to the screen, add Alexis and some more specialized, there are many special CCminer for certain ones. Ccminer asaltadorminer is only for lyra2vz, there is also version for HSX and XVG, there is special version for X16r that works much better than the neverminer etc ...

As previously mentioned, Klaust is included in the Miner tab, but not in real-time due to how that miner has been programmed. The other miners do output to that tab, but their windows are hidden (not minimized) because the text is redirected to my program and would be blank, black boxes if they were kept visible.

Now that I have released 1.8.1, I will test Alexis to see if it has the same pool-side hash rates as it shows on your rig. I'm sorry, but I have my doubts about a miner that has not been updated in 2 years and is optimized for Cuda 7.5.  As for the x16r miner, are you referring to the Enemy Miner?  If so, I hesitate to use that miner because it's official file repository has been removed and it is impossible to know if some of the versions being distributed have been tampered with.  Different users may have different tolerances for risk, but as the developer of software that others are using, I need to hold the mining software I include in my product to a higher standard.   

If it is true that the original alexis has not been updated for a long time, but only some protocols make them better, and it does not matter if you ask for cuda 7.5 I use it with the cuda 9.1 without problem. There are also several alexis fork optimized for a protocol, basically they remove all the remaining code and leave only the protocol that they want to enhance.

I know that the part of integrating the miners is a compromise between hash / stability, so I do an independent optimization for each protocol, to avoid those failures.

But it is also true that for some protocols I currently get better results by mining directly with the right miner and all in one process. The example that I put of X17 is real, I lose 30 mhs using its software and it is faster the Alexis for HXS and X17 that exists as a fork. When a single card gives 20 mhs, losing 30 mhs is losing the power of more than one card. And the optimization in HA I make it personalized, and if I force it, it fails more.

I do not want to seem demanding, I leave all my ideas and thoughts, you are free to consider them or not, it is your software.

With the changes of 1.8.1 has gained a LOT in configuration speed, I thank you, for me it has been a relief to configure.

As I said, I am willing to test Alexis miner for stability and to also see if the miner's reported hash rate is similar to what is accepted by the pools. Unfortunately, there are many cases where the local hash rate shown by the mining software is higher than what pools accept. My concern is that an older miner may not be as accurate or as stable as newer miners.  Since Alexis miner does not support many other algorithms that are still profitable to mine with GPUs, I am hesitant to divert my attention to including it when I could work on other feature requests. However, if the increase in x17 hash rate is significantly more than Tpruvot, I am willing to take a look at it. To make sure I am looking at the same version that you are using, can you verify that this is the same miner? https://github.com/alexis78/ccminer

I appreciate your feedback and suggestions. I don't consider your requests to be demanding and I understand that everyone wants to have the highest hash rates possible. However, I do need to evaluate and prioritize each request so that it will benefit the greatest number of users.  A significant improvement to x17 mining performance would help many users, but only if it doesn't have a negative impact on system stability.
As I mentioned before, I have had situations in the past where many users were having problems with miners that were written for older versions of the Nvidia SDK.  I think it is great that you are so dedicated to tuning your graphics cards. However, not all users are as willing as you are to carefully adjust the parameters of each algorithm.   So I need to make sure that if I include Alexis, it would lessen their experience with the software.

[HashAuger]

If it is true that the original alexis has not been updated for a long time, but only some protocols make them better, and it does not matter if you ask for cuda 7.5 I use it with the cuda 9.1 without problem. There are also several alexis fork optimized for a protocol, basically they remove all the remaining code and leave only the protocol that they want to enhance.

I know that the part of integrating the miners is a compromise between hash / stability, so I do an independent optimization for each protocol, to avoid those failures.

But it is also true that for some protocols I currently get better results by mining directly with the right miner and all in one process. The example that I put of X17 is real, I lose 30 mhs using its software and it is faster the Alexis for HXS and X17 that exists as a fork. When a single card gives 20 mhs, losing 30 mhs is losing the power of more than one card. And the optimization in HA I make it personalized, and if I force it, it fails more.

Unfortunately I tried two different versions of Alexis78 on one of my machines using just the command prompt and they both crashed repeatedly with an illegal memory operation within the first minute. I tried running each device separately and all of them together.  I also tried another variant of ccminer miner (the last free release of sp-mod) that supposedly has x17 improvements, but it was slower than Tpruvot. If you could provide a link to where you downloaded Alexis miner, I would appreciate it.  Also, which version of the Nvidia drivers are you using?

[trucobit]

A pity about Alexis, but I hope that over time you will find another more efficient miner in some protocols.

Changing the subject a bit, allowing the second most readable currency is an option as discussed in your day, but it is also making it more undermined in the currency than this, I recommend that you raise the 5 minute price review time that I believe What is this, 30 minutes, so that the miner has time to warm up and give up. What is most lost is to change the protocol every few hours, that must be avoided, as I have 15% of earnings and 25 minutes for the new price monitoring.

One thing that I would like to ask the programmer, is some statistics system, I would like to know in a simple panel, how many satochis I make per day. Now he only tells me the total that is in the pools without charging.

But for me to better evaluate my performance, and when I make changes to see if these changes are effective, I need to know the last 7 days the amount of satochis produced, even if it is not completely accurate and there is a good approximation.

Right now a day goes by and I have to go scoring and watching the program and the pools to try to know the satochis won. I think that for me and anyone this can be very important. Because I can play to remove certain protocols, or change the change for profit or the time of revision and see day by day, which configuration generates me
--------------

More ideas for the programmer to consider.


For example, if I want to mine a currency, say XVG, that only mine if the difficulty is less than X (x would be a variable to be defined by the user) in that way, when it is easy to mine the mino and when it lasts will go to undermine auto exchange. I do not think that is too much difficulty, you just have to check DIFF for the currency that is the same in all pools. When mining a coin, this option does not matter, but when we are in the mode that can be mined for auto exchange and for a particular currency, only do it if the difficulty drops from X (the money would give the same as it fluctuates with the BTC and the $ ç9, in this way the mixed mining of auto exchange + chosen currency, only mine when it is easy, may increase in price but if the difficulty does not decrease, I do not want to undermine it .I hope that the concept is understood and is interesting.

As you have added many new pools and I thank you for that. It would be well an option that I want to mine a coin, for example again XVG, and I choose 8 pools or more, and make 2 or 3 hours in each pool and then tell me which one yields the most XVG. In this the following points influence. Number of miners, pool hash, stratum speed, stratum stability or even how far I am from the pool. But if the system is capable of undermining the same wallet in different pools, and knowing how much it has done, it is already a beginning. Of course it can not be exact because if I choose 8 pools at 2 hours, it is 16 hours and the conditions can change. But at least I can find out which are the worst pools and remove them for that currency

I hope that my ideas and suggestions are of your liking, I treat the best for me, for you and for all in short. I've been working with teams of programmers for years and I'm usually the group's creator. and I firmly believe in your project

[HashAuger]

A pity about Alexis, but I hope that over time you will find another more efficient miner in some protocols.

Changing the subject a bit, allowing the second most readable currency is an option as discussed in your day, but it is also making it more undermined in the currency than this, I recommend that you raise the 5 minute price review time that I believe What is this, 30 minutes, so that the miner has time to warm up and give up. What is most lost is to change the protocol every few hours, that must be avoided, as I have 15% of earnings and 25 minutes for the new price monitoring.

One thing that I would like to ask the programmer, is some statistics system, I would like to know in a simple panel, how many satochis I make per day. Now he only tells me the total that is in the pools without charging.

But for me to better evaluate my performance, and when I make changes to see if these changes are effective, I need to know the last 7 days the amount of satochis produced, even if it is not completely accurate and there is a good approximation.

Right now a day goes by and I have to go scoring and watching the program and the pools to try to know the satochis won. I think that for me and anyone this can be very important. Because I can play to remove certain protocols, or change the change for profit or the time of revision and see day by day, which configuration generates me
--------------

More ideas for the programmer to consider.


For example, if I want to mine a currency, say XVG, that only mine if the difficulty is less than X (x would be a variable to be defined by the user) in that way, when it is easy to mine the mino and when it lasts will go to undermine auto exchange. I do not think that is too much difficulty, you just have to check DIFF for the currency that is the same in all pools. When mining a coin, this option does not matter, but when we are in the mode that can be mined for auto exchange and for a particular currency, only do it if the difficulty drops from X (the money would give the same as it fluctuates with the BTC and the $ ç9, in this way the mixed mining of auto exchange + chosen currency, only mine when it is easy, may increase in price but if the difficulty does not decrease, I do not want to undermine it .I hope that the concept is understood and is interesting.

As you have added many new pools and I thank you for that. It would be well an option that I want to mine a coin, for example again XVG, and I choose 8 pools or more, and make 2 or 3 hours in each pool and then tell me which one yields the most XVG. In this the following points influence. Number of miners, pool hash, stratum speed, stratum stability or even how far I am from the pool. But if the system is capable of undermining the same wallet in different pools, and knowing how much it has done, it is already a beginning. Of course it can not be exact because if I choose 8 pools at 2 hours, it is 16 hours and the conditions can change. But at least I can find out which are the worst pools and remove them for that currency

I hope that my ideas and suggestions are of your liking, I treat the best for me, for you and for all in short. I've been working with teams of programmers for years and I'm usually the group's creator. and I firmly believe in your project

You always have interesting insights and quality feedback, which I sincerely appreciate.  I will continue to look into the various miners available and see if I can incorporate additional ones if they are stable and offer significant benefits.  I did notice that Nevermore miner tends to run x17 a little faster than Tpruvot - not as a big of difference as what you said is possible, but an improvement nonetheless. Based on that, I have enabled more algorithms to run on Nevermore in order to provide more opportunities for improved hash rates. Since the software automatically subtracts the miner's dev fee from the price estimates, it should only use the miner if the hash rate increase is greater than the cost of the fee.

Hash Auger does not have a 5 minute price review.  The default and fastest setting is 10 minutes, but is based completely on the Pool Refresh Rate user setting.  If you set this to 30 minutes, than the software will only compare prices and possibly switch algorithms once every half an hour. The software will only change algorithms for each device if the new estimated earnings are greater than the Minimum Profit Switch percent, another user adjustable setting.  Between the two settings, users have a lot of flexibility over how often the software will switch algorithms.

I understand that revenue estimates are popular, but they are also among the most complained about features because they are often inaccurate.  Consider NiceHash, many users complain that those price estimates are not correct. NiceHash revenues should be the simplest to calculate because the service is paying only for hash rate.  It does not have to wait for coins to mature and then be traded at values that are often different than what was estimated when the coins were mined. Trying to calculate various revenue projections across different types of pools adds variables that can make such price calculations even more inaccurate. I would rather not show any earning projections than potentially mislead users by showing incorrect estimates.  That being said, I am considering ways to show users a historical record of what was mined so that they can be better compare their mining output to their actual payouts.

I recall that you would like the ability to mine a list of specific coins across all enabled pools.  I am still working on a design for that feature. I also understand that more advanced users such as yourself would like the ability to further customize the algorithm-switching parameters.  All of those ideas are interesting and worth considering.  However, as the sole programmer on this project with only a few hours a day to work on improvements, fix issues and provide support, most new enhancements will be introduced in an iterative manner over several releases rather than one big release that includes them all.

[trucobit]

I do not mean to estimate how much I will win, I mean how many satochis I have mined yesterday and only in autoexchange mode.

If I mine a single currency, it is VERY easy to know how much it gives me, I just have to see the wallet of that currency.

But when I use it in auto exchange with zergpool, zpool, etc ... it's not so easy to know if I'm going well or I'm going bad. I do not know if the change I made in the refreshment of pools and profits produces more or less.

Going underhand in auto exchange blindly is not a good idea. If only mino in Zpool is easy, I just have to see zpool. But if I mino in 5 pools of auto exchange?, It already complicates my life to know if I am fine with the configuration or not.

As I say, it is not an estimate of the future, it is knowing what I have produced yesterday and before yesterday. As you can see I do not mean all the situations, only in the mining mode with pools auto exchange.

I did not know you were the only programmer. Do not worry too much, I'm the one who usually has a lot of ideas and I tend to burden my own web programmers. When your product is better known, I hope you earn a lot of money.

[HashAuger]

I do not mean to estimate how much I will win, I mean how many satochis I have mined yesterday and only in autoexchange mode.

If I mine a single currency, it is VERY easy to know how much it gives me, I just have to see the wallet of that currency.

But when I use it in auto exchange with zergpool, zpool, etc ... it's not so easy to know if I'm going well or I'm going bad. I do not know if the change I made in the refreshment of pools and profits produces more or less.

Going underhand in auto exchange blindly is not a good idea. If only mino in Zpool is easy, I just have to see zpool. But if I mino in 5 pools of auto exchange?, It already complicates my life to know if I am fine with the configuration or not.

As I say, it is not an estimate of the future, it is knowing what I have produced yesterday and before yesterday. As you can see I do not mean all the situations, only in the mining mode with pools auto exchange.

I did not know you were the only programmer. Do not worry too much, I'm the one who usually has a lot of ideas and I tend to burden my own web programmers. When your product is better known, I hope you earn a lot of money.

I do enjoy working on this project, but I don't expect it to earn much money. The dev fee is just some extra motivation to keep me working on it when I should be sleeping. I just mentioned it because I do like a lot of your suggestions, but my schedule does limit how many feature requests I can include in each release. 

I now have a better understanding of your request.  I do want to include more historical information so that users can better evaluate their mining performance when auto-exchanging.  Unfortunately, even that information doesn't fall neatly into calendar days due to the time required for coins to mature and get traded.  For example, Verge typically requires a much higher number of network confirmations before some pools will trade it.  It may be well into the next day or even the following day before the pool pays out for that coin while other coins have quicker pay outs. Depending on how much Verge was mined in relation to other coins with shorter confirmation times, that may distort daily earnings, What also complicates things is that many of the auto-exchange pools have disabled the recent earnings portion of their APIs, so that information is not as easy to access as it could be.

However, I do want to help users better see what their rigs are mining, so I will be including summaries of work data in the future. I expect that information and functionality will evolve over time.

[trucobit]

Hello again, well I write this for two reasons, say goodbye for a while, give you my impressions.

I have tried their software a lot but for now it is insufficient, my time is golden and I can not invest so much time in a software still green.

You have said that you want to make a simple and easy software. It is a mistake, you can never overcome the simplicity of nicehash, which is to install, make bencmark and that's it, besides being more powerful. People compare everything, and everyone that I have recommended the program has told me the same, poor performance and I agree.

It does not matter if you add 1000 functions that we like, that's good, but not enough. You must fight to get the most out of the cards. You can not say that Alexis is unstable when I use it every day in manual and several versions and there are no stability problems, just look for the correct OC for each miner / protocol

I personally believe that there will be no success if you can not overcome the benefits of Nicehash. I can not lose 30% power in for example X17 (I use a version of alexis). 30% less is to lose more than 1 card if we talk in power.

I love the interface, I love to mine to change to BTC and save currency that I like, but I do not like to lose almost 1/3 of power because I do not have the right miners.

You have a very good and simple thing to do, which is the OC for each protocol, you can use any miner as long as those OCs are adjusted correctly and forget self-intensity.

In a month or two, I'll see how the work is going. Luck

[HashAuger]

Hello again, well I write this for two reasons, say goodbye for a while, give you my impressions.

I have tried their software a lot but for now it is insufficient, my time is golden and I can not invest so much time in a software still green.

You have said that you want to make a simple and easy software. It is a mistake, you can never overcome the simplicity of nicehash, which is to install, make bencmark and that's it, besides being more powerful. People compare everything, and everyone that I have recommended the program has told me the same, poor performance and I agree.

It does not matter if you add 1000 functions that we like, that's good, but not enough. You must fight to get the most out of the cards. You can not say that Alexis is unstable when I use it every day in manual and several versions and there are no stability problems, just look for the correct OC for each miner / protocol

I personally believe that there will be no success if you can not overcome the benefits of Nicehash. I can not lose 30% power in for example X17 (I use a version of alexis). 30% less is to lose more than 1 card if we talk in power.

I love the interface, I love to mine to change to BTC and save currency that I like, but I do not like to lose almost 1/3 of power because I do not have the right miners.

You have a very good and simple thing to do, which is the OC for each protocol, you can use any miner as long as those OCs are adjusted correctly and forget self-intensity.

In a month or two, I'll see how the work is going. Luck

As I said before, I encourage users to try other mining software and determine what works best for their needs. I appreciate the time you spent evaluating my software. However, I disagree with a number of your points. First, one can look at the NiceHash subreddit and see the many users who have fundamental problems with the NiceHash software. Most people would agree that the stability and usability problems those people are having with NiceHash are much more servere than the few issues with copying device settings you found in my software. I have already fixed the issues you have found, but users of other products complain that bugs they reported months ago are still not fixed.  Also, earnings on NiceHash are limited to what buyers on its marketplace are willing to pay. Hash Auger allows users to switch between NiceHash and other pools to find the best earnings while still offering more configuration options than many other mining managers. I'm not sure how NiceHash helps users "get the most from their hardware" when it doesn't offer the ability to easily set algorithm-specific overclock settings or intensity values. Finally, Hash Auger includes algorithms such as Phi, x16r and x16s that NiceHash simply doesn’t offer.

While you may not have stability issues with Alexis miner on your rigs, that miner consistently crashes before finding a single x17 result on several of my rigs - most  likely due to its age and the fact that it is optimized for Cuda 7.5.  I have tested it with multiple cards using no overclock and different overclocks and with nothing more than just the miner and the command prompt. When I asked you for more information about the version of the Nvidia device driver you are using and which version of Alexis miner you are using, you ignored my questions. Also, I find it interesting that you keep mentioning that the software includes less miners than you would like but then suggest NiceHash is superior. NiiceHash version 2 includes far fewer miners than NiceHash Legacy and I’m pretty sure Alexis miner isn’t one of them.

Thanks again for all your detailed feedback and suggestions. I wish you the best in all your endeavors.

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