Hash Auger 2.9.7.5 Mining Manager and Switcher for NVIDIA GPUs

[Zirillian]

HA - regarding the update to allow for Pickaxe pool. Can you check to make sure it's working appropriately?  It's telling me I would earn $0.00 mining LUX (phi algo), when I definitely earn quite a lot more than that mining individually on BSOD or algo on other pools.  Something might be wrong with the formula that brings in current estimates or something.

Edit: I should note that I believe I followed the directions in the OP about only turning it on when it's disabled and a wallet is ready for it. I might have API'd it out though as it now admits it can't fetch the rates from Pickaxe.  How do I go about fixing this you think?

[1713418866]

1713418866

[1713418866]

1713418866

[1713418866]

1713418866

[1713418866]

1713418866

[1713418866]

1713418866

[1713418866]

1713418866

[pizzaslut]

Which is more accurate  actual price or estimated price? I don't think either are for the cpu algo I am mining(m7m on hashrefinery other m7m pools are lower) at $1.89. It's like at that plausible price tso not sure.

[kadal88]

Thank you. Will be waiting for the next update to use your app as I want to try the new cryptonight...

[HashAuger]

HA - regarding the update to allow for Pickaxe pool. Can you check to make sure it's working appropriately?  It's telling me I would earn $0.00 mining LUX (phi algo), when I definitely earn quite a lot more than that mining individually on BSOD or algo on other pools.  Something might be wrong with the formula that brings in current estimates or something.

Edit: I should note that I believe I followed the directions in the OP about only turning it on when it's disabled and a wallet is ready for it. I might have API'd it out though as it now admits it can't fetch the rates from Pickaxe.  How do I go about fixing this you think?

Unfortunately, there is not much one can do once the pool issues the temporary block except wait until it expires. Unfortunately, there is nothing on the pool website that even mentions the API ban, let alone describes when it will be lifted. I do know that the ban is lifted eventually as I can get pricing information from the pool now.  If I can find some contact info for the pool admin, I will try to see if they can relax their restrictions a bit.

Also, it looks like the pool only provides price estimates for the current coin mined by each algorithm.  Right now I am getting an accurate price for Lux, but if you look on the pool website, prices for two other Phi-based coins (Folm and Seraph) are zero even though they both have miners.  I bet when you tried it earlier, the Phi port was mining a different coin and so the price estimate for Lux was zero. This is unlike other pools that provide price estimates for all the coins regardless of which one is the port's current coin. Unfortunately, this means that the software occasionally won't be able to calculate a price for coins on the pool due to the missing data. I'll see if I can reach out to the pool admin and talk to them about these issues.

[HashAuger]

Which is more accurate  actual price or estimated price? I don't think either are for the cpu algo I am mining(m7m on hashrefinery other m7m pools are lower) at $1.89. It's like at that plausible price tso not sure.

Looking at the 24 hour chart for m7m on HashRefinery, there were some insane price spikes with that algorithm earlier today - almost 2000 mbtc/Mh/day, so the price you saw was coming from the pool based on its estimates.  It looks like there are more orphan Magi coins than real coins today on that pool, which is probably why the prices are skewed. The Price Spike Limit feature will also work for the CPU if you want to avoid having the CPU mine coins experiencing these kinds of pool issues.

To answer your question, the actual prices reflect the historic prices from the previous day while the estimates are based on more recent data. If the coin's price has been steady in the past day, the actual price should be more accurate.  However, if the price of the coin has risen or fallen significantly in the past 24 hours, the estimated price may be more accurate.

[HashAuger]

Can you please help me understand how to decipher what coin is more profitable than any other?  I hope my question is clear.   I read comments where it is discussed that one coin or another is more profitable at a given moment.  What is the indicator or information that tells me this?   I feel that what I am asking will be obvious once explained so I apologize in advance if I should know this. 1.8 adds use mine coin parameter and unless I know what coin I am going after it is of little use.
I read the FAQ and my eyes glossed over about halfway through.  you have done an outstanding job in the past explaining  in detail all of my questions.  Thank you.

Probably best to just pick a pool that autoexchanges to BTC (Blazepool is my suggestion) and let that run for a while until you get the hang of this, vs. worrying about mining individual coins per the 1.8 update. All it does is allow you to mine individual coins (e.g. RVN) on autoexchange pools like Zergpool...but you can already do this on other pools (e.g. Pickaxe, BSOD), so that functionality was already there.  More trouble than it is typically worth as you then have to set up a wallet to mine that individual coin to, then transfer it to an exchange to sell it, etc.  If you're just learning, just do an autoswitch pool and let it run.

