Bitcoin Forum
December 08, 2016, 06:12:07 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [16] 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »
  Print  
Author Topic: Introducing CherryPicking - new Windows & Linux Pool Hopper  (Read 39821 times)
Bloodred
Member
**
Offline Offline

Activity: 112


View Profile
August 15, 2011, 10:36:14 PM
 #301

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

CherryPicking dev

If you'd like to donate: 15qV7jbw4C43Dcm4JhKL4RXVPKGtvLDAYM
1481220727
Hero Member
*
Offline Offline

Posts: 1481220727

View Profile Personal Message (Offline)

Ignore
1481220727
Reply with quote  #2

1481220727
Report to moderator
1481220727
Hero Member
*
Offline Offline

Posts: 1481220727

View Profile Personal Message (Offline)

Ignore
1481220727
Reply with quote  #2

1481220727
Report to moderator
1481220727
Hero Member
*
Offline Offline

Posts: 1481220727

View Profile Personal Message (Offline)

Ignore
1481220727
Reply with quote  #2

1481220727
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
ditchmagnet
Jr. Member
*
Offline Offline

Activity: 52


View Profile
August 15, 2011, 10:41:01 PM
 #302

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.
Bloodred
Member
**
Offline Offline

Activity: 112


View Profile
August 15, 2011, 10:52:52 PM
 #303

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.
Code:
;BitcoinPool
;Home Page: http://bitcoinpool.com
Type=PROP
Host=bitcoinpool.com
Port=8334
JSON=http://bitcoinpool.com/
HashEx1=Pool Speed: <d class="info">\d+\.?\d* Gh/s
HashEx2=\d+\.?\d*
MonitorMode=TIME
SharesEx1=Round Duration: <d class="info">\d+h&nbsp;\d+m&nbsp;\d+s
SharesEx2=Round Duration: <d class="info">##HOURS##h&nbsp;##MINUTES##m&nbsp;##SECONDS##s
Div=1

Code:
;polmine
Type=PROP
Host=polmine.pl
Port=8347
JSON=https://polmine.pl/?action=statistics
HashEx1=naszej kopalni to<b>[ \.0-9]+</b> Ghash/s
HashEx2=\d+\.?\d*
HashRemove=
MonitorMode=TIME
SharesEx1=Czas szukania bloku: &nbsp; </b> <br/> \d+ dni \d+ godzin \d+ minut \d+ sekund
SharesEx2=Czas szukania bloku: &nbsp; </b> <br/> ##DAYS## dni ##HOURS## godzin ##MINUTES## minut ##SECONDS## sekund
Div=1
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.

CherryPicking dev

If you'd like to donate: 15qV7jbw4C43Dcm4JhKL4RXVPKGtvLDAYM
amazingrando
Hero Member
*****
Offline Offline

Activity: 546



View Profile
August 15, 2011, 11:18:55 PM
 #304

CherryPicking has been updated to v0.6.5


Thanks Bloodred!  Grin

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?

Bitbond - 105% PPS mining bond - mining payouts without buying hardware
ampirebus
Member
**
Offline Offline

Activity: 84


View Profile
August 15, 2011, 11:19:16 PM
 #305

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
Bloodred
Member
**
Offline Offline

Activity: 112


View Profile
August 15, 2011, 11:37:23 PM
 #306

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!  Grin

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:

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.
Code:
P(x) = x/0.43
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.
Code:
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_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:
Code:
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.
Code:
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_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:
Code:
P_ADD2(x) = (1 - Penalty(hr)) * P(x) + Penalty(hr)
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.

CherryPicking dev

If you'd like to donate: 15qV7jbw4C43Dcm4JhKL4RXVPKGtvLDAYM
amazingrando
Hero Member
*****
Offline Offline

Activity: 546



View Profile
August 16, 2011, 02:37:48 AM
 #307

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


Bitbond - 105% PPS mining bond - mining payouts without buying hardware
Bloodred
Member
**
Offline Offline

Activity: 112


View Profile
August 16, 2011, 02:53:49 AM
 #308

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.

CherryPicking dev

If you'd like to donate: 15qV7jbw4C43Dcm4JhKL4RXVPKGtvLDAYM
DrG
Legendary
*
Offline Offline

Activity: 1456



View Profile
August 16, 2011, 05:08:33 AM
 #309

I downloaded the upgrade patch from 0.6.4 to .5 and when i tried to run upgrade it game me an error saying the bspatch was not found.  It went ahead and renamed the cherrypicker.jar file to old.  Do I need to install BSpatch to use this upgrade?

amazingrando
Hero Member
*****
Offline Offline

Activity: 546



View Profile
August 16, 2011, 05:10:57 AM
 #310

I downloaded the upgrade patch from 0.6.4 to .5 and when i tried to run upgrade it game me an error saying the bspatch was not found.  It went ahead and renamed the cherrypicker.jar file to old.  Do I need to install BSpatch to use this upgrade?

Yes, you need it.  Follow the upgrade instructions https://bitcointalk.org/index.php?topic=33031.msg441154#msg441154

Bitbond - 105% PPS mining bond - mining payouts without buying hardware
ampirebus
Member
**
Offline Offline

Activity: 84


