Introducing CherryPicking - new Windows & Linux Pool Hopper - page 27.

ampirebus

full member

Activity: 672

Merit: 100

Okay so After running cherry picker for 3 days (will be 3 days @ 9PM CST tonight, its 3PM as of now) I have gotten 1.38BTC on 2 6870 HD miners (i have 4 but i kept 2 just mining on slushs pool w/o hopping for comparison)

This is .47BTC/24 hours for 540mhash.
Compared to the deepbit estimate of .23BTC/24 hour

Overall i am pleased but I am sure you could work out the kinks and get this hopper much more efficient possibly better than bitHopper. (assuming thats your goal, and that bithopper is free and cherry picking costs money)

I've got all the first 14 pools running on my bot (before you updated all the new cfg files). is that too many or the more the better?

the other 2 miners got .28 BTC in 24 hours on slush.
so i guess that is nearly a 100% increase. At first the bot was acting crazy as hell (functioning way worse than my normal miners) but then it got into the swing of things after about 8 hours of running. I am sure my posts of the slush payouts and not being happy with hopping performance irked you but i am sure reading this post will alleviate that Roll Eyes

I really was worried that this was a bust at first.

Bloodred

member

Activity: 112

Merit: 10

Not right now, but support is planned for future versions (no ETA currently).

Ali

member

Activity: 84

Merit: 10

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

Bloodred

member

Activity: 112

Merit: 10

There seems to be a typo in the arsbitcoin cfg, the port is wrong (and poclbm can't connect), It's 8344 instead of 8334, oops. Embarrassed

It should work after that change, sorry for the inconvenience. I'll also update the archive.

Stupidpal

member

Activity: 112

Merit: 10

Problems communicating with bitcoin RPC 0 2
Keeps on going then starts over, repeats the same thing and then says arsbitcoin seems to be lagging.

Bloodred

member

Activity: 112

Merit: 10

What error messages are you getting? Can you please post them?

Stupidpal

member

Activity: 112

Merit: 10

I'm having problems connecting to arsbitcoin, even though cgminer is connecting to it. It's the most efficient pool right now and my backup but it just won't connect. Sad

Aexoden

newbie

Activity: 53

Merit: 0

Quote from: muyoso on August 06, 2011, 06:39:14 PM

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.

Strictly from a math perspective, the only best option is to mine at the pool that currently has the fewest shares in the round (ignoring score-based pools for the moment). The only adjustments to that are things like fees, donations, and perhaps rejected share ratios. (Especially when mining at smaller pools, it may take several weeks or months for things to reach a meaningful average, so short-term data is next to meaningless.)

If someone has simulations or other data showing that some other strategy is better, I'd be interested to see it. I have no access to hoppersden, so I can't really look at anything there.

muyoso

member

Activity: 84

Merit: 10

Quote from: hawks5999 on August 06, 2011, 08:31:18 PM

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.

hawks5999

full member

Activity: 168

Merit: 100

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

member

Activity: 84

Merit: 10

Quote from: Bloodred on August 06, 2011, 06:12:32 PM

Quote from: muyoso on August 06, 2011, 04:54:01 PM

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.

Bloodred

member

Activity: 112

Merit: 10

Quote from: Ali on August 06, 2011, 03:46:38 PM

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.

Quote from: muyoso on August 06, 2011, 04:54:01 PM

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

member

Activity: 84

Merit: 10

Quote from: Bloodred on August 06, 2011, 11:42:46 AM

Quote from: muyoso on August 05, 2011, 11:37:32 PM

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.

Ali

member

Activity: 84

Merit: 10

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

Bloodred

member

Activity: 112

Merit: 10

Quote from: muyoso on August 05, 2011, 11:37:32 PM

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

Quote from: pbj sammich on August 06, 2011, 07:08:13 AM

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.

pbj sammich

sr. member

Activity: 272

Merit: 250

Fighting Liquid with Liquid

anyone running this on ubuntu successfully?

muyoso

member

Activity: 84

Merit: 10

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.

gnaget

full member

Activity: 154

Merit: 102

Quote from: hawks5999 on August 05, 2011, 10:08:20 PM

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

hawks5999

full member

Activity: 168

Merit: 100

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.

Bloodred

member

Activity: 112

Merit: 10

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.

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