In the auto exchange pool configuration, there is the option to exclude protocols. But again, it's one on one. It would be good options to copy from another pool, or even copy to all pools that selection of protocols.

In the auto exchange pool configuration, there is the option to exclude protocols. But again, it's one on one. It would be good options to copy from another pool, or even copy to all pools that selection of protocols.

You may want to have all the same, but in some pool I can make a different change, but it would be punctual. It should be easier to copy that configuration to other pools easily, as you did in the graphics card section

I liked the update, I'm testing it in the small rig only in x17, Alexis makes a difference.

I did not know that before in the autochange pools, the disabled protocols worked equally. It is good to know that now it fulfills that condition.

I still think there are no miners, but I see that their intention is to add them more and more.

I'm going to tell you something that no software does and what they should do, a super optimization that would take many hours, but that would give the best performance for each protocol and card, something that you promise in this program.

You make the typical benchmark pass to know the HASH you have in each protocol. But what do you do to maximize that? . The process of manual optimization is very heavy, so it will be good for people with experience to save time and without experience. It should be optional. The default values ​​or what works for others may not be the best for me or my brand of card.

They should be two different steps, and should be launched separately on two buttons to avoid too many hours.

1 phase:
IMPORTANT in this phase, ignoring the OC values ​​completely, must be a pure test.

I would only do the optimization in the activated Protocols, those that are deactivated or must obviously be ignored. Or you could do one by one to each protocol, but I'm more interested in leaving it working hours and in the end having the best configuration

It would be based on the optimization of mining and intensity. Basically I will go to each protocol and all the miners of that protocol, and I say all that can be chosen, whether or not they are activated.

Image we have only activated X17, go to x17 and try the 4 miners there. Try the first one, for example Klaust and do the intensity test from 15 to 31 which is the maximum in jump ranges of 0.3. I would try klaust at 15 - 15.3 - 15.6 - 15.9 ....... until the failure or the maximum that is 31

If it fails, it repeats the test in that same fault intensity, and when it fails twice, it is the fault, for example in 19.6. At that point we took two jumps back, that is, 0.3 and 0.3 = 0.6, and the chosen intensity would be 19.

Then repeat the same procedure with miner 2, miner 3, miner 4 ...

at the end for that protocol, x17, it should self-select only the fastest miner of those that have been tested.

This first pass would choose the best miner for the selected protocol.

2 phase

Focus on intensity and OC at the same time, trying not to be too many steps, but there must be many steps.

