Introducing CherryPicking - new Windows & Linux Pool Hopper

[ampirebus]

try FAST ADDITIVE 1. I've gotten a decent score so far today, and whenever unitedminers finally solves the block I'll have 2BTC alone just from that. but its looking like that wont happen for weeks or possibly months lol.

[1713968701]

1713968701

[1713968701]

1713968701

[1713968701]

1713968701

[1713968701]

1713968701

[tal0n4]

try FAST ADDITIVE 1. I've gotten a decent score so far today

I've been using the same and done pretty well today too.

[scatterbrain]

i've done pretty well with dynamic multiplicative as well, but there must be some bug that kept it from updating pools

[Bloodred]

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

Ugh, that sounds like I might have missed a serious bug. Do you have anything that may help pinpoint it? Things like all your settings (no miner accounts of course), which pools you use and a log output would be of great help. Were the 3 machines on the same network (I want to rule out some network-related hang)? If you didn't have logging enabled, do you remember seeing some unhandled exception or other messages that were unusual or could signify an error?

LE: Forgot to ask this, did all your rigs get stuck at the same time?

LE2: Any NullPointerException messages specifically?

[scatterbrain]

no they did not get stuck at the same time, but all within an hour of each other. they are also all on the same network. one of the 3 rigs had a socket timeout read timeout error for bitclockers on the pool update right before it went into its 6 hour span but the other 2 did not. i also noticed that on the pool update before it began the 6 hour loop, it did not say which pool was most efficient but rather kept going with the pool it was in. the previous pool update had bitclockers right 0.9932702036013821 efficiency so that's when problem started. i can send you the whole log file if you want it?

[Bloodred]

Yes, seeing exactly what message it stopped at would really help me find the bug. Actually, if you have logs from all your 3 rigs, send them all.

Did you notice any bitcoin-unrelated network problems during the time the miners got stuck?

[scatterbrain]

where should i send them. they're way too long to post here

[Bloodred]

Just upload them to some file host (mediafire for example) and post the links here.

[scatterbrain]

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

[Bloodred]

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.

[Milkshanks]

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.

[Bloodred]

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

[scatterbrain]

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.

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

[amazingrando]

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)?

[scatterbrain]

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.

[Bloodred]

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?

[amazingrando]

Thanks Bloodred.

Here is what I am seeing:

Code:

[Miner0] bitcoinpool.com:8334 17/08/2011 19:15:00, LP connected to bitcoinpool.c
om:8334
[Miner0] bitcoinpool.com:8334 17/08/2011 19:15:46, b4a9f482, accepted
[Miner0] bitcoinpool.com:8334 17/08/2011 19:15:58, d00770f6, accepted
[Miner0] bitcoinpool.com:8334 17/08/2011 19:16:01, 3b0cfa4c, accepted
[Miner0] bitcoinpool.com:8334 17/08/2011 19:16:02, long poll: IO error
[Miner0] bitcoinpool.com:8334 17/08/2011 19:16:05, LP connected to bitcoinpool.c
om:8334
[Miner0] bitcoinpool.com:8334 17/08/2011 19:16:10, a5f37988, accepted
[Miner0] bitcoinpool.com:8334 17/08/2011 19:16:31, 7633cdf4, accepted
[Miner0] bitcoinpool.com:8334 17/08/2011 19:16:37, c4993b08, accepted
[Miner0] bitcoinpool.com:8334 17/08/2011 19:16:43, 3f4e307f, accepted
[Miner0] bitcoinpool.com:8334 17/08/2011 19:16:50, f048332a, accepted
[Miner0] bitcoinpool.com:8334 Problems communicating with bitcoin RPC 0 2
[Miner0] bitcoinpool.com:8334 17/08/2011 19:16:59, warning: job finished, miner
is idle
[Miner0] bitcoinpool.com:8334 17/08/2011 19:17:02, 680f0546, accepted
[Miner0] bitcoinpool.com:8334 17/08/2011 19:17:07, long poll: IO error
[Miner0] bitcoinpool.com:8334 17/08/2011 19:17:12, LP connected to bitcoinpool.c
om:8334

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

[Milkshanks]

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

Actually, nope.

[Folax]

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:

Code:

* Cherry Picking!
Exception in thread "Thread-0" java.lang.IllegalThreadStateException
at java.lang.Thread.start(Thread.java:612)
at ProcessControl.ProcessHandler.startProcess(ProcessHandler.java:104)
at ProcessControl.MinerController.switchPool(MinerController.java:308)
at ProcessControl.MinerController.actionPerformed(MinerController.java:186)
at ProcessControl.MinerController.deadPoolNotify(MinerController.java:94)
at ProcessControl.ProcessHandler.onDeath(ProcessHandler.java:109)
at ProcessControl.ProcessHandler.run(ProcessHandler.java:134)

Hope this is useful to someone.

[Bloodred]

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?