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

CherryPicking has been updated to v0.6.5a
No huge changes this version, a bit of code tidying up and fixed the bugs in the DYNAMIC algorithms (both the one in MULTIPLICATIVE and the one in the 2 ADDITIVE modes). New features coming with 0.6.6, I just released this to get the fixes out, as the bugs were pretty bad.
v0.6.3 to v0.6.5a
v0.6.5 to v0.6.5a

Would be awesome to get some Linux help. I suspect CP is not the issue but Poclbm is, so it could be a short investigation on your side and great rewards for all of us (greater possible userbase too).
0.2BTC to the person posting the line to update my poclbm install on Linux (Linuxcoin to be exact).

Indeed it should've gone to mtred, it's another bug but I haven't tracked it down yet. Right now, these are the most important things on my to-do list for v0.6.6:

• Fix MULTIPLICATIVE (already done actually)
• Find and fix this new bug Found and fixed it, it was division by 0 (there was only 1 valid prop pool, so maximum hash rate = minimum hash rate)
• Implement configurable error thresholds

I think I may install Linux on my notebook one of these days, so there may be some progress on the Linux front as well.

Same thing here. Picking Ars instead of 0.08 Mtred. Switching back to normal now.

Is there an easy way to update an existing poclbm install on linux?
Don't want to mess up the whole install by doing it manually step by step.

Does this work?
-edit- no it doesn't.

Which versions have you tried and are you sure you changed the path cp uses to the new versions you downloaded. I had that issue and resolved it by using m0mchil's poclbm

Could be, a lot of this above it:
Ive read someone else got this 127.0.0.1 problem too (pointing to localhost) but since ive tried 2 Poclbm versions now I don't know what other Poclbm version to try at this point, or if that would solve anything.

been running fast additive_1 for about 2 days now and i noticed that it's picking eligius, a PPS pool, over mtred, a PROP pool which is currently at .094163...this shouldn't be happening should it? i saw this earlier in another situation with bitclockers as well. i'm not getting any errors or anything, it just seems to be prioritizing the PPS pool over the a PROP pool with efficiency way under 1. i changed it to fast additive_2 and it did the same thing. i'll upload the full log for you when i get home bloodred but thought you should know in the meantime. also, no connection issues at all with either pool

