Topic: Introducing CherryPicking - new Windows & Linux Pool Hopper - page 18. (Read 43136 times)

Yes, all methods (dynamic or not) that take pools speed into account theoretically reduce your efficiency. The math says you should always mine in the youngest round (what NORMAL does). This also means mining very slow pools for long times and people sometimes don't like this, that's what all other methods address. STATIC_FAST probably has the worst efficiency and the 3 dynamic modes should be in between.

Thank you Bloodred for this detailed description.  I definitely think the ability to detect (and penalize) very slow pools is appealing.  I don't know if I am understanding this properly, but could a high penalty could force you into mining less efficient pools if the range of pool speed is very wide?  United Mining is an example where it took them more than 200 hours to find their last block (and over 170 hours so far on this block), but efficiency for a  while in the past couple of days was much better than other pools.

I'll try to give DYNAMIC a try in the next day or two and provide feedback

I'll test mainframe and see what's up and if they changed anything.

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:

NORMAL
Always 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 graph

STATIC_FAST
Always 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_MULTIPLICATIVE
This 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_hr
2. 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.
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_1
1. 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:
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.
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_2
This 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:
Graph for the slowest pool in this mode (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.

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

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?

This is just a hopper, it doesn't do any actual mining. As far as I know phatk is a Phoenix kernel and CherryPicking currently only supports poclbm, but it will definitely support other miners in the future and Phoenix will surely be among those.
Also, the hash rate it displays is poclbm's own average which takes actual share submissions into account. If you're lucky it will be greater than "normal" and if you're unlucky it will be below "normal".


Here are some new .cfgs for PolMine and BitcoinPool, the archive will be updated too.

Time-based hoping is still somewhat experimental and may have a few bugs that need to be ironed out, but everything worked in my tests.

LE: Updated .cfg archive link.

Is it possible to use the phatk kernel with this?  I am trying -k phatk right now.  My hash rate is normally around 2.3Ghash with it, but am around 2.0 - 2.1 now, just would be nice.

CherryPicking has been updated to v0.6.5

Changelog:

• Re-enabled the old Score profile that mines near 1.0 * diff and late in unlucky rounds. Simulations show that this isn't a good way to do it but since it was still there I thought I'd give people the option. It is enabled using the pool type LONG_SCORE
• Added 3 new hopping algorithms that take hash rate into account, they should be more efficient than STATIC_FAST but are still experimental. See the new ReadMe for short descriptions, if anybody wants details please post in this topic and I'll provide explanations on how they work (don't want to turn this post into a huge wall of text)
  • DYNAMIC_FAST_MULTIPLICATIVE
  • DYNAMIC_FAST_ADDITIVE_1
  • DYNAMIC_FAST_ADDITIVE_2
• Fixed the bug that caused reporting of stale ratios 100x larger than what they actually were
• Added time-based pool hopping! This makes hopping on PolMine and BitcoinPool viable again! See the ReadMe for detailed instructions on how to use the new time-based mode (.cfgs coming too)
• Added a new pool configuration attribute. MonitorMode can either be SHARES or TIME to select between round shares and round time hopping. It defaults to SHARES mode if not defined.
• The SharesEx1 and SharesEx2 attributes now serve as parse control strings for TIME based hopping when this mode is enabled. Their function remains the same in SHARES mode. See the ReadMe for details on how they work and for an example

New buyers will get v0.6.5 when they make a purchase.
Updates for current owners:
v0.6.3 to v0.6.5
v0.6.4 to v0.6.5
Always use the correct update. Applying an update meant for a different version will result in an invalid .jar file. Do not delete the .old files the updater creates, you may need them in case something goes wrong with a future update.

Click here for an update guide

yep, was just about to post that.

I was trying to use the path to guiminer, but I re-downloaded just poclbm and it is working now.

Thanks.

Delete poclbm and download it again, that's a poclbm problem and this seems to be the quickest solution.

Yikes, that is bad.  Disabled it is!

Thanks

take my word for it: don't spend any time trying to get mainframe working...
my payout from mainframe has been awful:

avg pps, poolname, eff
0.0000202594021739130   Mainframe      77%


all it has done is lower my overall efficiency: disabled.

It seems like their API is working http://mining.mainframe.nl/api

I wonder if they've blacklisted the CP client somehow?

I am having trouble getting setup.

I am just testing with bitcoins.lc for now since I already had miners setup.

I am just trying to get one miner going but it keeps saying:

[Miner0] 127.0.0.1:8332 Problems communicating with bitcoin RPC

I thought I had the cfg file for pools and for the bitcoinlc cfg set right.

I also copied the cert file for java.

There's no disadvantage and the miners don't stop for updates. The only possible problem is that it may or may not be more obvious to pool operators that are against hopping if they have some system that checks how often you request their stats pages. Note that the minimum value is 30s, if you set something less than that it will be switched internally to 30s without any explicit messages.

Is there any disadvantage if I set the UpdateTime to 60 Seconds?

The Miners are not disconnecting when a update is running right?

Bye Bloody

OK, good to know its not just me... 

Thanks for the feedback!

Mainframe has never worked for me.  Not sure why that is.  But I only added it into my pools list yesterday, so I wasn't sure if it was temporary or not. 

I am using the exact same configuration right now. Is mainframe actually working for you? I've been running CP since 8/8 and mainframe has never connected for me. I always get this error:

15-08-11 03:24:48 * 6mainframe
15-08-11 03:24:48 * Update error or pool considered invalid (lagging or down)

Phoenix currently isn't supported, as for poclbm you can use any version as long as it accepts the same command line arguments (and ideally has the same console output).