View Profile
August 16, 2011, 07:55:52 AM
 #311

I've been running fast additive 1 since the release and its looking good here... hopped around mtred for .1 BTC in an hour and then bitclockers and bitcoins.lc then polmine

if only there were a way to set cherrypicking to dynamically change algorithms based on how long or fast rounds at pools are going. (1/4th of the day on normal, 1/4th on static fast, 1/4th on dynamics and 1/4 whatever) it would be even cooler or possibly efficient . Sorry if that idea is worded not so well but I mean if the bot could switch between the algorithms better (on its own rather than human configuration) always choosing the (logically) best perceived payout at that point in time
Bloodred
Member
**
Offline Offline

Activity: 112


View Profile
August 16, 2011, 12:22:45 PM
 #312

Implementing something like that wouldn't be so difficult, but first I'd need some real-world data to see which algo performs best in which circumstance, to know when to use it.

CherryPicking dev

If you'd like to donate: 15qV7jbw4C43Dcm4JhKL4RXVPKGtvLDAYM
Bitsinmyhead
Sr. Member
****
Offline Offline

Activity: 376


View Profile
August 16, 2011, 03:45:54 PM
 #313

I have installed Cherrypicker using all pools except for a couple. Everything looks great and is running smooth. Just wondering if any of the more experienced users have any advice on changes to the configurations I could make. I am currently running v0.6.5 with everything on default.

Trade Bitcoin using credit card and with 4:1 leverage at plus500.
Sign up through: http://www.plus500.com/?id=67176&pl=2 for €25 free, or become an affiliate here: http://www.500affiliates.com/?id=67176
cuqa
Jr. Member
*
Offline Offline

Activity: 40


View Profile
August 16, 2011, 06:08:41 PM
 #314

i recommend to remove bitcoinpool from the rotation. its obvious that they fake their shares as decoy and then even demand a fee. also they are so unprofessional in every way.. avoid!
Bloodred
Member
**
Offline Offline

Activity: 112


View Profile
August 16, 2011, 06:26:51 PM
 #315

I have installed Cherrypicker using all pools except for a couple. Everything looks great and is running smooth. Just wondering if any of the more experienced users have any advice on changes to the configurations I could make. I am currently running v0.6.5 with everything on default.
As many prop pools as possible and NORMAL (default) algorithm will theoretically give you the best efficiency but also pretty high variance.

i recommend to remove bitcoinpool from the rotation. its obvious that they fake their shares as decoy and then even demand a fee. also they are so unprofessional in every way.. avoid!
BitcoinPool isn't hopped using shares anymore, as of 0.6.5.

CherryPicking dev

If you'd like to donate: 15qV7jbw4C43Dcm4JhKL4RXVPKGtvLDAYM
Bitsinmyhead
Sr. Member
****
Offline Offline

Activity: 376


View Profile
August 16, 2011, 06:48:45 PM
 #316


As many prop pools as possible and NORMAL (default) algorithm will theoretically give you the best efficiency but also pretty high variance.


Thanks for your reply. Does this mean I should remove the pools that are non prop pools or can I keep them on my pool list as well as long as I have as many prop pools as possible on there?

Trade Bitcoin using credit card and with 4:1 leverage at plus500.
Sign up through: http://www.plus500.com/?id=67176&pl=2 for €25 free, or become an affiliate here: http://www.500affiliates.com/?id=67176
Bloodred
Member
**
Offline Offline

Activity: 112


View Profile
August 16, 2011, 07:04:02 PM
 #317

You could remove PPLNS pools, the algorithm for those is still old and may not provide optimal efficiency. Score pools are a gamble but should have average efficiency over 100% on average.

CherryPicking dev

If you'd like to donate: 15qV7jbw4C43Dcm4JhKL4RXVPKGtvLDAYM
Bitsinmyhead
Sr. Member
****
Offline Offline

Activity: 376


View Profile
August 16, 2011, 07:45:17 PM
 #318

Great! What about SMPPS pools, keep that? Thanks again for all the help. Will ship you an extra donation once this thing starts paying off Cheesy

Trade Bitcoin using credit card and with 4:1 leverage at plus500.
Sign up through: http://www.plus500.com/?id=67176&pl=2 for €25 free, or become an affiliate here: http://www.500affiliates.com/?id=67176
Bloodred
Member
**
Offline Offline

Activity: 112


View Profile
August 16, 2011, 09:08:52 PM
 #319

Yeah, you can keep SMPPS pools, they are backup. Just remember that you must have a PPS or BACKUP type pool for CherryPicking to work properly.

CherryPicking dev

If you'd like to donate: 15qV7jbw4C43Dcm4JhKL4RXVPKGtvLDAYM
scatterbrain
Member
**
Offline Offline

Activity: 72


View Profile
August 17, 2011, 01:24:03 AM
 #320

i've been running v.0.6.5 for the last 24 hours with DYNAMIC_FAST_MULTIPLICATIVE. everything was going well but then CP got stuck on bitclockers for about 6 hours even though it was not the most efficient. it never stopped to check and update the pool status during the whole 6 hours, and this happened on 3 different rigs all with the same settings. i restarted CP and it updated the pool status and switched the the proper pool and seems to be working fine since then
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [16] 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!