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

Version 1.9.9.5 of Hash Auger adds support for CoolMiner.  While this miner has been very stable during testing, it does require an upgrade to the newer Nvidia drivers that some users have been wary of.  Consequently, CoolMiner is disabled by default in HA until more users have installed the 397/398 graphics card drivers that the miner requires.

Considering that the way Delos miner's collects its dev fee is incompatible with algorithm-switching software in general and the developers have decided to not respond to these concerns, I have removed support for Delos miner from the software.  Previously, Delos had been disabled by default due to this issue.

Changes in CryptoDredge 4.1 made it possible for me to avoid using log files with the miner altogether, so this should no longer be a problem with Hash Auger 1.9.9.3

Sorry that the error message in your screen capture is a little vague (I will reword it for the next release), but the file that the message is referring to is the log file that Cryptodredge writes to disk once it is done mining.  Since CryptoDredge does not currently have an API, the only way to get hash rate information from the miner is from that log file.  Unfortunately, sometimes CryptoDredge does not finish writing this file to disk or releasing the file lock so that it can be read before Hash Auger stops waiting for it.  This can be due to a high system utilization, a temporary slowdown in disk I/O or an issue with CryptoDredge shutting down before it finished writing the log file.  I have run CryptoDredge 4.1 on all my rigs and it seems a lot more stable than earlier versions. If you have not upgraded to Hash Auger 1.9.9.2 yet, the latest release may help prevent these log file issues from occurring.

Based on your screencapture, it looks like you were able to benchmark CryptoDredge, so Hash Auger was able to both run the miner and read its log file then.  Also, HA attempts to read the log file after mining, so you are still able to mine with CryptoDredge.  The only thing that the log file error affects is the ability of the software to calculate the difference between CryptoDredge's benchmark hash rate and its average mining hash rate.  In this particular case, HA would have skipped making that calculation because the log file could not be read. However, since this is most likely an intermittent issue, those calculations will still occur when the log file is available.

If you are running Hash Auger 1.9.9.2 and this issue is occurring every time CryptoDredge is being used, you may want to try mining CryptoDredge with just one or two GPUs and see if the log file error still occurs.  If the log file error does not occur when using only one or two GPUs, then the issue is most likely caused by slow disk I/O.  I can then increase the maximum time out in the software so that it will wait a little longer for the file.

Hi dev, I can't use cryptodredge




I was so happy to use it. What's the problem?

All Hash Auger users mining on Zergpool should note that they do not have to update a recent copy (1.9.8 or later) of the software despite the pool's recent pricing changes to Nist5 and x13.  I have tested the software with that pool using both the auto-switch ports and the MC Parameter option and the new mbtc_mh_factor is working as it should, automatically converting the mbtc value using the appropriate unit.

When Hash Auger isn't running, replace the .xml files in the main directory with the contents of the backup file. When you restart the software, Hash Auger will load the restored files automatically.

How do you suggest we restore backup?

Thank you for trying the software.  With all the upcoming forks and changes to Equihash, EWBF is already on my list of new features to add to the software. If you have any questions regarding the software or the configuration settings, please don't hesitate to ask either here or on the Discord channel. 

This looks great.

I'm testing it with one of my 8 1080ti rig. So far looking amazing. I will wait and see in 24 hours.
So much to learn I wish if you can make video tutorials ..

Its will be great if you can add EWBF miner for equahash. For my 1080ti rigs dstm with there 2% fee make less than EWBF.
If all go well, I will use it for all my rigs (40 1080 tis)

Great. Thank you.

Version 1.9.9 includes some code changes to improve performance on rigs that have many GPUs and lower-power CPUs. Thanks to all the users and beta testers on the Discord channel who helped provide feedback for this release.

Many thanks to all the users who have joined the Discord channel.  There have been some interesting discussions lately about cryptomining in general. Unfortunately, it means a lot of the conversations have also moved off this thread. Recently a user has tried upgrading to the latest Nvidia drivers (398.11) and has gotten some incompatibility issues with some of the mining software - particularly those older versions of ccminer compiled for Cuda SDK 8 (alexis, ccminer-phi, palginmod, xevan).  If you use any of those miners on Windows, you will probably want to think twice about upgrading from the 391.35 display drivers.

The mbtc_mh_factor is a behind-the-scenes changes that will make everyone's lives easier.  It is a new piece of data that allows users of the Yiimp API (algorithm switching software like my own, for example), to automatically include changes in how algorithms are priced by each Yiimp pool.  In your quote, I mentioned that Hash Refinery recently changed pricing for several algorithms. Specifically, they changed the pricing from mbtc/MH/day to mbtc/GH/day. 

If you are not familiar with the Yiimp API, then it would be helpful to know that the API returns the price of each algorithm in mBTC.  However, up until the addition of the mbtc_mh_factor, the API did not include if this price was per megahash, gigahash, etc.  API users had to build lists of how each pool prices each algorithm. If a pool changed how an algorithm was priced, users of the API had to update their lists -  which often meant updating their software to include the changes. Calculations based on the old price unit would be wrong and more often than not would make the algorithm appear to be more profitable than it actually was until it was adjusted with the new unit. This could cause problems if pools changed price units without any advance notice.

Fortunately, the new mbtc_mh_factor prevents this kind of issue because the API now says which unit the mbtc price is based on. Predefined lists are no longer required and if the pool changes the price unit from megahash to gigahash, any calculation using the mbtc_mh_factor will still be correct as the API will adjust the price factor automatically.

What is mbtc factor changes on yiimp? Can you explain me pls?

Adding cryptodredge you confirmed you are the best dev and you work very good listening your miners... I'll back to use hashauger again!! Thanks!!!

Just a friendly reminder to users of Hash Auger that are mining on HashRefinery.  On June 10th, HashRefinery is changing how price estimates are calculated for a few algorithms.  These algorithms (x11, x13, Scrypt, Quark and Qubit) are disabled by default in Hash Auger since they are not usually profitable to mine with GPUs. However, if you have any of these algorithms enabled for this pool and have not yet upgraded to Hash Auger 1.9.7, you should do so before these changes take effect.  With Hash Auger now supporting the new mbtc_factor Yiimp API, the software will respond to price factor changes such as these automatically in the future on pools that provide this API information.

Algorithms that have been disabled for all devices now appear unchecked on the pool algorithm lists in version 1.9.7. 

Thanks for your feedback, Dirk.  The pool's Algorithm checkboxes should be read-only when that algorithm is already disabled for every device. This is because the software will not attempt to mine that algorithm regardless of the pool setting.  I just tested this situation on one of my systems and I could disable Skein for AHashPool when Skein was still enabled on my GPUs.  As soon as I disabled that algorithm for all the GPUs, I could no longer disable it for the pool as the checkbox was readonly. If you have not disabled Skein on your GPUs, please let me know and I will take a look to see if there may be some other issue involved.

As a side note, I recognize that the pool's read-only algorithm checkboxes should be unchecked to better reflect that these algorithms are already disabled. That change will be in the next version of the software.

Is there a reason why you cannot disable some of the Algorithms in the pools like in Ahashpool skein is on and you cannot disable it?