There are many tests for a single protocol. Following the previous example, I would have selected X17 and Alexis, probably over 19 (I know because I've tried it).

The variabesl that I am going to give you, I have thought about them for a long time and it is like work, but of course I leave many steps because I have to do it one by one by hand. And with this even if it takes a day, you have the best result.

Intensity: we have the before, in this case 19, because tests will be done in 18 - 18.5 and 19

Core: -20 to +200 in breaks of 10. bone -20, -10, 0, +10, +20 .....

memory, from -200 to +400 in steps of 100, are 6 steps

TP, power supply, from 70 to 100 in jumps of 5. Again there are 6 steps.

To reduce the time, it would be done in two subprocesses. First optimization of the combo (intensity and core), all steps, failures are controlled and are not valid, but you have to do all the steps to know which yields more.
The second subprocess would also be using the core, but the number that we already have before, for example, has given the number 90 of core. Well we will use that number + - 10, in this case 80 - 90 - 100, and the formula would be

(core as I have explained, mem, prower supply), all the steps are done, the errors are ignored, and you only keep the results, choosing the one that more HASH provides.

And it would be optimized. It can be improved more, and it is not only taking into account only the HASH, but also the number of actions taken. Sometimes a very high intensity, because here it affects above all the intensity that is the one that adds more or less load to the nuclei. Well, it is not the same to do at the same time 5 hashes confirmed at 12 mhs, that 8 hash at 11 mhs. Although the Hash is smaller (11mhs) there have been more shares. And you must if you can, because here I think you can not do with those that you can not read, but it would be interesting if you can have both data, well 3.

Test time, maximum hash, number of shares

The idea is that at the same time the combination of shares + HASH is superior. This fits only with intensity, so it may or may not be easy.


I said I was not going to try it, but I see so much potential, and I fully understand that being a single programmer with limited time, do not develop as fast as we would like.
I mention this from the point of view of contributing ideas and suggestions, especially of some things that ALL others do not have.

If I had to choose between what to prioritize, if more miners or if you like the idea of ​​super optimization, choose the super optimization.

Nobody else has it, make the most of each card and each configuration, save time for experts and help newbies. And from the point of view of programming I think it would be easier to super optimize, I really think it is more difficult to explain than to program it. The programming would be about what is already there, because you do not have to change anything, just add those extra steps for those who want to lose a whole day and have the perfect configuration, and if it is not, it will be very close. And at this point I would add that a final control point, also optional, would be obligatory, and that optimized configuration will work for at least 10 minutes in a row, if it passes ok, and if not, it goes back to the previous point of optimization and repeats discarding if you get the same result

With this you will maximize your software before taking the next steps, it will stand out as the main quality against your competition and most importantly, the best daily profit rate. It is important to have intensity and OC adjusted for something, it is the key to profitability.

Once done, it would be a great platform to scale your software with new functions or miners, it is best to take advantage of what is already there, and make the tests as long as it takes to maximize profit.
I think that is just what it takes to be unique and really useful. Do not put ma configurations almost at random and settle for the result. I think that can silence many voices that say they say it does not pay.

Nice hash is hard to beat in benefits but some programs do. Some very good ones like AW lack optimization by protocol and card, and neither a super opcimizacion, also you have to pay for advanced functions. Others are more difficult and data is lost in each update.

You have a lot of auto change groups and to mine directly. You can mine with auto change and at the same time a coin. It has a good profit but it must adjust very well, it has intensity settings, and more important of OC for each protocol and card. Basically it has everything, it can be improved with more functions and pools etc .. But from my humble opinion you need a software that is able to get the best possible configuration for each machine, whatever this machine, have plenty of memory or it lacks, it has more or less CPU and with certain intensities it drowns. For me the super optimization would be the serious takeoff of Hash Auger, that every day I like more.

Regards

Note:
I forgot the tests should be done with all the cards at once. Not for saving time. It is because in real mining they will all be working at the same time creating bottlenecks in some points. It would not be appropriate to do the test with independent cards or one at a time. The test should be how it would be more or less the use when it is mined and not all have the same memory, motherboard and CPU equal.

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

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.

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

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.

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

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.

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.

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.

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.

If you can copy some simple files, why not put an export option? It will always be easier for me to export and save all the configuration in a zip file and use that zip to restore.

The more difficult and time consuming the program causes, the less people will use it. You win from the Dev Fee, make it easier.

I can understand that although two platforms are the same, with different 1080T, the restored data of OC of the first equipment can give some problem. I can understand that, but it will always be easier to import everything and then solve a couple of intensities or OC so that it is ready and working. It would save so much time, if it could be exported and imported from a simple zip, and even if some configuration failed on a card, the adjustment would take a little time. I also understand that in a new rig that I restore a configuration, we must do the benchmark again, but at least the configurations of OC and others, will be done.

One of the advantages of using a program of this type is to simplify the steps to save time. I can devote time to the configurations, but I can not configure and reconfigure in each new version, so I do not use it in all the platforms, only in one of the four. It's money that you do not raise, I do not care about the development rate, but the product has to improve in ease of use, and in being able to save and restore configurations to avoid wallets, swimming pools, etc.

At this moment I do not know whether to wait for more updates or buy the Awersome license ... the important thing is the usability / profitability

Thanks for your attention.

Abusing my confidence, I would suggest two other very simple options.

1.- When you configure the Gpu0, with a button configure all the other cards the same, instead of having to go card to card and copy the option, although you can copy, in a rig of 8 cards you must choose the option to copy the GPU0 7 times, it's a bit tedious, and it's just one more button to copy the 0 card to all the others.

2.- An option to save all the configuration of Wallet, pools and especially the OC configurations. I spend a lot of time releasing each protocol, adjust the intensity and then the OC, one by one each protocol. I can take a whole day to do it. If I lose that configuration it is a waste of time. And if I have 3 equal rigs, I configure only 1, and then I save and restore that configuration in the other rigs. So everything would be much faster.


Thanks for this great software, I am using it only in a rig and when it is ready it will pass to all my machines. I like it a lot, I just need to be able to add a batch of coins and watch only those for the change.

More problems. When I copy the configuration from one card to another, everything except the intensity is changed. If I have Skein with manual intensity in 19 and then I configure the OC for that protocol and I save it. When copied to another card, it passes the configuration but the intensity stays at 0.0

Delete and reinstall and I can copy the card settings. Unfortunately, the automatic intensity is still activated at each start of the program