Just purchased - Though the pool config files download link is not working, can you reupload it somewhere else?
Thanks
Topic: Introducing CherryPicking - new Windows & Linux Pool Hopper - page 8. (Read 43136 times)
September 04, 2011, 01:50:10 PM
September 03, 2011, 08:46:31 PM
Correct me if i am wrong, but mmc is a hoppable pool no?
Ill jump in here briefly to correct you.
No its not. We implemented PPLNS 1 week ago. No longer hoppable.
September 03, 2011, 07:16:12 PM
lately I have been having troubles with some pools. These are the ones with the problems:
mtred java certificate problem
btcmonkey lagging or down
bitp java certificate problem
arsbitcoin java certificate problem
poolmunity java certificate problemn I see it might be closed down...site says...We're currently offline and are back within 2-3weeks (end of september)
anyone else having problems with those pools?
mtred java certificate problem
btcmonkey lagging or down
bitp java certificate problem
arsbitcoin java certificate problem
poolmunity java certificate problemn I see it might be closed down...site says...We're currently offline and are back within 2-3weeks (end of september)
anyone else having problems with those pools?
September 03, 2011, 12:59:59 PM
All running smooth so far. it has been about 3 hours... 
Now...here is a little something I think should be added...
I run 7 GPU in one machine. I love seeing the total hash, but how can I tweak a single card? a suggestion would be...just like when we press i, or e....we have a g command...meaning all info at the bottom stops and we get numbers that represent the hash amount each gpu is getting.
so the bottom of the window would look something like:
GPU-->404 350 354 344 349 351 355
press g and enter, and it goes back the old way...
I'll add something like that, sure.Now...here is a little something I think should be added...
I run 7 GPU in one machine. I love seeing the total hash, but how can I tweak a single card? a suggestion would be...just like when we press i, or e....we have a g command...meaning all info at the bottom stops and we get numbers that represent the hash amount each gpu is getting.
so the bottom of the window would look something like:
GPU-->404 350 354 344 349 351 355
press g and enter, and it goes back the old way...
great phoenix will make my hashrate go up 15%. that with hoping will be like getting a new gpu 
Working on Linux too.
September 03, 2011, 01:32:00 AM
Edit:
Making some progress regarding Phoenix support in the upcoming v0.6.7
Making some progress regarding Phoenix support in the upcoming v0.6.7
great phoenix will make my hashrate go up 15%. that with hoping will be like getting a new gpu
September 02, 2011, 11:04:56 PM
All running smooth so far. it has been about 3 hours...
Now...here is a little something I think should be added...
I run 7 GPU in one machine. I love seeing the total hash, but how can I tweak a single card? a suggestion would be...just like when we press i, or e....we have a g command...meaning all info at the bottom stops and we get numbers that represent the hash amount each gpu is getting.
so the bottom of the window would look something like:
GPU-->404 350 354 344 349 351 355
press g and enter, and it goes back the old way...
Now...here is a little something I think should be added...
I run 7 GPU in one machine. I love seeing the total hash, but how can I tweak a single card? a suggestion would be...just like when we press i, or e....we have a g command...meaning all info at the bottom stops and we get numbers that represent the hash amount each gpu is getting.
so the bottom of the window would look something like:
GPU-->404 350 354 344 349 351 355
press g and enter, and it goes back the old way...
September 02, 2011, 07:37:15 PM
Yes, it would work, just remember to always have a backup of the .jar, just in case. There really isn't any reason to update the Windows version though, there is literally nothing that could make a difference, just some code changes that do the same things but in a different way (completely transparent while running).
Edit:
Making some progress regarding Phoenix support in the upcoming v0.6.7
Edit:
Making some progress regarding Phoenix support in the upcoming v0.6.7
September 02, 2011, 06:04:06 PM
Normally I would just update my windows version and copy the folder over to the linux machine...If i change the values to reflect the current files in the update bat will this work?
for testing purposes i frequently swap from windows to linux... so i like having both with the same version of CP.
for testing purposes i frequently swap from windows to linux... so i like having both with the same version of CP.
September 02, 2011, 05:57:49 PM
im on it...
September 02, 2011, 01:26:44 PM
So I've made a possible bugfix (v0.6.6a) for the Linux error, I believe it has something to do with threads not synchronizing properly in Linux, so I've changed the code to make it a bit 'safer'. This version also displays a more explicit error message (may help if this does not fix it). Windows users have no need whatsoever to bother with this version (though you can update if you want to for some reason).
v0.6.6 to v0.6.6a
Here's a short guide on how to update on Ubuntu, I don't know much about Linux so if it doesn't work on another distro you'll have to figure it out yourself (most notably getting bsdiff and bspatch installed).
1. Open a Terminal window.
2. Install bsdiff and bspatch:
3. Extract 066to066a.bin to your CherryPicking directory.
4. In Terminal, navigate to your CherryPicking directory.
5. Rename your old .jar:
That's it, you should now have the latest version, you can run it the same as you were running the old one. Tell me if you're still getting that bug!
v0.6.6 to v0.6.6a
Here's a short guide on how to update on Ubuntu, I don't know much about Linux so if it doesn't work on another distro you'll have to figure it out yourself (most notably getting bsdiff and bspatch installed).
1. Open a Terminal window.
2. Install bsdiff and bspatch:
Code:
sudo apt-get install bsdiff
(or go through the software center to get it installed)3. Extract 066to066a.bin to your CherryPicking directory.
4. In Terminal, navigate to your CherryPicking directory.
5. Rename your old .jar:
Code:
mv CherryPicking.jar CherryPicking066.old
6. Apply the update using bspatch: Code:
bspatch CherryPicking066.old CherryPicking.jar 066to066a.bin
That's it, you should now have the latest version, you can run it the same as you were running the old one. Tell me if you're still getting that bug!
September 02, 2011, 10:12:36 AM
Right now only poclbm or poclbm "compatible" miners are supported, meaning anything that has the exact same command line arguments as the current version of poclbm will work. Ideally you want it to also have the exact same output messages, if not various "extra" features won't work (for example CherryPicking may spam the console with useless messages, stats tracking won't work, lag detection won't work, etc).
I'm working on an update right now that will add several new features, Phoenix support among them. It may be a few days until it's done.
I'm working on an update right now that will add several new features, Phoenix support among them. It may be a few days until it's done.
September 02, 2011, 09:42:17 AM
i don't know if you'll know what's wrong but for cherrypicking i'm using the command -v -w128 -f0 in poclbm. my gpus are only being used at 94-95% load. i use 99% with phoenix or kiv's poclbm backend. is it possible you could use kiv's poclbm backend or phoenix for cherrypicking? they are better optimized than poclbm and would increase hashrates 15%
September 02, 2011, 01:57:30 AM
i realize i didn't account for difficulty. i wasn't exactly sure how or if it was applicable. there were 2 difficulties in my data and it went down by only 83000 when it changed; a pretty small amount compared to most of the other difficulty changes i've seen. small enough i thought to not really have an effect on how it would impact results if it was applicable. is that a poor assumption?
why exactly does difficulty need to be applied at all? how does it change the ratio of my actual earned BTC/day/Ghash/s to somone's BTC/day/Ghash/s who mines at a PPS pool?
why exactly does difficulty need to be applied at all? how does it change the ratio of my actual earned BTC/day/Ghash/s to somone's BTC/day/Ghash/s who mines at a PPS pool?
Fee-free PPS reward for mining 1Ghps for one day at current difficulty = 10^9*3600*24*50/1777774/2^32 = 0.5657797
Fee-free PPS reward for mining 1Ghps for one day at last difficulty = 10^9*3600*24*50/1805700/2^32 = 0.5570296
Yep, not a huge increase - only about 1.5%. But if you were looking at several months, especially when difficulty was doubling, it would have a rather large effect.
For the record, my average
September 02, 2011, 01:37:54 AM
het scatterbrain, you haven't taken difficulty changes into account. If you plot the coins you get in your bitcoin client against days, you'll see a slight curve. You can do one of two things:
- Calculate the expected payment per share for each difficulty (50/difficulty), add up the total shares for the period and multiply, and you'll get what you would have gotten at a fee-free pps pool
- Only average your results per difficulty period
Hope this helps.
[/quote]
i realize i didn't account for difficulty. i wasn't exactly sure how or if it was applicable. there were 2 difficulties in my data and it went down by only 83000 when it changed; a pretty small amount compared to most of the other difficulty changes i've seen. small enough i thought to not really have an effect on how it would impact results if it was applicable. is that a poor assumption?
why exactly does difficulty need to be applied at all? how does it change the ratio of my actual earned BTC/day/Ghash/s to somone's BTC/day/Ghash/s who mines at a PPS pool?
September 02, 2011, 12:12:35 AM
Any kind of upgraded config pack with new pools added?
September 01, 2011, 11:11:24 PM
* Bloodred - I'm using Linux Mint 11 LXDE with sun-java6-jre_6.26-1natty1_all. I'm sending the logs over now.
September 01, 2011, 11:09:08 PM
i've been looking at my mining data and continue to be very impressed with CP. blood i must thank you for doing such a great job. with roughly a month of data to look at, 1 Ghash/s is averaging .75 BTC/day. the last 5 days alone 1 Ghash/s has been averaging almost .9 BTC/day. anyone else with some comparison numbers? it would be awesome if i was the low to mid end of the spectrum.
I do not know how to do the calculations to get this information, but if you would like I can send you the info and you can calculate it yourself and compare. Just let me know the stuff you need to do the calculations...
all i did was take my average BTC/day for the 1 month period and divided by my hashrate(in Ghash/s)
so if i was mining 5 BTC/day at 7 Ghash/s: 5/7 = .714 BTC/day/Ghash/s, almost as good as my average
. it's a good stat to use when calculating how long a card will take to pay itself off. using that example, a new 5970 from newegg, with price tag of $500 and hash rate of 800 Mhash/s, would get about .5712 BTC/day. assuming current price(1BTC=$8.3) and difficulty remain the same, it would take about 60 BTC, or 105 days to pay off. this is not including electricity costs. using a common mining calculator, such as http://www.alloscomp.com/bitcoin/calculator.php or http://98.200.247.249:81/btc_calc.php, shows it would take about 133 days to pay off if you didn't pool hop. CP is giving me more than a whole months advantage over those poor saps who think pool hopping is unfair, or more than 2 months if i used my 5 day average (which will most likely drop) but is still crazy! now if only i had a 20Ghash farm...please correct me if any of the math looks wrong
het scatterbrain, you haven't taken difficulty changes into account. If you plot the coins you get in your bitcoin client against days, you'll see a slight curve. You can do one of two things:
- Calculate the expected payment per share for each difficulty (50/difficulty), add up the total shares for the period and multiply, and you'll get what you would have gotten at a fee-free pps pool
- Only average your results per difficulty period
Hope this helps.
September 01, 2011, 10:41:12 PM
Do they have a JSON API and/or do they display the number of round shares or time somewhere? I've had a look but couldn't find anything like this.
September 01, 2011, 10:17:06 PM
bloodred, is it possible to put together a cfg file for bitminter? nice little prop pool at 70 Ghash/s
September 01, 2011, 09:19:47 PM
current.log is the log file CherryPicking is currently writing in, it only exists while CherryPicking is running. When you close it (via the proper command) current.log is renamed to the timestamped version. It does this so you can easily see the active log and because it obviously can't know at what time you'll stop it.
Log sent sir...
Jump to: