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.
What if you made it only update on request? In that someone has to physically press a button to update the estimation. That way the queries only have to run when requested, rather than every x minutes? Not sure if that helps 