Introducing CherryPicking - new Windows & Linux Pool Hopper

[hawks5999]

I have to say I've been a little nervous about all the additional small pools (even though I requested them  ). It seemed like too much time was going to bithasher.

But I'll be danged. We just solved a block on bithasher while picking (534951 total shares) and now I have 1.73 BTC waiting for confirm. That should keep my daily moving average happy 

Damn you, just made me add ANOTHER pool.  Ive had like 15 tabs open just for pools for like a month now.

I used to do that. I stopped and now just have this quick shortcut list:

[1713874770]

1713874770

[1713874770]

1713874770

[1713874770]

1713874770

[1713874770]

1713874770

[muyoso]

Damn you, just made me add ANOTHER pool.  Ive had like 15 tabs open just for pools for like a month now.

I used to do that. I stopped and now just have this quick shortcut list:
https://i.imgur.com/WlBjL.png

Thats awesome, but I'm too lazy for that.  Ill stick with the 15 tabs in Chrome.  I do like that I can Ctrl+Shift+R and reload all the tabs at once.  

Also, bitclockers working flawlessly, LOVE IT.  

Edit:  Just saw you have bitp.it on there.  Have the config for CP for that?  I tried to make it myself but got stuck trying to figure out the hashrate.

Edit:  NVM, saw the new configs. 

[hawks5999]

get the latest cfg.zip from the first page, second post.

also, use this:
https://chrome.google.com/webstore/detail/oilipfekkmncanaajkapbpancpelijih

I used to have the many tabs open and I just set Auto Refresh Plus to refresh them every 5-15 minutes depending on how active the pool generally was.

Save you some ctrl+ whatevers.

Also, you can just "Bookmark all open tabs" to get started with a list like I have. Then use the bookmark manager to quickly and easily (f2, ctrl-c, alt-tab, f2, ctrl-v) rename the bookmarks to match your cfg files. Then order from there (wish chrome did sort by name).

[hawks5999]

Bloodred, here's where a slicing function could come in handy


I'll probably only end up with a few shares on BitClockers once it is higher than Bithasher.

Would be good to submit to both.

[Bloodred]

About score (and PPLNS) pools
Think I'll do what myself suggested and add a new hopping profile for short rounds. PPLNS has indeed proven to be unprofitable with various algorithm tweaks and a few random data sets. Right now I strongly suggest either removing PPLNS pools or switching them from PPLNS to backup (you'd have higher variance, but it should average out to 1.0, though personally I'd still rather have PPS).
I haven't simulated the Score pool algorithm but I strongly believe it'll produce similar results, so until I change the profile I suggest disabling score pools because on average you'd hurt your efficiency, although you would have a chance of getting much more than PPS.

Bloodred, here's where a slicing function could come in handy


I'll probably only end up with a few shares on BitClockers once it is higher than Bithasher.

Would be good to submit to both.

Something like mining 10 minutes (or some period) on each pool that's close to the minimum? Yeah, I could implement that as long as the interval isn't very very short. If you mean literally a few seconds a slice it probably wouldn't work too well because CP would have to stop/restart each poclbm process once every few seconds, if it's done that often it may introduce unwanted overhead.

[muyoso]

Bloodred, here's where a slicing function could come in handy


I'll probably only end up with a few shares on BitClockers once it is higher than Bithasher.

Would be good to submit to both.

Yea, I disabled bithasher until bitclockers finishes.  Probably should have let the hopper stay on bithashers, but I guess I was too excited to see bitclockers working to see some newly added pool take away its shares. 

[gnaget]

Does it have to be one account per GPU?  I haven't looked too much into this yet, but I have 28 GPUs, and I don't want to create a worker for each on each pool.  Any way to make it per system?

[muyoso]

Does it have to be one account per GPU?  I haven't looked too much into this yet, but I have 28 GPUs, and I don't want to create a worker for each on each pool.  Any way to make it per system?

I have two GPU's in two different systems both using the same workers on every pool without a problem.  IDK if this will scale to 28 GPU's.  I might consider at least for bitclockers using different workers, because you might run into trouble with that many gpu's requesting getworks.

[Bloodred]

All CherryPicking itself requires is one Miner= entry for each GPU. From the hopper's stand point these do not have to be unique, you can have the same line there 28 times, but it has to be there 28 times.

If the pools you're mining support multiple miners connecting to the same account it's all good. If not, it's a requirement put forward by the pool and not by CherryPicking.

[hawks5999]

Just to clarify the Miner= lines: you need one for each GPU in the system. Since you don't have 1 system with 28 GPUs, you won't have 28 Miner= lines in one config.

I have 3 systems with 3, 3 and 4 GPUs. One cfg per pool per system.

[gnaget]

Just to clarify the Miner= lines: you need one for each GPU in the system. Since you don't have 1 system with 28 GPUs, you won't have 28 Miner= lines in one config.

I have 3 systems with 3, 3 and 4 GPUs. One cfg per pool per system.

Oh, I had misunderstood, I thought this was centralized

[muyoso]

Was just thinking that it would be cool to have not only a "PROP" setting but also a "SLOWPROP" setting.  This would be kind of a hack so that you could mine on the slow prop pools after finishing a fast round with a pool with a much faster rate instead of getting stuck at a slow pool all day.  This would work until the miner takes hashrates into account on choosing which pool to hop to. 

