Quote from: trucobit on June 08, 2018, 02:48:15 PM

Quote from: zergbitcore on June 07, 2018, 11:14:46 PM

Hello, Patrike
After analyze the statistics I came to understanding important thing: the hashrate of the same algo can be different for different pools. I saw at least 3% difference based on connection ping, pool load and pool mining settings such as difficulty or other things.
Please, make independent hashrate profile values for different pools for the "save hashrate..." function to make profit switching work correctly.

Really what you ask for is done or half done. Within the configuration of a pool, on the left go to ADVANCED and below you can vary the profitability of that pool, this is how I do it and it is the right thing to do. The hashrate for each protocol is the same, the pool can vary by the Ping as you say, or connection problems etc ..

https://www.dropbox.com/s/00y2dx83t4rc9b1/Captura%20de%20pantalla%202018-06-08%20a%20las%2016.23.48.png?dl=0

This corrects what you ask and can do for each pool, add a negative or positive%, because I have found coins / pools that make me earn 50% more, and that hyay to reflect it.

But really then it is misinterpreted within the same program. Let me explain, I use Auto Switch to 60 minutes or more, but in each miner I add a rule, that if the benefit falls below X amount, that miner makes auto switch and restarts the miner to go to another currency. In this way, if I am in a currency that exceeds my minimum amount, it may be undermining much longer and be more profitable.

But that amount is not reflected in the other panels nor are they taken into account for the rules nor in the general statistics, that is half done well. IF it serves at the time of Auto swtich, at that moment if you keep it in mind if you earn more or less for the number that you have indicated. But as I said, I use a rule for each RIG that until it does not fall of X profit does not make Switch, but it is fixed in the benefits without that the gain is modified, look at the following capture

https://www.dropbox.com/s/j1o1c10rkr2kr0l/Captura%20de%20pantalla%202018-06-08%20a%20las%2016.33.46.png?dl=0

That menu is right click on the rig, VIEWS DETAILS, and you see the autoswtich information. If you look at the first result of that window and the amount of the first miner that is in blue, you will see that there is a difference. While the views views window shows the hashrate corrected with our value% that we have added in the pool, in the information of the miner in real time, that% correction does not apply, nor in the statistics window per day and monthly, bone gives a number that does not help us at all, is indicative.

If I invest hours a day in testing coins and pools, and on your estimate correct the real one with a% deviation in each pool, I do not understand why it does not apply to all the information. It makes it almost impossible for me to manage the RIG with the rule that if the daily benefit falls below X, change, because it takes the value of the RIG without applying my% deviation. And I have pools that range from -50% to + 50%. For me it is very important that this value is reflected on all sides, because the daily and monthly statistics do not take it into account and therefore it is a mere adornment.

And to the comment above, the programmer just said "is not designed for that", but that's not my problem. If a pool has a% correction it must be applied on ALL SIDES, to have correct information and for the switch based on a benefit falling below a number, look at the real number with the% percentage applied, if not, Has no sense.

That% deviation only works at the time of autoswicth, there perfect. But not in statistics and not in the real-time miner, with which applying rules on that number is possible but it is not effective after the autoswtich to control the profit perfectly, of course for me personally it is the great failure of this program, not It is serious, but it is easy to fix and adapt it, just add that% in statistics of the miner and in the statistics panel. Thus a rule based on a minimum profit per miner could be effective.

I pray every day for the programmer to correct this, because it is also incongruous, that I show statistics or that in real time in each miner I get the value of uncorrected profit. Really, it would be the most urgent thing to do according to my opinion, we have 1000 functions, rules, menus, options, but then it turns out that they work on a number that does not have the correction or adjustment% applied, it is something that does not make sense and the Change in programming is minimal and fast. It does not make sense to show falsified statistics because they are not corrected. So that I am worth so much option if then the program does not respect my corrections of pools to make decisions by rules.

And on your question, in each pool, modify in advanced with that%, and you have corrected what you said.

Thanks for the feedback. I have actually looked into the display of revenue/profit of custom pools based on the profit factor a bit more and you can expect that the revenue/profit in the miner list will be adjusted for the factor in either the next release or the release after that. This will match what you see in the View Details dialog today already.

Quote from: trucobit on June 08, 2018, 05:27:43 PM

Ask the programmer @patrike :

In rules, the trigger of "miner revenue" has three options, I'm going crazy, I look for the option that takes into account my% correction of the pool.

Once the implementation I pointed out above is done - this should automatically be resolved.