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.
|
|
|
it completely avoided all the best rounds there is no way to know what rounds will be the best because CP cant predict the future so mining in short rounds is always a tricky thing a task was open for this and maybe a child score profile for short rounds can fix your needs Thats why you mine all rounds for no more than 10%. Take these rounds for example: Each round had ~55 shares submitted. 7140 - 201.79% efficiency 7139 - 1201.46% efficiency 7138 - 422.01% efficiency So on the longer rounds when you get nothing, these go a long way to keeping overall efficiency high.
|
|
|
Uploaded with ImageShack.usnot so happy with this. i would have thought the hopper would have seen those short rounds and gone in... it completely avoided all the best rounds! and the ones that it did join are no payout at all . Spent time between eligius and mtred between then, which also ended up having very long rounds. below is a comparison of what i get on slush w/o cherrypicker on... 7140 2011-08-04 19:40:26 0:12:41 355009 0.01410793 139620 confirmed 7139 2011-08-04 19:27:46 0:06:22 178960 0.01227752 139618 confirmed Yea, the way cherrypicker does slush is completely backwards. It should be doing it exactly like bithopper does, which is jumping in at the start of every round for 10% of difficulty shares and then hopping out. I can confirm that this method absolutely works and gives you 100-150% efficiency over time. Cherrypicker: vs Bithopper: I've just disabled slush for now. Been a boring day for hopping so far. Been on Arsbitcoin pretty much all day.
|
|
|
sorry if this is a n00b question but why isnt deepbit hopped
They delay their stats for an hour. Basically its impossible right now to know when they found a block and hop to them.
|
|
|
cherrypicker refuses to go to a backup for me. It just jumps to the lowest prop pool even if its over the 43% threshold. What am i doing wrong?
Are the backup pools set properly? Can you please copy-paste the info it displays when updating the pools? I'll be able to tell what's happening from that. You need a working pool set as BACKUP or it will do just what you've described. I have ars set to backup in the latest stable release. Edit: OK, found the problem. In the config files you have the port set to 8334. The port that works for me is 8344. I think the reason that it wasn't switching to Ars for me last night is that Ars is set to 1.00264 and BTCPool24 was below that, although I will have to keep an eye on this to confirm it. Seems to be working perfectly now that I changed the port. Going to setup another backup JIC.
|
|
|
cherrypicker refuses to go to a backup for me. It just jumps to the lowest prop pool even if its over the 43% threshold. What am i doing wrong?
|
|
|
OK, weird. Polmine is at 41% and CP just switched to Slush, which is at 98.7% of difficulty. This is almost opposite behavior of bithopper. Can't wait to see the results. Edit: I don't see how jumping late into a round at Slush is profitable. Jumping in at the very beginning and staying for 10% of difficulty number of shares is profitable because you are only risking a small amount of shares and when they have a fast round you get a relatively massive payout (2-300% efficiency) and on long rounds you get nothing. Works out to somewhere in the range of 100-150% efficiency from the days I have tested it on BH. From the looks of it, you are trying the opposite. Jumping in on long rounds for the last 10% of difficulty instead of the first. The reason I don't think that would work as well is that you are betting on such a small range. The round literally has to end at difficulty + 5-10% for the maximum payout, if what I see in the console is correct, which rarely happens. Edit2: Loving CherryPicking so far. Would be absolutely amazing if you could do some sort of website output like bithopper and even better if you figured out a way to feed multiple instances of CP into one website output. Edit3: Getting this error on rigs not running a bitcoin server: [Miner0] mtred.com:8337 Problems communicating with bitcoin RPC 0 2 Doesn't seem to be affecting anything. Just want to make sure that I don't need to be running the bitcoin server for CP to work.
|
|
|
Should be coming in a day or two, stats are implemented but I'm still testing to make sure it doesn't display any erroneous information. While debugging I haven't really noticed any difference to guiminer/pure poclbm, both my stock-clocked 5850s are pulling about 288-290MH/s. Prop pool hopping should pretty much be the same to bitHopper, it mines the youngest round under 43%, I think Score needs to be penalized a bit more (changes in next version as well) but I'll have to see exactly how much when I have some simulation results.
Cool. I am running bithopper and CP right next to each other to see what the differences are. I did noticed that Slush solved a block and bithopper jumped to it until it reached .1*difficulty and then hopped back to polmine. CP stayed with polmine the entire time and chose not to hop to Slush. I guess score pools as a kind of backup pool with CP? The way bithopper did it worked out pretty well with anywhere from 100-150% efficiency on Slush, but losing it would not be the end of the world. Also, I don't think CP polls the pools for updates fast enough to catch Slush like that. I really want to see how CP handles bitclockers, which is actually the entire reason I set it up.
|
|
|
Newest SSL patch is working for everything including Mtred and rfcpool. Awesome. Now to see how it handles switching pools compared to bithopper. . . .
Also, can't wait to be able to see the hashrate.
|
|
|
how do i know if its working? I am looking in cataylst at my card actvitiy (usually at 98% in guiminer). but its at a flat 0% while running this. it says all that pool info and then *Cherry Picking ============ but nothing else. Im pretty sure its not doing anything. Lol, I did the same thing. Go to your polcbm.cfg and set the device correctly. Also, getting this error on every update of the pools: * rfcpool * Error occured while trying to communicate or open a connection to https://www. rfcpool.com/api/pool/stats * sun.security.validator.ValidatorException: PKIX path building failed: sun.secu rity.provider.certpath.SunCertPathBuilderException: unable to find valid certifi cation path to requested target * Update error or pool considered invalid (lagging or down) Using the newest SSL patch.
|
|
|
Is there anyway to see the hash rate you are currently mining at? Its really reassuring to see that number.
|
|
|
So hawk, if you had to choose right now which is better, cherrypicker or bithopper? What are the big differences if any?
Trying to figure out if I want to spend the time tonight setting up cherrypicker.
|
|
|
Its gotta be getwork related with bitclockers. [15:46:04] Server change to bitclockers, telling client with LP [15:46:04] LP triggered serving miner [15:46:04] LP triggered serving miner [15:46:04] LP triggered serving miner [15:46:04] LP triggered serving miner [15:46:08] RPC request [getwork] submitted to bitclockers.com [15:46:09] RPC request [getwork] submitted to bitclockers.com [15:46:10] LP Call pool3.bitclockers.com:8332/LP [15:46:15] writing to database [15:46:15] RPC request [00668000] submitted to bitcoin.cz [15:46:20] RPC request [081ca000] submitted to bitcoin.cz [15:46:21] RPC request [getwork] submitted to bitclockers.com [15:46:21] RPC request [602ed000] submitted to bitcoin.cz [15:46:23] RPC request [getwork] submitted to bitclockers.com [15:46:25] Server change to rfc, telling client with LP Cleaned out the non-relevant lines. 4 getworks within 15 seconds and an immediate change to rfc.
|
|
|
This might be part of the problem with bitclockers: [15:32:09] RPC request [c2577000] submitted to bitcoin.cz [15:32:14] Server change to bitclockers, telling client with LP [15:32:14] LP triggered serving miner [15:32:14] LP triggered serving miner [15:32:15] writing to database [15:32:15] LP Call pool3.bitclockers.com:8332/LP [15:32:15] slush: 117863 [15:32:15] RPC request [getwork] submitted to bitclockers.com [15:32:16] RPC request [4ef05000] submitted to bitcoin.cz [15:32:16] btcmonkey: 3137405 [15:32:25] bitclockers: 6019 [15:32:27] RPC request [getwork] submitted to bitclockers.com [15:32:31] nofeemining: 4323061 [15:32:32] triple: 2656095 [15:32:38] RPC request [getwork] submitted to bitclockers.com [15:32:42] slush: 132366 [15:32:44] btcmonkey: 3137421 [15:32:44] btcpool24: 712236 [15:32:46] RPC request [52393000] submitted to bitclockers.com [15:32:50] RPC request [getwork] submitted to bitclockers.com [15:32:59] triple: 2656319 [15:33:01] RPC request [getwork] submitted to bitclockers.com [15:33:03] nofeemining: 4323274 [15:33:09] rfc: 567957 [15:33:09] slush: 146966 [15:33:12] btcmonkey: 3137445 [15:33:13] RPC request [getwork] submitted to bitclockers.com [15:33:15] writing to database [15:33:18] bclc: 5237051 [15:33:26] bitclockers: 8684 [15:33:26] triple: 2656742 [15:33:27] RPC request [getwork] submitted to bitclockers.com Why are there so many getworks being sent to bitclockers? I literally have 4x as many getworks as shares submitted everytime I connect. The last time I hopped to bitclockers I submitted 9 getworks and 3 shares on one of my workers. The other worker was similar. Do normal miners do this?
|
|
|
have you tried it without bithopper as an immediate (and different worker names)?
i still get some connection errors, but not that much as before (atm 1 conn errorevery minute - which bh ignores) - maybe you get more (as you have more getworks in general) - and therefor bh disabled bclockers faster?.
Yep, no bithopper+new ip+new account = bitclockers work semi stable <1gh , total wackjob >1gh , with bithopper+new ip+new account = bitclockers exact same results. Im still 99.9% sure its a getwork per worker issue. I think I agree. I more than doubled my hashrate according to bitclockers by creating a new worker and running two instances of bithopper instead of one, each pointing to its own worker. Still only around half what it should be though.
|
|
|
bitclockers is working fine.. just make a new account, thats enough
Created a new account and its even worse for some reason. Now I cannot even submit a share before bithopper hops away.
|
|
|
Um, I am running 400mhash through bitclockers from a single machine. I did not make a new account or get a new ip. The latest version shouldn't have any obvious errors. When you are running a lot of Mhash's through them what happens? Do they just lag out a lot quicker? b/c we could have the delagger run more often. Or is it just an artificially high reject rate? and is bitclockers the only pool where it appears?
Rejects are fine and pretty low. This is what happens: [14:22:16] RPC request [getwork] submitted to rfcpool.com [14:22:18] btcmonkey: 3134237 [14:22:19] triple: 2620852 [14:22:23] bitclockers: 169721 [14:22:27] RPC request [2dddd000] submitted to rfcpool.com [14:22:28] RPC request [getwork] submitted to rfcpool.com [14:22:35] slush: 10355371 [14:22:39] RPC request [503e8000] submitted to rfcpool.com [14:22:40] RPC request [getwork] submitted to rfcpool.com [14:22:42] RPC request [97826000] submitted to rfcpool.com [14:22:46] btcmonkey: 3134253 [14:22:46] triple: 2621078 [14:22:47] nofeemining: 4307955 [14:22:52] RPC request [getwork] submitted to rfcpool.com [14:22:53] Server change to bitclockers, telling client with LP [14:22:53] LP triggered serving miner [14:22:53] LP triggered serving miner [14:22:54] rfc: 468991 [14:22:54] LP Call pool3.bitclockers.com:8332/LP [14:23:03] btcpool24: 697559 [14:23:03] RPC request [getwork] submitted to bitclockers.com [14:23:09] RPC request [b6976000] submitted to rfcpool.com [14:23:12] writing to database [14:23:13] triple: 2621292 [14:23:14] btcmonkey: 3134268 [14:23:23] bitclockers: 172216 [14:23:24] Server change to rfc, telling client with LP [14:23:24] RPC request [3e8c1000] submitted to bitclockers.com [14:23:24] LP triggered serving miner [14:23:24] LP triggered serving miner [14:23:24] LP Call pool.rfcpool.com:8332/LP [14:23:27] RPC request [d0bdf000] submitted to bitclockers.com [14:23:29] RPC request [getwork] submitted to rfcpool.com [14:23:33] slush: 10370471 [14:23:33] RPC request [6b91d000] submitted to rfcpool.com [14:23:36] polmine: 1060066 [14:23:37] RPC request [b54c2000] submitted to rfcpool.com [14:23:41] triple: 2621511 [14:23:41] RPC request [getwork] submitted to rfcpool.com [14:23:42] btcmonkey: 3134294 [14:23:46] RPC request [8aa82000] submitted to rfcpool.com [14:23:48] nofeemining: 4308177 [14:23:51] RPC request [getwork] submitted to rfcpool.com [14:23:57] rfc: 470617 [14:23:59] RPC request [85cae000] submitted to rfcpool.com [14:24:02] RPC request [246cf000] submitted to rfcpool.com [14:24:02] slush: 10387871 [14:24:03] btcpool24: 697751 [14:24:03] RPC request [getwork] submitted to rfcpool.com [14:24:05] RPC request [6ddf8000] submitted to rfcpool.com I can get like 3-4 shares to bitclockers before it lags and then hops away. 30 seconds on bitclockers and then the server is changed to RFC. No clue why it happens but its gutting my payments.
|
|
|
I have bitclockers working fine for myself.
Did you create a new account, get a new IP or something like that? Did you used to have problems and then fix it in a newer version of bithopper? Are you running one instance of bithopper and having multiple miners connect to it from various rigs?
|
|
|
I am wondering how cherrypicker has bitclockers working. According to some its working flawlessly.
I wonder if its that cherrypicker is using poclbm to mine. Are we sending getworks faster than poclbm or doing anything else that would differentiate us from normal miners? If so, is there a way we could scale it back to blend in with the crowd?
|
|
|
I sent him a pm anyways this is the part that gave me hope. bolding mine. Sorry, proportional is the only fair mining method. A share is a share, no matter when it is submitted. TBH, I really don't mind hopping that much. But as i said before, when it starts wreaking havoc on the pools you're hopping on the problem must be addressed. Hoppers are hundreds of thousands of work requests all hopping together to the same pool; might as well be a "DDoS". his whole reason for coming in here was the high stale problem, as we were submitting bad data and he wanted to tell us to quit. That's the wreaking havoc. That is fixed. Also with the slice now, if we all use different numbers, we wont be hopping simultaneously onto the pools. Their hash rate with rise a bit less drastically. SO that pretty much addresses all the issues he has as a pool OP. ADD 1% of a few gigahashes...well i think the PM might have a chance. I hope it works. His pool is very valuable among the few we have to hop, and I would love to be able to use it effectively.
|
|
|
|