The idea would be so that the picker chooses PROP>SLOWPROP>SCORE/SMPPS>BACKUP.  Actually ideally the SCORE implementation would be like bithoppers so that you jump on for 10% and then get off, so that the picker would choose: SCORE>PROP>SLOWPROP>BACKUP.

[pbj sammich]

anyone running this on ubuntu successfully?

[Bloodred]

Was just thinking that it would be cool to have not only a "PROP" setting but also a "SLOWPROP" setting.  This would be kind of a hack so that you could mine on the slow prop pools after finishing a fast round with a pool with a much faster rate instead of getting stuck at a slow pool all day.  This would work until the miner takes hashrates into account on choosing which pool to hop to. 

The idea would be so that the picker chooses PROP>SLOWPROP>SCORE/SMPPS>BACKUP.  Actually ideally the SCORE implementation would be like bithoppers so that you jump on for 10% and then get off, so that the picker would choose: SCORE>PROP>SLOWPROP>BACKUP.

I could make it take hash rate into account, but what method are you suggesting? Going to the fastest (prop) pool under 43%, then switching to the 2nd fastest when the 1st goes over 43%?

anyone running this on ubuntu successfully?

When I've tested a very, very early version on Ubuntu everything worked besides the actual starting of the processes. It would indeed start poclbm, but the miners were always idle and not outputting any error messages. It theoretically could have been some invalid argument in a .cfg (I have some but not too much Linux experience) but I can't say.

[Ali]

I bought it and am wondering if it can be used in conjunction with phoenix or cgminer?

[muyoso]

Was just thinking that it would be cool to have not only a "PROP" setting but also a "SLOWPROP" setting.  This would be kind of a hack so that you could mine on the slow prop pools after finishing a fast round with a pool with a much faster rate instead of getting stuck at a slow pool all day.  This would work until the miner takes hashrates into account on choosing which pool to hop to. 

The idea would be so that the picker chooses PROP>SLOWPROP>SCORE/SMPPS>BACKUP.  Actually ideally the SCORE implementation would be like bithoppers so that you jump on for 10% and then get off, so that the picker would choose: SCORE>PROP>SLOWPROP>BACKUP.

I could make it take hash rate into account, but what method are you suggesting? Going to the fastest (prop) pool under 43%, then switching to the 2nd fastest when the 1st goes over 43%?

Thats what I was thinking.  I don't know if that would be the most profitable, but I have to think sticking with one pool that is slow and only getting a few shares in on faster pools isn't the most profitable.  Over on the bithopper thread they are all trying to implement "slicing" which basically tells the hopper that if there is more than 1 pool under 43% to rotate between them submitting shares.  Again, there are people a lot smarter than me who know what is the most profitable though.

[Bloodred]

I bought it and am wondering if it can be used in conjunction with phoenix or cgminer?

It's planned in the future, but at the moment only with poclbm.

Thats what I was thinking.  I don't know if that would be the most profitable, but I have to think sticking with one pool that is slow and only getting a few shares in on faster pools isn't the most profitable.  Over on the bithopper thread they are all trying to implement "slicing" which basically tells the hopper that if there is more than 1 pool under 43% to rotate between them submitting shares.  Again, there are people a lot smarter than me who know what is the most profitable though.

The earlier shares are most profitable afaik. I wanted to release 0.6.4 today but I'll delay it a bit longer to add this mode that takes hashrate into account. The next version will have 2 prop pool hopping modes to choose from, picking fast pools first or this regular one.

[muyoso]

Thats what I was thinking.  I don't know if that would be the most profitable, but I have to think sticking with one pool that is slow and only getting a few shares in on faster pools isn't the most profitable.  Over on the bithopper thread they are all trying to implement "slicing" which basically tells the hopper that if there is more than 1 pool under 43% to rotate between them submitting shares.  Again, there are people a lot smarter than me who know what is the most profitable though.

The earlier shares are most profitable afaik. I wanted to release 0.6.4 today but I'll delay it a bit longer to add this mode that takes hashrate into account. The next version will have 2 prop pool hopping modes to choose from, picking fast pools first or this regular one.

There is a thread discussing this exact thing here:

http://hoppersden.info/showthread.php?25-What-s-the-better-strategy

I don't know what is the best option anymore.  Looks like slicing or dynamic penalties like Ryouiki's fork is the most efficient according to Ryouiki's simulation.  I am sure you know more about this than I do.  I am grateful for all of your hard work.

Edit:  Also, nofee seems to be switching their server over to google's apparently after this long block is over and I think the host address and username and passwords for everyone will be changing.  No idea what the correct port is because they didn't say.

[hawks5999]

Ryouiki backed out his algorithm and went to vanilla least shares based hopping. I really liked his multi-threshold, time/speed, dynamic penalty approach and would probably still use it if he didn't have the issues with bitclockers like c00w. I'm hooked on picking now and c00w's seems to me to have 'slice'-ed it's own throat for the time being. I'm sure it will work itself out but for now and until ryouiki integrates slicing into his fork I'll keep picking.

[muyoso]

Ryouiki backed out his algorithm and went to vanilla least shares based hopping. I really liked his multi-threshold, time/speed, dynamic penalty approach and would probably still use it if he didn't have the issues with bitclockers like c00w. I'm hooked on picking now and c00w's seems to me to have 'slice'-ed it's own throat for the time being. I'm sure it will work itself out but for now and until ryouiki integrates slicing into his fork I'll keep picking.

Same.  Hard to give up bitclockers.  I am making 5x as much per round at bitclockers with CP compared to BH.