loving the beta the update is greatly appreciated. I am glad to report that I've updated successfully and all pools are reading properly (except mainframe) which is probably legitimately lagging or down
I'll test mainframe and see what's up and if they changed anything.
CherryPicking has been updated to v0.6.5
Thanks Bloodred!
The new configs for polmine and bitcoinpool are working for me.
Can you explain the differences between the three new Dynamic modes? Also, based on your knowledge and simulations is there a configuration (Dynamic vs. normal, shares vs. time, etc.) that you expect to be optimal?
Actually I haven't simulated the new dynamic modes (lots of work for a simulator and I chose to put the work towards CherryPicking itself), that's why I said they're experimental. In any way, purely theoretically (it may actually differ) it should be like this: NORMAL should provide the highest efficiency but also highest variance, STATIC_FAST should provide the lowest variance but also the lowest efficiency. The 3 dynamic penalty algorithms should all be in between NORMAL and STATIC_FAST both for efficiency and variance, but I don't know which is best. MULTIPLICATIVE assigns very high penalties to very slow pools and also changes the hop-off threshold as a consequence of how it works while the 2 ADDITIVE modes are more lenient to very slow pools. ADDITIVE_1 also changes the hop-off threshold dynamically as a consequence of the assigned penalty while ADDITIVE_2 keeps the threshold at 43% and assigns the penalty differently.
There's quite a bit to write in order to properly explain all the algorithms, I want to add some function graphs from wolframalpha to make it as clear as possible. I'll post again or edit this post when I'm done writing everything.
So, this is what each algorithm does:
NORMALAlways chooses the pool with the least submitted shares in the current round, no penalties, as simple as that. A pool that displays a value of 0 has 0 submitted shares, a pool that displays a value of 1 has 0.43 * diff submitted shares, the pool with the lowest priority number is chosen.
Priority function graphSTATIC_FASTAlways chooses the fastest pool with a priority value under 1 (under 43%). No penalties or anything like that. The priority function is the same, even though this method doesn't make much use of it.
DYNAMIC_FAST_MULTIPLICATIVEThis is the first algorithm that is a little bit more complicated, here's what it does:
1. Determine the fastest prop pool with priority under 1. Let's call this pool's hash rate
max_hr2. For each pool, with hash rate
hr, multiply its priority by the penalty
max_hr/hr. Since max_hr is the maximum hash rate, this ratio is always greater than 1 for any slower pool and exactly 1 for the fastest pool. Multiplying a pool's priority value by a number greater than 1 will increase the value, thereby decreasing the actual priority.
P_MULTI(x) = P(x) * max_hr / hr
This method should hop more than STATIC_FAST, because slower pools that find a block can still have a chance to get a lower priority value. The hop-off threshold is also affected because pools are considered unminable at a priority value over 1 and the multiplication will make the priority have a value of 1 earlier than 43% into the round. This method should also increase efficiency because more rounds are mined early, rounds which would have been completely ignored by STATIC_FAST.
This method applies extreme penalties to very, very slow pool. For example if your fastest pool is mining at 200GH/s and you have a 2GH/s pool, the penalty for the 2GH/s pool would be 100. With such a high penalty it's basically impossible to hop on that pool.
3. Hop on the pool with minimal P_MULTI
DYNAMIC_FAST_ADDITIVE_11. Determine the maximum and minimum hash rates among prop pools with priority values under 1. Let's call them min_hr and max_hr.
2. Calculate a penalty between 0 and 0.5 for each prop pool under 1, the fastest pool gets a penalty of 0, the slowest one 0.5, all others in between depending on their hash rate. This is the penalty function:
Penalty(h) = 0.5 / (min_hr - max_hr) * h - 0.5 * max_hr / (min_hr - max_hr)
Note that this function obviously changes based on the minimum and maximum hash rate at the time of update.
Here's an example graph, assuming a minimum of 25GH/s and a maximum of 200GH/s (random values with no special meaning)
3. Add each pool's penalty to its priority. The higher the penalty the higher the priority value, therefore the less likely to jump on the pool.
P_ADD1(x) = Penalty(hr) + P(x)
The hop-off threshold is also affected by adding the penalty. The slowest pool that's penalized with a value of 0.5 will effectively have its hop-off threshold reduced to 21.5% instead of 43%. However this method is much more lenient on very slow pools. No matter how great the difference between the fastest and the slowest is, the slowest will never receive a penalty greater than 0.5. This means that a slow pool has a better chance to be mined than when using DYNAMIC_FAST_MULTIPLICATIVE.
Priority function graph for the slowest pool (0.5 penalty) (Compare this to P(x) to see the differences)
The fastest pool has a graph identical to P(x) (P(x) + 0 = P(x))
4. Choose the pool with the minimal P_ADD1 value.
DYNAMIC_FAST_ADDITIVE_2This works much like ADDITIVE_1, only step 3 is different.
Instead of simply adding the penalty to P(x) to get a new priority function, this uses a function that maintains the hop-off threshold at 43% (decreases the function's slope so that it hits 1 at 0.43 * diff shares and not before). This is the function:
P_ADD2(x) = (1 - Penalty(hr)) * P(x) + Penalty(hr)
(Compare to P(x) and P_ADD1(x) to see the differences)
Again, if the penalty is 0 then P_ADD2(x) = P(x)
This method favors slow pools even more, because their hop-off threshold is fixed at 43% and not lower.
Closing notes:None of these dynamic methods have received any real-world testing (as in mining testing, not software debugging), but they should still prove more efficient than STATIC_FAST while having higher variance (but not as high as NORMAL). I'm actually hoping to get some feedback if anybody uses them and I'll obviously continue to tweak and change them based on that.
As for SHARES vs. TIME mode, those are there more for compatibility with more pools, I don't think they'd make much difference, although SHARES mode should offer more accurate switches.