18-08-11 08:18:35 * Updating difficulty
18-08-11 08:18:35 Difficulty is: 1805700.8361937
18-08-11 08:18:35 * Updating pools
18-08-11 08:18:35 * 0arsbitcoin
18-08-11 08:18:36 * Pool update done
18-08-11 08:18:36    Type: PPS
18-08-11 08:18:36    Hash rate: 426.032 GH/s
18-08-11 08:18:36    1.0023472415217636
18-08-11 08:18:36 * 1bitclockers
18-08-11 08:18:38 * Pool update done
18-08-11 08:18:38    Type: PROP
18-08-11 08:18:38    Hash rate: 245.29 GH/s
18-08-11 08:18:38    Monitoring mode: SHARES
18-08-11 08:18:38    Round shares: 1117624
18-08-11 08:18:38    1.43939988800921
18-08-11 08:18:38 * 2bitcoinlc
18-08-11 08:18:39 * Pool update done
18-08-11 08:18:39    Type: PROP
18-08-11 08:18:39    Hash rate: 508.831 GH/s
18-08-11 08:18:39    Monitoring mode: SHARES
18-08-11 08:18:39    Round shares: 1194961
18-08-11 08:18:39    1.5390030364195595
18-08-11 08:18:39 * 3bithasher
18-08-11 08:18:40 * Pool update done
18-08-11 08:18:40    Type: PROP
18-08-11 08:18:40    Hash rate: 3.76 GH/s
18-08-11 08:18:40    Monitoring mode: SHARES
18-08-11 08:18:40    Round shares: 1706755
18-08-11 08:18:40    2.198147995980007
18-08-11 08:18:40 * 4eclipsemc
18-08-11 08:18:40 * Pool update done
18-08-11 08:18:40    Type: SCORE
18-08-11 08:18:40    Hash rate: 75.14 GH/s
18-08-11 08:18:40    Monitoring mode: SHARES
18-08-11 08:18:40    Round shares: 2481512
18-08-11 08:18:40    13.742652992457298
18-08-11 08:18:40 * 5eligius
18-08-11 08:18:41 * Pool update done
18-08-11 08:18:41    Type: PPS
18-08-11 08:18:41    Hash rate: 500.363 GH/s
18-08-11 08:18:41    1.0019985490533871
18-08-11 08:18:41 * 6mainframe
18-08-11 08:18:41 * Update error or pool considered invalid (lagging or down)
18-08-11 08:18:41 * 7mineco
18-08-11 08:18:42 * Pool update done
18-08-11 08:18:42    Type: PPLNS
18-08-11 08:18:42    Hash rate: 99.385 GH/s
18-08-11 08:18:42    Monitoring mode: SHARES
18-08-11 08:18:42    Round shares: 2564738
18-08-11 08:18:42    1.8730312242688978
18-08-11 08:18:42 * 8mtred
18-08-11 08:18:42 * Pool update done
18-08-11 08:18:42    Type: PROP
18-08-11 08:18:42    Hash rate: 291.585 GH/s
18-08-11 08:18:42    Monitoring mode: SHARES
18-08-11 08:18:42    Round shares: 73113
18-08-11 08:18:42    0.09416301368977167
18-08-11 08:18:42 * 9nofee
18-08-11 08:18:42 * Update error or pool considered invalid (lagging or down)
18-08-11 08:18:42 * 10ozco
18-08-11 08:18:44 * Pool update done
18-08-11 08:18:44    Type: PROP
18-08-11 08:18:44    Hash rate: 54.525 GH/s
18-08-11 08:18:44    Monitoring mode: SHARES
18-08-11 08:18:44    Round shares: 1265174
18-08-11 08:18:44    1.6294311091316616
18-08-11 08:18:44 * 11polmine
18-08-11 08:18:45 * Pool update done
18-08-11 08:18:45    Type: PROP
18-08-11 08:18:45    Hash rate: 138.82 GH/s
18-08-11 08:18:45    Monitoring mode: TIME
18-08-11 08:18:45    Round time: 29277
18-08-11 08:18:45    1.2187215674112726
18-08-11 08:18:45 * 13slush
18-08-11 08:18:46 * Pool update done
18-08-11 08:18:46    Type: SCORE
18-08-11 08:18:46    Hash rate: 1862.607 GH/s
18-08-11 08:18:46    Monitoring mode: SHARES
18-08-11 08:18:46    Round shares: 3396962
18-08-11 08:18:46    18.8124296777786
18-08-11 08:18:46 * 14triple
18-08-11 08:18:47 * Pool update done
18-08-11 08:18:47    Type: PROP
18-08-11 08:18:47    Hash rate: 21.29 GH/s
18-08-11 08:18:47    Monitoring mode: SHARES
18-08-11 08:18:47    Round shares: 5508353
18-08-11 08:18:47    7.094266668678551
18-08-11 08:18:47 * 16BitcoinPool
18-08-11 08:18:48 * Pool update done
18-08-11 08:18:48    Type: PROP
18-08-11 08:18:48    Hash rate: 187.59 GH/s
18-08-11 08:18:48    Monitoring mode: TIME
18-08-11 08:18:48    Round time: 36083
18-08-11 08:18:48    2.029729696103863
18-08-11 08:18:48 * 17btcserv
18-08-11 08:18:48 * Pool update done
18-08-11 08:18:48    Type: PROP
18-08-11 08:18:48    Hash rate: 2.605 GH/s
18-08-11 08:18:48    Monitoring mode: SHARES
18-08-11 08:18:48    Round shares: 1109843
18-08-11 08:18:48    1.4293786549929186
18-08-11 08:18:48 * 20Bloodys
18-08-11 08:18:49 * Pool update done
18-08-11 08:18:49    Type: PROP
18-08-11 08:18:49    Hash rate: 0.76 GH/s
18-08-11 08:18:49    Monitoring mode: SHARES
18-08-11 08:18:49    Round shares: 1939241
18-08-11 08:18:49    2.497569198784984
18-08-11 08:18:49 * 24DigBtc
18-08-11 08:18:59 * Socket timeout
* Read timed out
18-08-11 08:18:59 * Update error or pool considered invalid (lagging or down)
18-08-11 08:18:59 * 25NinjaCoin
18-08-11 08:19:00 * Pool update done
18-08-11 08:19:00    Type: PPS
18-08-11 08:19:00    Hash rate: 21.4 GH/s
18-08-11 08:19:00    1.046728971962617
18-08-11 08:19:00 * 26ABCPool
18-08-11 08:19:00 * Pool update done
18-08-11 08:19:00    Type: PPS
18-08-11 08:19:00    Hash rate: 118.0 GH/s
18-08-11 08:19:00    1.0084745762711864
18-08-11 08:19:00 * Most efficient pool is: 5eligius
18-08-11 08:19:00 1.0019985490533871
18-08-11 08:19:00 * Cherry Picking!

