simonk83
|
|
August 09, 2011, 12:36:20 AM |
|
Is anyone able to pinch the code and port it to the default scheduler (as I assume most of us are using that)?
|
|
|
|
|
|
|
"Governments are good at cutting off the heads of a centrally
controlled
networks like Napster, but pure P2P networks like Gnutella and Tor seem
to be holding their own." -- Satoshi
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
GenTarkin
Legendary
Offline
Activity: 2450
Merit: 1002
|
|
August 09, 2011, 12:41:11 AM |
|
slush just got a new block and the hopper didnt switch over to it, its still making sure the other hoppable pools slice accounts are "caught up" =(... I want slush to take priority over those...grr
Pull the latest code from c00w. There is code now to jump to slush while it's "hot" and return to normal when it's not, but only with the alternate scheduler: --scheduler=AltSliceScheduler and only when it's set to mine_slush. Isn't this possible to do with the default slicer? It will mine ONLY on slush, until approximately 10% is reached. Yeah, Id like some clarification on this, because I jsut sat here and watched the default scheduler just keep switching between 3 pools when slush's was around 2% till 11%.... =( I hope you can see the clarification. he was only working on that one scheduler, so no, it isnt on the default... not to be overly snarky HAHA, well call me blind =P Thanks for the clarification and yes! I want this on the default scheduler as well so I can use it along w/ testing deepbit startLP mining....
|
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
August 09, 2011, 12:44:12 AM |
|
All I'm saying is if you have more than three pools, the only hopping you have to do is when another pool has fewer shares than the one you're on. You shouldn't have to jump to backup at 43% - this number its only useful if you have one proportional pool and one pps pool. So if any pool ops are checking for you hopping off at 43%, not hopping off then won't have an effect on your long term earnings. ... sort of. we're talking long term here, so even going over 1*diff doesn't matter. If you set the threshold to 3*diff, then for a particular round it might make a difference, but only if no other pools were available. But that's pretty rare and in the long run it wont have a significant effect on overall earnings. ... I know this is all very counter intuitive - I wrote the sim and it took me a week to believe the results. Plus I'm probably not explaining it well, sorry.
First, I wanted to thank you for doing these sims and sharing the results, this is absolutely fascinating. It makes sense right up until going over 1*diff part. I think that is what I'm having trouble getting my head around, so maybe you could try to explain that aspect of it better? It seems that any time that you can submit a share with a higher EV that is your best course of action. Is this specifically vs. submitting to a PPS pool? Would I be right in assuming that if you had the option to Solo mine vs submit a share at more than 1*diff that Solo mining would be the better option in the long run? Sorry for all the questions, just a little bit mind bending.... (Oh, and if anyone has a hden invite, I'd love to not be cluttering up the thread with non-BH stuff. Thanks) I'm glad I could confuse you as much as relearning all my uni stats confused me. In stats it seems that 'common sense' is often not a very reliable guide. The reason that going over 1*diff is ok: Each data point is the result of at least one hundred thousand rounds using that particular hop off point (x axis). It's not the result of just one round. So while it may impact a particular round, if you have enough pools it wont happen very often. Just because you set your hop threshold to say 3*diff, it doesn't mean you'll mine the often, and in the long run won't make a significant difference to your earnings. A pleasant side effect is although you'll still be hopping, it wont be until just 43% any more so it will be harder to point you out as a hopper. As far as your second question goes, yes that's true. But it won't happen often enough to give you many pps shares if you have lots of other pools. See the difference between the '0 other pools' graph and the '5 other pools' graph? Hopping to another pool that just found a block will happen more and more frequently when you have more pools, and sooner. I won't clutter this thread up further, but I'll get some intro to hopping blog posts up on hoppersden using byteHopper to illustrate. When I can stop fiddling with the sims, that is. The best hop point vs efficiency for slush should be done soon.
|
|
|
|
paraipan
In memoriam
Legendary
Offline
Activity: 924
Merit: 1004
Firstbits: 1pirata
|
|
August 09, 2011, 12:47:35 AM |
|
@GenTarkin For me mine_slush works nice in the default scheduler, dunno if it matters but I played with penalty too (1-4)
|
BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
|
|
|
simonk83
|
|
August 09, 2011, 12:50:03 AM |
|
@GenTarkin For me mine_slush works nice in the default scheduler, dunno if it matters but I played with penalty too (1-4)
Hi paraipanakos, the problem with it is that it still switches between slush and other pools when slicing. Ideally (and what has just been added to altslicer) we want it to switch to slush as soon as it turns to zero, and stay on slush (ignoring everything else) until 11%.
|
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
August 09, 2011, 12:50:42 AM |
|
I think this fulfills the idea that gnaget put forth originally as mine_friendly or mine_charity.
Not quite. There's a difference between regularly mining over difficulty*1 and only doing it when there are no other pools with fewer shares available. With mine_charity you will loose significant efficiency because you're doing it systematically and regularly. If you only mine over diff*1 when there aren't other pools available it doesn't make much difference since it wont happen often.
|
|
|
|
ed64
Newbie
Offline
Activity: 42
Merit: 0
|
|
August 09, 2011, 12:52:37 AM |
|
@GenTarkin For me mine_slush works nice in the default scheduler, dunno if it matters but I played with penalty too (1-4)
Personally I think mine_slush should be removed and replaced by penalty, it's more dynamic and can account for say a 100ghash pool that delays stats by 1 hour (still hoppable). While a pool that delays stats for 1 hour > 1Thash/s, it's impossible to know where they are.... Or for smaller/slower pools, I put in a penalty so I don't mine too much on them, since payouts take forever...
|
|
|
|
paraipan
In memoriam
Legendary
Offline
Activity: 924
Merit: 1004
Firstbits: 1pirata
|
|
August 09, 2011, 12:59:09 AM |
|
@GenTarkin For me mine_slush works nice in the default scheduler, dunno if it matters but I played with penalty too (1-4)
Hi paraipanakos, the problem with it is that it still switches between slush and other pools when slicing. Ideally (and what has just been added to altslicer) we want it to switch to slush as soon as it turns to zero, and stay on slush (ignoring everything else) until 11%. hey simonk83, it's an issue default scheduler has, someone will surely implement the "stick with slush" function in time because it seems to be a good ideea edit: @ed64, agree with you, seen it in ryo's and liked it allot, I would definitely like to see it some day implemented
|
BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
August 09, 2011, 01:04:27 AM |
|
Ok i havent done the math but lets say WE got 1 supper slow, and 3 fast pools.
I'll have to think about this for a while so I can answer in a non-math way. Actually, given the number of people using slicing, I might spend a bit of time on it, and write something substantial up. In short, pool hash speed only affect the number of shares you get and their value, not efficiency. The problem with slow pools isn't that they pay less, but that you put more eggs in one basket and if the round goes long you lose much more. But if the round is short, you gain much more. But tell me: have you plotted your daily efficiency over time? Say, daily shares and daily earnings over two weeks? Let me make a prediction: I bet you 1 bitcoin that oldDefaultScheduler will approach the theoretical maximum for the number of pools you use, but slicers will not. Reason: Since variation due to pool luck is reduced, the short term efficiency might seem better than oldDefaultScheduler. But for two weeks of one compared to the other and the same shares submitted per day (and taking any difficulty changes into account) oDS will come out ahead since it will have more early shares than the slicer.
|
|
|
|
c00w (OP)
|
|
August 09, 2011, 01:23:38 AM |
|
Deepbit Hopping is finally working for the default slice scheduler. I'm going to add in an estimation function and then get it working for the old scheduler since it looks like that might be a better scheduler.
|
1HEmzeuVEKxBQkEenysV1yM8oAddQ4o2TX
|
|
|
simonk83
|
|
August 09, 2011, 01:30:28 AM |
|
Deepbit Hopping is finally working for the default slice scheduler. I'm going to add in an estimation function and then get it working for the old scheduler since it looks like that might be a better scheduler.
Cool. Can anyone give me (and plenty others I'm sure ) a quick rundown on how to get this working? Something about enabling every pool (even ones you don't use) and setting them all to info?
|
|
|
|
bb
Member
Offline
Activity: 84
Merit: 10
|
|
August 09, 2011, 01:31:20 AM |
|
Hope everybody was on MtRed.
|
|
|
|
c00w (OP)
|
|
August 09, 2011, 01:34:34 AM |
|
Um. Enable everything which produces valid share counts. If in doubt: don't. Then add deepbit with role:mine_deepbit in user.cfg.
Then start bitHopper with --startLP. Soon that option will be by default once I get the deepbit share estimator working.
If any errors appear: Tell me.
|
1HEmzeuVEKxBQkEenysV1yM8oAddQ4o2TX
|
|
|
simonk83
|
|
August 09, 2011, 01:36:45 AM |
|
Um. Enable everything which produces valid share counts.
Right, I might need a list of which work Maybe I'll wait until it's more defaulterised
|
|
|
|
joulesbeef
Sr. Member
Offline
Activity: 476
Merit: 250
moOo
|
|
August 09, 2011, 01:40:38 AM Last edit: August 09, 2011, 01:57:11 AM by joulesbeef |
|
The problem with slow pools isn't that they pay less, but that you put more eggs in one basket and if the round goes long you lose much more. But if the round is short, you gain much more. true but in my example, their 100% was 20 days, i dont doubt in the long run it works out, but it could be several months before a short round. If they had a 600% block for the first one, it would be 4 months waiting on that short round to make it all worth it. But tell me: have you plotted your daily efficiency over time? Say, daily shares and daily earnings over two weeks? Let me make a prediction: I bet you 1 bitcoin that oldDefaultScheduler will approach the theoretical maximum for the number of pools you use, but slicers will not.
Reason: Since variation due to pool luck is reduced, the short term efficiency might seem better than oldDefaultScheduler. But for two weeks of one compared to the other and the same shares submitted per day (and taking any difficulty changes into account) oDS will come out ahead since it will have more early shares than the slicer. nope i havent. I dont 100% disagree with you, but had I not been slicing, i would have been on bloodies for days.. weeks if yall hadnt decided to mine there and so far they havent found a block, in that time others had short rounds. I know it is more complex than that but it sure seems to me like several days would have been wasted.. sure after a year if bloody hits.. if they dont change from prop over that time, or start to delay stats.. i might make up for all that time i wasted. and on that last part 2 slow pools 5% a day.. we start pool one starts at 1% when we start the hopper the pool two at 0% since both pools are at same hash rate we should stay on pool two until pool one finds a block. pool one finds a block at 70%(or really close to 14 days) without slicing.. reward 0 for 2 weeks. with slicing i mined for half of that time it took to get 70%.. each share about 1.42 times average winner slicing. Ok i know what you are saying.. it has been 2 weeks and now i am back on pool one at 0% while pool 2 is going above 70%.. as long as pool one hits a block before passing pool two.. we got mega payday that makes up for the last 2 weeks right? lets see. pool 2 is still having bad luck but after 2 weeks they find a block at 140%.. now after 2 weeks pool one is at 70% and then the admin decides to stop sending out stats, we have no clue when the round ends, we just ahve to wait until we get paid and the admin has decided to delay that so you can use that info to hop. default.. i did pool 2 for 70% last week and pool one for 70 this week.. no pay for pool one.. paid on pool 2 my shares on pool 2 are worth 0.72 average value. slicing i did 70 shares on pool two and 70 on pool one.(35 week one, 35 for week 2.. each). I get the same.. it is a tie.. my shares on pool 2 are worth 0.72 one month average.. slice wins . ( the guy messing with stats has no baring on anything except to end the game. I think i showed the need to reduce variance in the first two weeks.. but since we are quitting this pool our future payout will be the exact same.. this leaves us with the last prop pool as everyone as gone anti hopping.. slice wins for all time) yeah I am doing extremes.. and yeah I can see it will still work out over time, but time isnt certain in the bitcoin world and it is pretty damn uncertain in the hopper world. I'd like to see some more graphs and math before i am sold.
|
mooo for rent
|
|
|
paraipan
In memoriam
Legendary
Offline
Activity: 924
Merit: 1004
Firstbits: 1pirata
|
|
August 09, 2011, 01:53:31 AM |
|
@c00w just happened to see this in log 2011-08-09 03:33:22+0200 [HTTP11ClientProtocol,client] New Block: d8f14ee933cee60c1ab4d1232f4c60b3c9451a3a0bc43f9b0000080e00000000 2011-08-09 03:33:22+0200 [HTTP11ClientProtocol,client] Block Owner triple 2011-08-09 03:33:22+0200 [-] LP Call eu1.triplemining.com:8344/LP it's for real ? or just a guess
|
BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
August 09, 2011, 02:02:08 AM Last edit: August 09, 2011, 02:23:29 AM by organofcorti |
|
@joulesbeef: ok, if you're going to use extremes of pool speed or hashrate , sure. Variance will kill you and long term becomes months rather than weeks or days. But then over the *very* long term, oDS will still win over slice. Choosing larger pools (~50Ghps and above) is a simpler and more efficient was of reducing variance. Yes - the more pools the better - but the efficiency loss due to having to use slice to reduce variance might be an issue. Edit: Also don't forget you wouldn't have only been mining on bloody's the whole time, only when it had fewer total shares than any other pool. Mining on a small pool is risky, so your is to increase risk to get more pools and possibly a better payout. But because of the increased risk you need slicing to reduce variance, which also reduces payout. I'd like to see some more graphs and math before i am sold. and I'd like to make some chartporn for you (you know you want it...) but I really don't know how to model slice until until someone explains exactly how it works inmining on a small pool all circumstances. PM me if you have something I can use (ie a decision tree, flowchart or some other human language algo) and not just the actual code.
|
|
|
|
simonk83
|
|
August 09, 2011, 02:16:47 AM |
|
Oops, just saw loads (more than I manage to capture) of this as my miners went idle: [12:15:11] RPC request [getwork] submitted to PolMine.pl [12:15:11] RPC request [getwork] submitted to PolMine.pl [12:15:11] RPC request [getwork] submitted to PolMine.pl [12:15:11] RPC request [getwork] submitted to PolMine.pl [12:15:12] RPC request [getwork] submitted to PolMine.pl [12:15:12] RPC request [getwork] submitted to PolMine.pl [12:15:13] RPC request [getwork] submitted to PolMine.pl [12:15:13] RPC request [getwork] submitted to PolMine.pl [12:15:14] RPC request [getwork] submitted to PolMine.pl [12:15:14] RPC request [getwork] submitted to PolMine.pl [12:15:15] RPC request [getwork] submitted to PolMine.pl [12:15:15] RPC request [getwork] submitted to PolMine.pl [12:15:15] triple: 858469 [12:15:15] RPC request [getwork] submitted to PolMine.pl [12:15:15] RPC request [getwork] submitted to PolMine.pl [12:15:16] RPC request [getwork] submitted to PolMine.pl [12:15:16] RPC request [getwork] submitted to PolMine.pl [12:15:17] RPC request [getwork] submitted to PolMine.pl [12:15:17] RPC request [getwork] submitted to PolMine.pl [12:15:18] RPC request [getwork] submitted to PolMine.pl [12:15:18] RPC request [getwork] submitted to PolMine.pl [12:15:19] RPC request [getwork] submitted to PolMine.pl [12:15:19] RPC request [getwork] submitted to PolMine.pl [12:15:19] RPC request [getwork] submitted to PolMine.pl [12:15:19] RPC request [getwork] submitted to PolMine.pl [12:15:20] RPC request [getwork] submitted to PolMine.pl [12:15:20] RPC request [getwork] submitted to PolMine.pl [12:15:21] RPC request [getwork] submitted to PolMine.pl [12:15:21] RPC request [getwork] submitted to PolMine.pl [12:15:21] slush: 2500803 [12:15:22] RPC request [getwork] submitted to PolMine.pl [12:15:22] RPC request [getwork] submitted to PolMine.pl [12:15:23] RPC request [getwork] submitted to PolMine.pl [12:15:23] RPC request [getwork] submitted to PolMine.pl [12:15:23] RPC request [getwork] submitted to PolMine.pl [12:15:23] RPC request [getwork] submitted to PolMine.pl [12:15:24] mtred: 264683 [12:15:25] Error in pool api for itzod [12:15:25] RPC request [getwork] submitted to PolMine.pl [12:15:25] RPC request [getwork] submitted to PolMine.pl [12:15:26] RPC request [getwork] submitted to PolMine.pl [12:15:26] RPC request [getwork] submitted to PolMine.pl [12:15:27] RPC request [getwork] submitted to PolMine.pl [12:15:27] RPC request [getwork] submitted to PolMine.pl [12:15:28] RPC request [getwork] submitted to PolMine.pl [12:15:28] RPC request [getwork] submitted to PolMine.pl [12:15:28] RPC request [getwork] submitted to PolMine.pl [12:15:28] RPC request [getwork] submitted to PolMine.pl [12:15:29] RPC request [getwork] submitted to PolMine.pl [12:15:29] RPC request [getwork] submitted to PolMine.pl [12:15:30] RPC request [getwork] submitted to PolMine.pl [12:15:30] RPC request [getwork] submitted to PolMine.pl [12:15:31] RPC request [getwork] submitted to PolMine.pl [12:15:31] RPC request [getwork] submitted to PolMine.pl [12:15:32] RPC request [getwork] submitted to PolMine.pl [12:15:32] RPC request [getwork] submitted to PolMine.pl [12:15:32] Server change to mtred Followed straight after by: [12:16:14] RPC request [getwork] submitted to BTCServ.net [12:16:16] RPC request [04130000] submitted to OzCo.in [12:16:20] RPC request [getwork] submitted to BTCServ.net [12:16:21] RPC request [getwork] submitted to BTCServ.net [12:16:22] RPC request [getwork] submitted to BTCServ.net [12:16:22] RPC request [0d9c5000] submitted to OzCo.in [12:16:22] triple: 859632 [12:16:22] bitp: 1214343 [12:16:22] RPC request [getwork] submitted to BTCServ.net [12:16:23] RPC request [getwork] submitted to BTCServ.net [12:16:23] RPC request [getwork] submitted to BTCServ.net [12:16:24] RPC request [getwork] submitted to BTCServ.net [12:16:24] RPC request [getwork] submitted to BTCServ.net [12:16:24] bcpool: 2539522 [12:16:24] RPC request [getwork] submitted to BTCServ.net [12:16:25] RPC request [getwork] submitted to BTCServ.net [12:16:25] RPC request [getwork] submitted to BTCServ.net [12:16:25] RPC request [getwork] submitted to BTCServ.net [12:16:26] slush: 2525203 [12:16:26] RPC request [getwork] submitted to BTCServ.net [12:16:26] RPC request [getwork] submitted to BTCServ.net [12:16:27] RPC request [getwork] submitted to BTCServ.net [12:16:27] RPC request [getwork] submitted to BTCServ.net [12:16:27] RPC request [getwork] submitted to BTCServ.net [12:16:27] RPC request [getwork] submitted to BTCServ.net [12:16:28] Error in pool api for itzod [12:16:28] RPC request [getwork] submitted to BTCServ.net [12:16:28] RPC request [getwork] submitted to BTCServ.net [12:16:29] RPC request [getwork] submitted to BTCServ.net [12:16:29] RPC request [getwork] submitted to BTCServ.net [12:16:30] RPC request [getwork] submitted to BTCServ.net [12:16:30] RPC request [getwork] submitted to BTCServ.net [12:16:30] RPC request [getwork] submitted to BTCServ.net [12:16:30] RPC request [getwork] submitted to BTCServ.net [12:16:31] RPC request [getwork] submitted to BTCServ.net [12:16:31] RPC request [getwork] submitted to BTCServ.net [12:16:32] RPC request [getwork] submitted to BTCServ.net [12:16:32] RPC request [getwork] submitted to BTCServ.net [12:16:33] RPC request [getwork] submitted to BTCServ.net [12:16:33] RPC request [getwork] submitted to BTCServ.net [12:16:33] RPC request [getwork] submitted to BTCServ.net [12:16:33] RPC request [getwork] submitted to BTCServ.net [12:16:34] RPC request [getwork] submitted to BTCServ.net [12:16:34] RPC request [getwork] submitted to BTCServ.net [12:16:35] RPC request [getwork] submitted to BTCServ.net [12:16:35] RPC request [getwork] submitted to BTCServ.net [12:16:36] RPC request [getwork] submitted to BTCServ.net [12:16:36] RPC request [getwork] submitted to BTCServ.net [12:16:36] RPC request [getwork] submitted to BTCServ.net [12:16:36] RPC request [getwork] submitted to BTCServ.net [12:16:37] RPC request [getwork] submitted to BTCServ.net [12:16:37] RPC request [getwork] submitted to BTCServ.net [12:16:38] RPC request [getwork] submitted to BTCServ.net [12:16:38] RPC request [getwork] submitted to BTCServ.net [12:16:38] btcserv: 120273 [12:16:39] RPC request [getwork] submitted to BTCServ.net [12:16:39] RPC request [getwork] submitted to BTCServ.net [12:16:39] RPC request [getwork] submitted to BTCServ.net [12:16:39] RPC request [getwork] submitted to BTCServ.net [12:16:40] RPC request [getwork] submitted to BTCServ.net [12:16:40] RPC request [getwork] submitted to BTCServ.net [12:16:40] btcmonkey: 3516104 [12:16:41] RPC request [getwork] submitted to BTCServ.net [12:16:41] RPC request [getwork] submitted to BTCServ.net [12:16:42] RPC request [getwork] submitted to BTCServ.net [12:16:42] RPC request [getwork] submitted to BTCServ.net
|
|
|
|
bb
Member
Offline
Activity: 84
Merit: 10
|
|
August 09, 2011, 02:21:05 AM Last edit: August 09, 2011, 03:08:27 AM by bb |
|
Hope everybody was on MtRed. Same goes for ozcoin I guess. Btw, do we actually know if the 10% slush mining will work out?
|
|
|
|
paraipan
In memoriam
Legendary
Offline
Activity: 924
Merit: 1004
Firstbits: 1pirata
|
|
August 09, 2011, 02:26:30 AM |
|
@simonk83 happened to me a moment ago with mt.red , just deleted the log thinking it's a connection prob with them, seems like it happens with a server it chosen by bH, please run it with if you dont mind
|
BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
|
|
|
|