Use this config for mtred, it accounts for the recent changes (and scrapes info from their web page, as they seem to have removed it from the API). Type=PPS
Host=mtred.com
JSON=https://mtred.com
Port=8337
HashEx1=<span id="sh0">\d+\.?\d*</span></td>
HashEx2=>\d+\.?\d*
hashremove=>
Div=1
|
|
|
|
|
I am, but I have significantly less free time and therefore significantly less time to dedicate to CherryPicking. I'm working on 0.6.8, most notably it will have an implementation of organofcorti's hop point approximation functions and a new parameter you can add to pool files to change their priority, so people who want to prioritize merged mining pools over regular pools can do so.
|
|
|
|
|
If Miner0 was running and then the others started on a hop it could very well be the account information issue I suggested. CherryPicking does not handle networking for the actual miners, so it's pretty much impossible for different instances of the same software (the miners) on the same machine to have network issues while others work.
|
|
|
|
|
That feature is actually already implemented and has been implemented from release, so you're saying you've encountered a bug with it?
When using poclbm, it invalidates a pool for 10 minutes if it receives 8 "Problem communicating with bitcoin RPC" errors in a 30s period. With Phoenix, it invalidates if it receives 3 "Failed to connect, retrying" errors in 40s. However, these checks are only made for Miner0 as they are meant to detect network errors (since everything is running on the same machine and on the same connection).
If Miner0 is working and the rest aren't it's very likely that the problem lies elsewhere, not with the pool or the network. They could have indeed crashed or have some other issues, such as bad miner accounts (be very careful with these, some pools accept shares even if your accounts are wrong, so in essence you'd be mining for nothing). If you have wrong accounts for certain pools and certain GPUs, those may not work on those pools but would be perfectly fine on others, so they would seem to stop randomly.
Also, please check actual GPU load to make sure they aren't working, that's a sure-fire way of knowing.
|
|
|
|
|
I'll be fully back in action tomorrow or the next day.
BTCGuild and Deepbit do not work, I haven't made cfgs for them with good reason. They are too fast and delay stats for too long (they get to over 43% of a round during the delay period so you're essentially hopping blind which cannot guarantee efficiency), furthermore in the case of Deepbit the average shares in the last 24h have pretty much nothing to do with the shares of the current round.
Anybody is of course free to try, but I advise not to.
|
|
|
|
i had a small issue upgrading from .066 to .067. CP was able to apply the patch update, but when i started the program i got an invalid or courrupt jarfile error. i have 4 rigs and the same thing happened on all of them. i completely reinstalled CP to see if that helped and i still got the invalid or corrupt jarfile error when i updated to version .067 whether i was updating from .063, .066, or .066a.
i couldn't find a post on how to roll back to a previous version, so i just renamed the current CherryPicking.jar to CherryPicking067.old. i then renamed the CherryPicking066.old to CherryPicking.jar and everything worked fine again. is this the proper way to go back to a previous version? CP still retained all the new updated functions of .067 even though i'm using the .066 .jar file. i don't know much about programming but i thought the code was in the .jar file, so how can the .066 file use the .067 updates, unless the code is not in the .jar file. in which case, what exactly is the difference in the .jar files if i can simply interchange them and not affect how CP runs?
The .old files the updater .bat makes are just the other .jar files renamed, so if you use any of those you're essentially using an older version. To re-update from an older one, download all the needed updates to get to the current version, then rename the respective .old file to CherryPicking.jar and apply the updates in order (the .old files will be generated again). I recommend re-upgrading from 0.6.5 or any older version. In any case, I have re-uploaded the 0.6.6 to 0.6.7 update in case it somehow got corrupted, download that again to be sure. Here are also the correct checksums for 0.6.6 and 0.6.7: 0.6.7 File: CherryPicking.jar
CRC-32: 9ccce5d1
MD4: 6422bade46c6e4e59d5c6b304aeaa1ad
MD5: c7009e1cb51af0d8d36b0a93c53318ac
SHA-1: a99fff9ee398bb95b0ed097414529b45dc3c80bb 0.6.6 File: CherryPicking.jar
CRC-32: cff79356
MD4: c087ffd9704b0faa1ef6d86c0750e75e
MD5: 619a959b53c7d2ae6c2c150c9d1a8a5e
SHA-1: 388f6c1b70990439a958097ee505307983973df9 |
|
|
|
|
Sorry for my inactivity, I'm a bit busy these days, but as soon as I have a bit more time I'll see to making corrections to the pool cfgs and to getting 0.6.8 out.
|
|
|
|
Would it be possible that you could implement support for cherry-picking which GPUs we'd like to use for mining?  Say for instance that I want GPU 0, 1, 3, 4 to be mining with CherryPicking, while GPU 2 is left alone. This can be done with POCLBM and Phoenix, picking which GPU's to dedicate to mining, so could CherryPicking implement this in some way?  EDIT: Anyone else having problems with mainframe, nofee, unitedminers, and bitp.it? CherryPicking has problems connecting to them. I can implement something like that in the next version, should work well enough. Also, are the settings for the btcserv configs in the config pack correct? According to btcserv.net, the global network speed was 12.37 TH/s, and CherryPicking reports the global speed as 13.7 GH/s.. or am I missing something here? Also, still having issues with mainframe, nofee, unitedminers, and bitp.it.  The global speed is the entire mining network, not just that pool. CherryPicking reports the pools speed, not the network's speed. New How to hop out now! 'How to hop' - now with even more chart porn. Great read and very useful info! I'll implement a Score profile where you can set c and that uses the function for the next version of CP. |
|
|
|
but why would it work better?
when there are new config files for some pool u just replace the files sp u dont need to edit them Yeah, that was the idea, though I also post any changes I make to the archive here, so I don't know if people download the entire archive again or just edit the changes. |
|
|
|
|
I know BitcoinPool switched to PROP50, don't know about all other pools. I'll have a look.
|
|
|
|
|
It has been suggested that I separate a pool's mining accounts from the rest of the settings, so each pool would have 2 config files, one for the credentials, one for the other settings. Before implementing this change I want to hear what everybody has to say about it, so would you want this implemented or should I just leave things the way they are?
|
|
|
|
let me think of some other features...  OK OK I got one... When updating the pools...the stuff flies by too fast for my 40 year old eyes...The reason it scrolls by so fast is because you have verry little information per line. Actually I was already planning to do that, I had noticed that the update spam didn't really allow you to see much info. That is the only thing about the hopper that I think "can be improved", meaning I think everything else is perfect!
I'm really happy to hear you think CherryPicking is that good!  Bloodred a pair of suggestions.
First the latest version is solid.
Two minor UI tweaks.
1) eliminate need for pressing enter. i.e. e to exit not e+enter. i for info not i+enter.
I believe it would be as simple as replacing readline() w/ getchar(). Java isn't my language but most languages support both single char reads and line reads from console.
2) Include the "i" info screen when you exit. i.e. hitting e displays final info (simply a call to the function which handles i and then exits. Often I do this manually (i + enter, e + enter) but would be nice to have it all wrapped up.
1) This is actually pretty much impossible in a Java "console" application. Java console apps only really have an input and an output stream, they are not actually aware of running in a console or not and they don't care. Basically, the JVM actually handles the console stuff and reads the application's output stream and writes to its input stream. This means you cannot intercept keypresses or anything like that since you only have access to what the virtual machine is giving you, even if I change to a simple read() that returns a single char, it still only gets written to the input stream itself after you press Enter. I haven't done too much research into this topic, there may be some way to get around this. Native code could be used, but that would likely cause issues with cross-platform compatibility. Not saying that I'm 100% sure it's impossible, but don't expect this. 2) Sure, this is no problem and will be there in the next update. |
|
|
|
Part of the credit goes to max, this feature was his idea. |
|
|
|
Forgetful as I am, I neglected to mention another feature that has been added in 0.6.7, namely that you can see the individual hash rate of each GPU, as has been requested. It can display 8 GPUs at most (no more room on a single default-length terminal line). To switch to/from individual hash rate display press/type g and then Enter. Screenshot below of what it looks like, running on my 2-GPU machine:  |
|
|
|
I think my problem was because I was too agressive... I restarted the system and started cherry a few times and e nded it a few times, all works as it should. There haven't been any changes made to Phoenix on Linux (just checked) since I got it and it's still behaving properly on my install. If you ever get that again I'll have a thorough look through the code, though I can't imagine what could cause high CPU usage in Phoenix. im using windows no problems
Running great on both Windows 7 64bit and Ubuntu 11.04 64.
Good news! |
|
|
|
|
@max, so that's only when trying to stop CP on Linux? Does it happen on pool switches? And just to be sure, it's Phoenix having high CPU usage, not CP itself, right?
As for the slow updating, can you post a sample of Phoenix output without CherryPicking, a screenshot or copy-pasted text will do, including the Phoenix live info display? Which version are you using exactly?
The slow live stats updating may be happening because your version of Phoenix may be outputting different text compared to what I used while developing, that's why I need to see what its output is. As always, as long as pool switching works for you and you have normal load on your GPUs, the slow stats update may be just a 'cosmetic' problem.
@blacbe, that's a nice increase. While testing I can't say I've noticed any hash rate difference on my GPUs, but it's good to hear you're getting significantly better results.
Any problems with Phoenix so far, serious or no? Are you on Linux or Windows?
LE: As for developing, I've used Phoenix 1.6.2 on Windows and to get it on Linux I did a git clone and used that for testing (this was when I posted the screenshots).
|
|
|
|
|
I'm not exactly sure which the fastest Phoenix kernel is, I've used the one linked to above for development, though I don't think a different kernel would make any difference to CP.
|
|
|
|
|
Yeah, that's it. If you want to use Phoenix add Miner=Phoenix (capitalization doesn't matter) in miner.cfg. You don't need to add anything for poclbm, if the entry is missing it defaults to poclbm anyway.
Obviously, have the Path entry to phoenix.exe on Windows or phoenix.py on Linux. On Linux you may need to chmod phoenix.py to make it executable first, CP will get access denied errors otherwise.
|
|
|
|
CherryPicking has been updated to v0.6.7! Changelog:- Added support for Phoenix, both on Windows and Linux!
- New code that intercepts miner messages, necessary due to Phoenix support (first release so should be considered slightly experimental)
- Added proper support for pools which delay stats. The Delay attribute in pool config files may now be used to specify a stats delay time in seconds. Note that this does NOT work for very fast pools (if the pool gets over the hop threshold in the stats delay time, it won't work)
- Added a separate mining profile for proportional 50-50 tax pools! Many thanks to organofcorti for his great research into hopping these pools! The profile for these pools is PROP50
- Changed the score hopping profile in accordance to organofcorti's simulations and research. Thanks again!
- The poclbm.cfg file has now been renamed to miner.cfg, to make more sense with Phoenix usage as well. The Windows updater .bat file renames it automatically, you'll have to rename it yourself on Linux.
- Added a new attribute in miner.cfg, aptly called Miner. It's used to select between poclbm and Phoenix as miners, the accepted values are poclbm and phoenix.
- Added a feature that displays each GPU's individual hash rate, press g then Enter to switch between this display and the default live info display.
- CherryPicking now costs 0.5BTC, up by 0.1 from the previous price point.
Note: Due to lots of new stuff added and change to core process control code this version may bring a few bugs, though I have fixed all bugs that I have found on my systems (Windows 7 x64 SP1 and Ubuntu 11.04 32bit) Updates:v0.6.6a to v0.6.7v0.6.6 to v0.6.7 |
|
|
|
|
CherryPicking doesn't hop pools with a hash rate of 0 since that would be solo mining.
|
|
|
|
|
Show Posts
