Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 201. (Read 499491 times)
August 04, 2011, 01:50:06 PM
yay! now that time frame is more like it =)
August 04, 2011, 01:45:43 PM
aaaand new block solved! 
August 03, 2011, 03:55:38 PM
woot woot! about freakin time LOL....block found/solved =)
My gosh, I love CGminer...only 1.2% stale shares woot! I was using guiminer previously and on this pool it was doin avg of 5-8% stale shares.
My gosh, I love CGminer...only 1.2% stale shares woot! I was using guiminer previously and on this pool it was doin avg of 5-8% stale shares.
August 03, 2011, 02:34:21 AM
Although being able to do it midround might be kind of interesting. What type of rescaling would be needed? All share rescale or a current score rescale going forward?
You could just update future shares. But let's not make it too complicated. 
August 03, 2011, 01:08:43 AM
I mean that I can adjust it without having to bring the getwork server down and it will poll for a new setting without me having to poke at it. I hadn't really planned on doing it mid round, since it would be hard to tell a hopper from someone just dropping out for various reasons. Although being able to do it midround might be kind of interesting. What type of rescaling would be needed? All share rescale or a current score rescale going forward?
GenTarkin: Difficulty went up again last block, so it's going to take longer on average for blocks. We are still running under the difficulty for this block and have been having pretty good luck lately as far as that goes.
GenTarkin: Difficulty went up again last block, so it's going to take longer on average for blocks. We are still running under the difficulty for this block and have been having pretty good luck lately as far as that goes.
August 02, 2011, 11:56:22 PM
Ok, should be settled down now and ready to move forward. Decay time has been modified to be less harsh and I can now play with it in real time as the hashrate changes or pool hoppers get uppity.
Not sure what you mean by "real time", but it's not designed to allow the parameters to change mid-round (though it should be possible with the proper rescaling). You should only change them between rounds (ie, do a change that will take effect starting with the next round). August 02, 2011, 10:42:26 PM
Cool, its no prob if you go down...CGminer is failing over to my 2ndary pool just great =) hahaha....love CGminer!
Glad to hear it wont be so harsh....
I just want to solve another block dangit...this one is going on over a day as well =P boohoo!
Glad to hear it wont be so harsh....
I just want to solve another block dangit...this one is going on over a day as well =P boohoo!
August 02, 2011, 09:56:36 PM
Ok, should be settled down now and ready to move forward. Decay time has been modified to be less harsh and I can now play with it in real time as the hashrate changes or pool hoppers get uppity.
August 02, 2011, 09:47:38 PM
Gotta do to more field updates, but they won't take as long.
August 02, 2011, 09:42:39 PM
Sounds like you're using myisam.
August 02, 2011, 09:24:33 PM
It only took about 20 minutes... there wasn't a choice, the pool was up and so was the site, but mysql likes to lock the table and hold all requests when you do a mass delete. Probably should have gone with pgsql but too late now.
August 02, 2011, 09:00:37 PM
I guess it's faster to pause the pool for an hour to do it?? Pool is down for 15min now.. site working tho..
August 02, 2011, 08:56:05 PM
Sorry guys, I am cleaning up the shares database and increasing the decay time (and making it dynamic for future use) and it's taking a really long time to clean up 10 million + shares. Hooray for MySQL's idiotic table locking logic.
August 02, 2011, 06:55:37 PM
dangit...we need to solve a block already, its been like under one block a day for the last 5 days =( lol
August 02, 2011, 06:14:22 PM
I would agree, keep the % above the top of block stats..
August 02, 2011, 05:45:48 PM
Top of Block Stats? Thats where deepbit has it...I think. Well, in an area similar to it. Is there a luck % for each block too that can be recorded historically as another field in stats? Then a rolling "current" luck %? like above block stats....that was kinda my thinkin...
August 02, 2011, 05:28:11 PM
Yep, it's pretty much the next thing on my list. I actually haven't done it yet because I can't figure out the best place to put it... I know it's kind of a silly excuse, but putting it in quick stats has it's problems (not least of which is formatting) and putting it in the block stats makes it kind of hidden.
If you have a suggestion on placement/format, I'm all ears.
If you have a suggestion on placement/format, I'm all ears.
August 02, 2011, 05:25:18 PM
grr another long block ... lol... hows the PPS stuff comin inaba? =)
I think I've come up with a good solution, but it's fairly complicated. I need to complete a tenative design and I'll roll out a test server once I have something concrete in place.
Sweet! Oh, I was wondering, can you impliment a luck % somewhere kinda like deepbit has? I dont know how to figure luck and I liked seeing the stat.
August 02, 2011, 11:18:21 AM
grr another long block ... lol... hows the PPS stuff comin inaba? =)
I think I've come up with a good solution, but it's fairly complicated. I need to complete a tenative design and I'll roll out a test server once I have something concrete in place.
August 02, 2011, 11:17:18 AM
I do not know much about your backend, but it sounds like we are two entirely different architectures. On my pool we use Redis (a no-SQL datastore) and Node.js. Additionally we have a single "getwork server". So, since Redis stores everything in memory anyway, we were able to really quickly re-perform the scoring algorithm on every share submission. Unless you centralize your share data in someplace other than SQL, I do not think our solution will be easy for you.
Hmm, I'm not familiar with Redis - so are you saying you have direct access to the memory that your getwork backend is using from your webserver to gather those statistics? That's mighty handy if so.
Quote
I am curious, why do you have multiple servers? Is it to allow for users to be closer to a server (e.g., geographic distribution), or are you doing this for performance reasons? If at all possible try and consolidate your getworks to a single server, and I think that will open up more possibilities to you.
I could easily consolidate to a single server, but you are correct in your geographical assumption. There is simply no way to run an efficient server over oceanic links, the latency is to great. Western Europe is at the very limit of acceptability, often falling into unacceptable latency, anything further east and it becomes untenable. Thus multiple servers.
Quote
I am not aware of any single post that fully describes ESMPPS, unfortunately. I'd love to write one, but I've just been pretty swamped lately.
In this scenario, you will eventually reach a future where no bucket is paid past the 98.5% bucket. However, unlike *MPPS systems old and new shares are paid immediately up to the 98.5% range. This underpayment is remembered by the system, and if the buffer goes positive, the backpay is made up. Interestingly enough, even in this scenario the ESMPPS pool still behaves "normal" and outperforms any true PPS pool, provided that true PPS pool charges more than a 1.5% fee.
IMHO it's a pretty interesting dynamic, a pool that "self regulates" itself. This is, ideally, what a true PPS pool tries to accomplish when the pool operator charges a fee. However, in the case of ESMPPS it set by the probabilities of the situation itself, and if the situation takes a turn for the better then everybody wins. If the situation stays the same, it still outperforms true PPS.
In this scenario, you will eventually reach a future where no bucket is paid past the 98.5% bucket. However, unlike *MPPS systems old and new shares are paid immediately up to the 98.5% range. This underpayment is remembered by the system, and if the buffer goes positive, the backpay is made up. Interestingly enough, even in this scenario the ESMPPS pool still behaves "normal" and outperforms any true PPS pool, provided that true PPS pool charges more than a 1.5% fee.
IMHO it's a pretty interesting dynamic, a pool that "self regulates" itself. This is, ideally, what a true PPS pool tries to accomplish when the pool operator charges a fee. However, in the case of ESMPPS it set by the probabilities of the situation itself, and if the situation takes a turn for the better then everybody wins. If the situation stays the same, it still outperforms true PPS.
Let me know if you do write something more definitive on it, I would be very interested in it. Have you done any analysis on the timeframe for a pool to self regulate? It seems that it might take a very long time to reach a steady state if you have a particularly bad run of blocks without a balancing good run extreme swing. I can see how it would outperform a pure PPS, certainly, but it seems theres a lot of risk to the users, or operator if the operator wishes to shoulder that burden by paying out into the negative.
Jump to: