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

I don't know if that would be able to help in this endeavor, I've only quickly checked it out but communicating the API tokens to that website looks just about the same as logging in to the pools themselves. It's definitely using cookies/sessions since it remembers the settings you have.

As has been already pointed out, in theory mining on the pool with the least shares should be the most profitable, no matter the pools hash rate. This *should* increase your income but also increases your variance a lot (for example, a slow pool may only find a block once a week or something).

STATIC_FAST always mines on the fastest prop pool under 43% round shares (this translates to a priority value under 1.0 in CP). This reduces your variance because you're always mining on fast pool and you get payments more often. It theoretically decreases income because it may very well completely ignore slow pools that are earlier in the round than fast ones. Since these early shares are the most valuable, you'd be sacrificing your income for less variance.

As for efficiency calculation - indeed the math itself is trivial, but the problem lies with actually getting the payment from every pool. CherryPicking can (and does) already scrape information from websites as well as JSON APIs, but we have 2 pretty significant issues:
1) Most pools do not provide this information via JSON API + user key or anything like that
2) Most pools do provide this information on a web page which would be easy enough to get, but only if you're logged in. This would mean having some sort of cookie/session emulation like a browser has which would be quite difficult and I suspect time consuming to implement. I haven't worked on anything like that before so there would be a significant learning curve for me as well and all this translates into lots of time. I believe there are much more important things to add/improve in CP for the time being.

Yeah, I guess I could implement something like that. Making it a proxy would completely eliminate the advantage of client hopping though.

Wow. I see that United Miners has decided to stick with Proportional. I had them marked as PPLNS due to an earlier version of their FAQ. Turned out to be a good thing I didn't have them marked correctly.

No, it will most likely go to another slow pool. What you can do is create a settings.cfg file on your cfg folder and add this line to it:


Algorithm=STATIC_FAST

This way CherryPicking will always pick the fastest pool with the newest block and will only fall back to slower pools if necessary.

this exact thing happened to me so hard today, if the bot wouldve stayed at mtred we'd have made a killing but it ditched for unitedminers over and over again making the payouts pretty much nothing
(from mtred)
8/8/11 09:42pm    1h21m44s   50.12400000   377275   95 req.
8/8/11 08:20pm    1h23m51s   50.02543212   384953   89 req.

So All i have to do is change unitedminers to type=backup?

If you are mining at MtRed and suddenly united miners has a short block, you missed out on it completely.  I am still unsure which is the best method myself.  I think I may just set unitedminers to BACKUP manually and let the normal algorithm do its business.

Edit: Actually I don't think that would work setting it as backup.  I have no idea what is the best method now.

Ah, the new STATIC_FAST option? I see. But from what I can see from the changelog, STATIC_FAST can "reduces variance and your income to some extent" How is that possible?

The problem is that Unitedminers is slow as hell, so while it takes them 6 hours to reach 42k shares, the other pools like MtRed reach that almost immediately.  So Cherrypicker will jump to MtRed when they find a block, but almost immediately they are no longer the pool with the fewest shares so it switched back to unitedminers.  If you have the latest version you can set in the settings.cfg the algorithm so that it will stay with faster pools and fall back on the slow pools.

That is easy to figure out.  Go to a pools website and look at their last solved block.  I'll take my last mtred as an example:

I submitted 389 shares and received a payout of 0.05155391.

(389/1888786.705353) * 50BTC = Expected payout of .010297616

(.05155391/.010297616) * 100 = Efficiency of 500% for that round at MtRed.

Sadly there is no real way to do it automatically as most pools don't offer all of the information needed through JSON stats and it would be a pain and a half to scrape all of that information off of their websites.  You can measure your overall efficiency for the day however by adding up all of the payments you received for today and adding up all of their shares and doing the math.

That would be cool, cause I can't seem to keep proper track of my earnings with this much pools. Also, I'm wondering, isn't pool hopping roughly about finding the youngest block amongst pools and mining on that pool? Cause from what I see CherryPicking always tries to mine on unitedminers for example, wich is trying to solve a block for almost 6 hours now while other pools like mtred barely gets mined on by cherry. I know there is something i'm missing here, but I can't figure out what exactly that is.

So now that everything seems to be working well, is it possible to see our efficancy, or how much better we are doing?

@Bloodred

I have a suggestion that could improve your hopper a little, maybe you could add some option on argument so we can have 2 or more different config files. The reason for this is using different arguments on different situations. The way I see it you'd just need to add a argument to set from wich file CherryPicking should read the configs, if no argument is used, it'd read it from poclbm.cfg as always.


Edit: Either that or making a way so we can use this hopper as a proxy, being able to connect multiple miners to it. But I guess that would ask for a ton of coding work.

 

Those are phoenix arguments.  You need to use "-v" for vectors, BFI_INT is baked in and doesn't need to be stated, no idea about fastloop, worksize is "-w128" and aggression at that level would be around "-f5" or so.  So your arguments should look like this:

to the guy saying his mhash is crazy low than normal, my mhash is exactly the same as using guiminer or phoenix. im using XFX 6870 1GB x2 and  x2 Saphhire 5830-2L (overclock to 315 mhash/s one)

i run the 6870s on one machine and the 5830s on another,
however, in my args file for the 5830 for some reason cherry picker says "invalid server entry" and then goes on to read my args line VECTORS BFI_INT FASTLOOP=false WORKSIZE=128 AGGRESSION=13

but on my 6870s it never says anything from the normal -v -w128 args. i think its maybe something with poclbm and it cant handle some args that guiminer can?

@Bloodred

Cool, thanks for all your help. my gpu load is at where it should be, so i'm guessing everything is fine. Thanks.

It's probably fine, as I've said it's taken form poclbm's own averaging which I believe takes into account how many shares you actually submit as well. So if you're unlucky and submit few shares, it'll be lower, if you're lucky and submit lots in a short amount of time it will be higher than your normal hash rate. If you check that value after a long time spent on a pool it should be pretty close to the real value. If this behavior is too confusing I can switch it to a "normal" average, done within CherryPicking. If you're seeing low GPU load though, then there's a real problem, but I don't think so.

That means poclbm (not CherryPicking) cannot connect to the pool. The pool is either down or you have something invalid in its .cfg. Bad miner credentials maybe, or an accidental typo in the hostname, something like that. CherryPicking detects the problem and switches to a different pool, to avoid wasting mining time.

Perfectly normal.

also

-update error or pool considered invalid
-problems communicating with bitcoin rpc 2 3

 

I get that message for all my .cfg files, I thought it was normal. Maybe not?