By that stack trace it seems CP tried to switch from a lagging pool, but for it to do that it would've had to properly start poclbm in the first place. Did that happen? Did you get "Problems communicating with bitcoin RPC" messages?

So I am trying CP on Linux, and it seems to do well (CP itself) up to the point where Poclbm is going to start: Error=13 Permission denied.
I am running the .jar from a root terminal, have set the path to Poclbm in the config file and but now Poclbm is giving trouble.

I changed the path to another version of Poclbm and CP started normal and then gave me this:
Hope this is useful to someone.

Actually, nope.

Thanks Bloodred.

Here is what I am seeing:

It would be great to have any solution configurable - maybe in the settings.cfg catch-all file?

Actually there's already a system in place that disables a pool for 10 minutes if it gets 8 "Problem communicating with bitcoin RPC" messages within a 30s period. Just tell me what error messages you're getting (the exact string) and adding them to the detection list won't be any problem. I guess I could also make the time-out period and the detection threshold configurable via settings.cfg. Would this work for you guys?

i had the same issue with unitedminers. after about 3 days i simply took them off my hopping list. it's a pretty small pool and shouldn't make a huge difference, at least not in the short term. bitcoinpool still gives me RPC issues too, but it's not nearly as bad as what i was getting from united, so i still use them.

i also like the idea for setting a stale/rejected threshold, but rather than completely blacklist a pool, put a penalty on its efficiency. that way worst case every pool goes down you could still hop to the one with a crappy connection and mine something. or place it above some of the tiny pools which take days to find a block.

There are probably a zillion things that would be nice to have in 0.6.6, but one that I think would help a lot is some way of maintaining uptime. What I have been gaining by hopping has been outweighed by uptime issues.

For instance, much of today CP was mining on bitcoinpool.  However, there were tons of RPC communication issues and stales.  I didn't have that problem with other pools, so it seems like it was a pool server issue.  This was also the case this past weekend with unitedminers.

Would it be possible to set a threshold of stales/rejected shares or a count of RPC communication errors in a given amount of time and then blacklist that pool for a period (e.g. a certain number of hours)?

Don't worry about the wasted mining time. CP is still a great program and your help is appreciated. How else would you find bugs without us guinea pigs

Do you get any "Unexpected error, exiting" messages?

Btw Bloodred, I think I may have encountered a bug or something like that. It seems that when I run this game (Dragon Nest) on fullscreen on my computer, CherryPicking just exits, when I check CP back it shows that "Press any key" message, the same as it would if I had typed "exit" in the console. I'm avoiding it by playing in windowed mode, so it's not much of a hassle, telling you just to let you know about it.

It never updated again because the update thread must have gotten stuck somehow, I hope the log(s) will help me determine where and why.

LE: The logs did help and I believe (almost certain) that I've found the bug. There's an instruction in the MULTIPLICATIVE algorithm that isn't properly checked and can cause an unhandled NullPointerException in the thread handling updates which results in it halting execution. It's an easy fix that will be available soon, but until then I recommend not using DYNAMIC_FAST_MULTIPLICATIVE. ADDITIVE 1&2 aren't affected by this.

scatterbrain, sorry for the somewhat-wasted mining time.

i'll do that shortly and send you the link, but looking at the log file myself i see a <* Socket timeout * Read timed out > error for bitclockers during the pool update. for whatever reason it then doesn't display the most efficient pool at the end of the pool update and continues to stay with the current pool (bitclockers), and never updates the pools again