Apologies for the miscommunication regarding Zergpool and the MC parameter. Zergpool is the only pool that supports it, so Hash Auger 1.8 still won't let you mine individual coins on other auto-exchange pools like Blazepool or HashRefinery because those pools don't provide a way to specify coins. While this feature is conceptually similar to how the software works with pools that don't auto-exchange, like BSoD and Yiimp.eu, a key difference is that it still works with an auto-exchange wallet.  Basically, with the MC parameter Zergpool is now more like MiningPoolHub than anything else. You can mine on the auto-switch ports, the individual coins or both while still enjoying the benefits of auto-exchanging to BTC/LTC and automatic coin switching.

For example, sometimes Lux will have a better price estimate than the Phi algorithm port. Hash Auger will pick which option has the better estimate and use the MC parameter accordingly. However, you wouldn't need a Lux wallet to mine Lux on Zergpool with the MC parameter as the pool will still auto-exchange your earnings to BTC or LTC.  As an aside you could assign a Lux wallet to Zergpool and Hash Auger will then use that wallet instead of your auto-exchange wallet when mining Lux on Zergpool (just like the software does with pools that don't auto-exchange). Adding wallets for coins that Zergpool doesn't currently auto-trade (such as ElliotCoin) will also allow you to mine those coins using the new MC parameter.

So to answer your question JBeck, you don't have to worry about calculating the most profitable coin on Zergpool as the software will do that for you. Sometimes it will pick the pool's auto-switch coin and sometimes it will pick an individual coin. However, the pool will still auto-exchange your earnings to your LTC wallet.  You just get the flexibility of comparing prices across 180+ coins versus just the couple dozen auto-switch ports. I know you have been disappointed in Zergpool's payouts in the past, but you may want to try again and enable the MC Parameter on that pool to see if your earnings on that pool improve.  I'm currently doing a little experiment with Zergpool myself to see what my earnings are like if I disable the auto-switch ports and just use the MC Parameter based on the theory that too many miners are following (and increasing the difficulty) on the traditional ports.

I agree with Zirillian that anyone just starting out should stick with the auto-exchange pools rather than trying to mine individual coins on the pools that don't auto-exchange because the risk/reward ratio is much higher when you don't auto-exchange.  

[jbeck]

Again Very clear in your explanation about MC Parameter. I appreciate your your always clear and detailed reply.  But what I was looking for was a bit of a better understanding on how to look at the stats as presented to learn what coin is worth over another coin.  For example I see a coin listed with a higher hash rate with an estimated price lower than a coin with a lower hash rate .  I see estimates of current and actual and 24 hr actual and dont know what that means.   I am sorry that I dont quit understand . I dont like not knowing even if I will most likely will leave the selection up to the program. 

[trucobit]

Another mistake, or at least for me it is. You already fixed that when copying from one GPU to another, the intensity will be copied. But now what is missing, is that if I, deselecting protocols, this selection is not passed to the following cards.

Example in GPU0 deactivated scrypt, and when copying GPU0 to GPU1, it is not deselected, it is a nuisance.

[trucobit]

https://image.ibb.co/f8Gswn/Captura_de_pantalla_2018_04_16_a_las_22_15_25.png
I still have this fault. I uncheck self intensity and saved it. I close the program and restart it again, and Auto Current selected again.

I hope you now understand the problem. As I configure the intensity for each protocol, I do not use the auto intensity at all. As soon as I start the program, I have to deactivate that option for each card.

I apologize that I overlooked this particular issue. The device intensity is separate from the algorithm intensities and I didn't test it when I made the recent fixes.  I will take a look at why the custom value is not being loaded correctly from saved data.

EDIT: I just tested the software and compared it with your screen image. 0 is the level for the auto intensity setting. If you do not change the value from 0, the software will re-select the Auto Intensity setting because another value wasn't given.  However, yf you change the intensity value to anything other than zero, the Auto Intensity box will stay unchecked.  For example, if I set the intensity slider to 80 instead of zero and then save the device, the correct value loads when I restart the software. I should change the word Intensity to Utilization on the devices to better indicate how this setting is used by the software. END EDIT

