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

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.

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.

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.

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.

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.

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.

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.

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. 

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.  

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.

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.

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

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.

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?

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.

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.

You can always backup the .xml files that are in the AppData\Local\CongeriesSoftware\HashAuger before an upgrade.  I do test the upgrades to make sure that they don't replace or delete the config files before I release them.  I never understood why some other software products make you re-benchmark everything every time they release an upgrade.  One of Hash Auger's features is that the configuration files and device benchmarks persist between updates, so most upgrades should only take a couple minutes to download and install and shouldn't require any config changes unless there is a new feature you want to try. However, I cannot rule out some random event that corrupts a data file, so it is a good idea to occasionally backup the .xml files.

Thank you for understanding my position about the data export suggestion.  I recognize that some users would benefit from being able to export configuration files to other machines. I am not opposed to implementing such a feature in the future. However, it will require more time to implement than just simply creating an archive file due to the device assignment issues. In the meantime, I am still planning to implement functionality to copy a single device's settings to all other devices on the same machine. Once that feature is in place, it would reduce the amount of time needed to setup additional systems.

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.

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.



please see the video and there will be no translation problems.

https://www.dropbox.com/s/fljm9heaw7ql3jk/WhatsApp%20Video%202018-04-16%20at%2022.28.12.mp4?dl=0

I understand your position and the complication. I know it can cause some conflict, but it is always quicker to copy a configuration from one rig to another and then review the errors, than try to configure ALL from 0.

I am supporting myself in the case that would be easier if they have the same cards.

In any case, being able to save and save the configuration of 1 rig and be able to save it is already an advance.

Now there is a new version. Before updating, I can save the settings and in case it is deleted, I can recover it from the copy.

I can not be doing optimizations every few days in the same rigs. That's why I only use it in 1 for now and at times.

Thanks for the new improvements when it comes to copying the settings between devices and the power to mine loose coins in Zergpool, I think it's wonderful.