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

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

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?

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.

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.

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.

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.

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.

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.

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?

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

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.   

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.

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.

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.

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

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.

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.

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.