I should mention that the device intensity works a little differently than the overclock settings.  You can leave the device intensity as auto and the software will still use the custom intensity levels that you set for each algorithm.  If you don't enter a custom intensity level for an algorithm, the software will use the miner's default intensity level for that algorithm instead. For example, I leave my device intensity settings to Auto, but then assign custom intensities to x16r, Raven and some other algorithms.

The device intensity is really intended for users who don't want a particular device to run at full utilization while mining. For example, someone who uses their computer while mining may want a lower intensity on their primary graphics card to improve display performance.  If you are using a device for mining only, it is probably best to leave the device setting to auto and then adjust specific algorithms for better performance. However, I do need to fix the issue with the custom value not saving correctly regardless.  Thanks.

Thanks for the information, then if I put a number of intensity the automatic is ignored. Thanks for detailing, then for me it is not a problem.

[HashAuger]

Another mistake, or at least for me it is. You already fixed that when copying from one GPU to another, the intensity will be copied. But now what is missing, is that if I, deselecting protocols, this selection is not passed to the following cards.

Example in GPU0 deactivated scrypt, and when copying GPU0 to GPU1, it is not deselected, it is a nuisance.

Yes, I did notice that issue while working on the ability to copy a single GPU’s settings to all other GPUs. It has already been fixed in 1.8.1 - which should be released tomorrow. Thanks for letting me know.

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

[HashAuger]

Again Very clear in your explanation about MC Parameter. I appreciate your your always clear and detailed reply.  But what I was looking for was a bit of a better understanding on how to look at the stats as presented to learn what coin is worth over another coin.  For example I see a coin listed with a higher hash rate with an estimated price lower than a coin with a lower hash rate .  I see estimates of current and actual and 24 hr actual and dont know what that means.   I am sorry that I dont quit understand . I dont like not knowing even if I will most likely will leave the selection up to the program.  

It is always a good idea to further one’s knowledge and understanding. Software can perform these calculations faster than most people, but it always helps to understand what is being calculated and why. Hash rate is only one factor in the pricing equation and most algortihms have vastly different hash rates on the same hardware. For example, on a 1080 Skein usually has a rate over 650 mh/s while Phi has a hash rate around 24 mh/s and Equihash does less than 600 H/s.  So you really cannot compare prices based on hash rate alone.

Each coin that can be traded has an underlying value based on the price people are willing to pay for it on an exchange. The coin’s value is a big reason why prices fluctuate even when your hash rate stays the same. If the price of the coin increases, you should get better earnings for the same hash rate as long as the difficulty stays the same.

So the other big factors in coin prices are difficulty and hash rate. The higher the hash rate, the greater number of chances that a new block will be found. Coins that can be traded are the reward for finding a block. However, nearly all algortihms limit how many new blocks can found in a specific period of time. If the current hash rate is finding blocks at a rate higher than this limit, the algorithm increases the difficulty of finding a new block so that it falls within the limit. Since it will take longer to get new coins at this higher difficulty, earnings will decrease even if the coin value and hash rate stay the same.

Putting all that together, you’ll see a lot of pools estimating prices as mBTC/MH/Day.  That is the current estimate of how much Bitcoin you would get per mega hash if you mined that coin for an entire day. Some pools will measure prices of some algorithms in different units like GH or Kh, but the concept is the same. It is important to note that this price will change if the underlying coin value changes, the pool’s hash rate changes or the difficulty changes.

The difference between the estimated values and the actual values is that the estimates are looking at current statistics while the actual values are based on recent historical data. Both have their advantages and disadvantages. The historical (actual) data can be more accurate if all the factors such as price, hash rate and difficulty have been stable recently. The estimated values are more current, but are more prone to volatility that may distort the prices. For example, if a coin temporarily shoots up in value, the estimates will be higher, but there is no guarantee that the value of the coin won’t drop back to historical levels by the time the pool has exchanged it.

[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 see the usefulness of that feature. Let me take a little time to think through some possible implementations and then we can discuss this further.

[HashAuger]

https://image.ibb.co/f8Gswn/Captura_de_pantalla_2018_04_16_a_las_22_15_25.png
I still have this fault. I uncheck self intensity and saved it. I close the program and restart it again, and Auto Current selected again.

I hope you now understand the problem. As I configure the intensity for each protocol, I do not use the auto intensity at all. As soon as I start the program, I have to deactivate that option for each card.

I apologize that I overlooked this particular issue. The device intensity is separate from the algorithm intensities and I didn't test it when I made the recent fixes.  I will take a look at why the custom value is not being loaded correctly from saved data.

EDIT: I just tested the software and compared it with your screen image. 0 is the level for the auto intensity setting. If you do not change the value from 0, the software will re-select the Auto Intensity setting because another value wasn't given.  However, yf you change the intensity value to anything other than zero, the Auto Intensity box will stay unchecked.  For example, if I set the intensity slider to 80 instead of zero and then save the device, the correct value loads when I restart the software. I should change the word Intensity to Utilization on the devices to better indicate how this setting is used by the software. END EDIT

I should mention that the device intensity works a little differently than the overclock settings.  You can leave the device intensity as auto and the software will still use the custom intensity levels that you set for each algorithm.  If you don't enter a custom intensity level for an algorithm, the software will use the miner's default intensity level for that algorithm instead. For example, I leave my device intensity settings to Auto, but then assign custom intensities to x16r, Raven and some other algorithms.

The device intensity is really intended for users who don't want a particular device to run at full utilization while mining. For example, someone who uses their computer while mining may want a lower intensity on their primary graphics card to improve display performance.  If you are using a device for mining only, it is probably best to leave the device setting to auto and then adjust specific algorithms for better performance. However, I do need to fix the issue with the custom value not saving correctly regardless.  Thanks.

Thanks for the information, then if I put a number of intensity the automatic is ignored. Thanks for detailing, then for me it is not a problem.

I'm glad that this is no longer a problem.  I did make same changes to the GPU intensity slider in 1.8.1 to clarify how it is used.  First, it is now called Utilization instead of Intensity. Second, the default value is now 100% and I removed the Auto checkbox.  Hopefully these changes will help distinguish this setting from the individual algorithm intensities on the benchmark tab.

[trucobit]

https://image.ibb.co/f8Gswn/Captura_de_pantalla_2018_04_16_a_las_22_15_25.png
I still have this fault. I uncheck self intensity and saved it. I close the program and restart it again, and Auto Current selected again.

I hope you now understand the problem. As I configure the intensity for each protocol, I do not use the auto intensity at all. As soon as I start the program, I have to deactivate that option for each card.

I apologize that I overlooked this particular issue. The device intensity is separate from the algorithm intensities and I didn't test it when I made the recent fixes.  I will take a look at why the custom value is not being loaded correctly from saved data.

EDIT: I just tested the software and compared it with your screen image. 0 is the level for the auto intensity setting. If you do not change the value from 0, the software will re-select the Auto Intensity setting because another value wasn't given.  However, yf you change the intensity value to anything other than zero, the Auto Intensity box will stay unchecked.  For example, if I set the intensity slider to 80 instead of zero and then save the device, the correct value loads when I restart the software. I should change the word Intensity to Utilization on the devices to better indicate how this setting is used by the software. END EDIT

I should mention that the device intensity works a little differently than the overclock settings.  You can leave the device intensity as auto and the software will still use the custom intensity levels that you set for each algorithm.  If you don't enter a custom intensity level for an algorithm, the software will use the miner's default intensity level for that algorithm instead. For example, I leave my device intensity settings to Auto, but then assign custom intensities to x16r, Raven and some other algorithms.

The device intensity is really intended for users who don't want a particular device to run at full utilization while mining. For example, someone who uses their computer while mining may want a lower intensity on their primary graphics card to improve display performance.  If you are using a device for mining only, it is probably best to leave the device setting to auto and then adjust specific algorithms for better performance. However, I do need to fix the issue with the custom value not saving correctly regardless.  Thanks.

I'm sorry but it does not work as you say. I have all the pre-established protocols in 20 to start optimizing. I have put intensity 20 into each of the protocols.

Now I leave you a capture where you will see that being marked "auto intensity" ignores my pre-defined intensity of the protocol and the program assigns an intensity to the solo. It can also be deactivated because when restarting it is activated again, it forces me every time you start to always have to uncheck those boxes.

His explanation was fine, but his programming ignores him.

The capture is in Benchmarking, and the system ignores my intensity and puts its own. There is still a lot of work to correct flaws and usability.



The benchmark with the 1080ti, although I have them all in intensity 20 manually, makes me restart constantly. Somewhere the Benchmark beats my machine and freezes.

If I'm going to invest time in optimizing, I do not understand why when benchmarking it does it with autointensity. Please correct this fault.

[trucobit]

https://www.dropbox.com/s/li2a4uz1nua7u1h/IMG_2219.MOV?dl=0

Please see the first part of the video, you will see that the GPU0 took away the auto intensity but in benchmark it does not take it into account.

It has been agreed that my rig be frozen 8 times, because the benmark never ends because it freezes.

Another weird error that I have seen, is that always the gpu0 is the card that performs less, I have checked it in 4 different rigs from 1060 to 1080ti, and always the gpu0 is the card that hash less hash.

Please correct the benchmark and respect my intensity settings, I'll do it one by one without going through benmark so it does not freeze anymore.

[HashAuger]

https://image.ibb.co/f8Gswn/Captura_de_pantalla_2018_04_16_a_las_22_15_25.png
I still have this fault. I uncheck self intensity and saved it. I close the program and restart it again, and Auto Current selected again.

I hope you now understand the problem. As I configure the intensity for each protocol, I do not use the auto intensity at all. As soon as I start the program, I have to deactivate that option for each card.

I apologize that I overlooked this particular issue. The device intensity is separate from the algorithm intensities and I didn't test it when I made the recent fixes.  I will take a look at why the custom value is not being loaded correctly from saved data.

EDIT: I just tested the software and compared it with your screen image. 0 is the level for the auto intensity setting. If you do not change the value from 0, the software will re-select the Auto Intensity setting because another value wasn't given.  However, yf you change the intensity value to anything other than zero, the Auto Intensity box will stay unchecked.  For example, if I set the intensity slider to 80 instead of zero and then save the device, the correct value loads when I restart the software. I should change the word Intensity to Utilization on the devices to better indicate how this setting is used by the software. END EDIT

I should mention that the device intensity works a little differently than the overclock settings.  You can leave the device intensity as auto and the software will still use the custom intensity levels that you set for each algorithm.  If you don't enter a custom intensity level for an algorithm, the software will use the miner's default intensity level for that algorithm instead. For example, I leave my device intensity settings to Auto, but then assign custom intensities to x16r, Raven and some other algorithms.

The device intensity is really intended for users who don't want a particular device to run at full utilization while mining. For example, someone who uses their computer while mining may want a lower intensity on their primary graphics card to improve display performance.  If you are using a device for mining only, it is probably best to leave the device setting to auto and then adjust specific algorithms for better performance. However, I do need to fix the issue with the custom value not saving correctly regardless.  Thanks.

I'm sorry but it does not work as you say. I have all the pre-established protocols in 20 to start optimizing. I have put intensity 20 into each of the protocols.

Now I leave you a capture where you will see that being marked "auto intensity" ignores my pre-defined intensity of the protocol and the program assigns an intensity to the solo. It can also be deactivated because when restarting it is activated again, it forces me every time you start to always have to uncheck those boxes.

His explanation was fine, but his programming ignores him.

The capture is in Benchmarking, and the system ignores my intensity and puts its own. There is still a lot of work to correct flaws and usability.

https://preview.ibb.co/if7Ee7/Captura_de_pantalla_2018_04_18_a_las_3_52_52.png

The benchmark with the 1080ti, although I have them all in intensity 20 manually, makes me restart constantly. Somewhere the Benchmark beats my machine and freezes.

If I'm going to invest time in optimizing, I do not understand why when benchmarking it does it with autointensity. Please correct this fault.

You are correct, benchmarking is always done with the miner's default intensity settings and not the custom intensity settings.  Your custom intensity settings only run when the software is mining - not benchmarking. This is because the software uses each mining program's built-in benchmark feature instead of running each algorithm for an extended period of time.  It is a compromise between benchmarking precision and the time required to benchmark all the algorithms.  Most users prefer to start mining sooner rather than later.  If you use the software's Update Benchmarks With Actual Rates feature, the benchmarks will be continually revised with more accurate hash rates, including the effects of your custom intensity ratings. That should replace a drawn-out benchmarking procedure.

If GPU0 is the video card that your monitor is connected to, then a decrease in hash rate is to be expected because that video card is also responsible for refreshing your desktop in addition to mining. That is not unique to my software and there is nothing in the software that treats GPU0 any differently than any other graphics card.

Looking at your video, I don't see anything that indicates your system is freezing as you are still using it and mining with it.  I do see that Tpruvot seems to fail while benchmarking one of your 1080ti cards.  I will take a look to see why the software isn't recognizing that failure and moving on to the next miner.

[trucobit]

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.

[trucobit]

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.

[pizzaslut]

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?