Topic: bit pit - (LP, ESMPPS, 8-decimal payout, SSL, API, 0% fee, Almost 0% Stales!) - page 14. (Read 80771 times)

I use GUIMiner (2011-07-01 version) with poclbm kernel.
Two of my workers connects to the internet directly from the first computer, and two another connects via shared internet connection from another computer (I don't have a router, but have 2 LAN in my first computer). Perhaps, problem in it? Can you tell me the numbers (or labels) of my workers with no longpolling?

Thanks!


Lol, you beat me to it  

SMPPS is like PPS in that we'd offer a price per share. Unlike PPS, we'd have to wait until the round is complete (and the block has 120 confirmations) before payouts are made for shares.

One of the major downsides to PPS is that a really long round could eat into a pool operators reserve funds, and could possibly bankrupt a pool if either it was extremely unlikely or if someone attracted PPS via block withholding.

SMPPS avoids this downside due to it being "Shared Maximum", or in other words, if the total price of all pending shares exceeds the block income the pool operator pays out proportional to the funds that are available.

luke-jr wrote some pesudo code for how the payout scheme works here: http://eligius.st/wiki/index.php/Shared_Maximum_PPS

For readability, what luke-jr said was:


During short rounds you will get paid less than proportional. In fact, during really short rounds the payout will be less than the block's 50 BTC. However, the excess is not something that the pool operator pockets. What the pool operator does, is move that into "available funds". Now, when a round goes long the pool operator will dip into the available funds to try and keep the per share price at the fixed and advertised price. If the available funds cannot suffice, total available funds are payout proportionally.

Now, since variance averages out over time, the available funds bucket will fluctuate up and down, but ultimately have a net of 0.

Remember our 8 million share round? In a proportional payout scheme, we all worked harder but got paid "less".

However, the two rounds before out 8 million share death round were very lucky. Had we been using SMPPS those two lucky rounds would have esthablished a reserve for us all, so that during out 8 million share round we can all get paid more proportionally to the time the block took to solve.

+1 from my side.

http://eligius.st/wiki/index.php/Shared_Maximum_PPS

How does SMPPS work exactly?

Indeed, that is why I'm very much inclined to like SMPPS....

But, I've yet to hear a direct yes or no from anyone regarding such a change.

Its bad because the non-pool-hoopers do the ungrateful work while it is being payed the same as the other work, while the pool-hoopers get the rewards from quicker finds of other mining pools. Pool-hooping is profitable unless the pool stablishes some time of anti-hooping mechanism, like rewarding more the late shares.

I know is tempting to not discourage pool hooping because you get more Hash/s rate for a while, but I think it also discourages the "legal" miners that feel they are being cheated.

i guess 20% of the pool are the hoppers. do you think it is bad?
or good since we have the possibility to find a block during their "visit"?

Yes, the most recent drop in hash rate may have be due to pool hoppers leaving. We did pass the 600K share mark.

pool hopping? the point in time (about 0.4*difficulty) fits.

just want to clarify - abuse by pool hoppers (especially with prop/realtimestats) is not a question of faith. it's mathematically provable. for a good explanation, read this: http://forum.bitcoin.org/index.php?topic=24966.0

Okay. Then the only reasonable explanation is that I have forgotten to add some flags, will check this later today. However, if I use the same settings as on other pools, I'll contact you with more details about the problem.

Thanks for the fast replies.

What is with the big swings in the pool total hash rate today? In the lat hour or so I have seen it in the from 100Mh/s to 70Mh/s.

I just got done looking over our logs, and I do see a lot of stale shares coming from your works.

For example:



If you could tell me what miner you use, and what version you have that would be helpful. From our longpool logs it appears that you only have 2 open longpool connections, but four miners. Also, this rapid stales, like the above, indicates that either you don't have a longpool connection open or that we were not successful in getting you the LP getwork soon enough.

Also, on issues like this, for everyone I'd be curious to know what your ping response time to pool.bitp.it is. Network latence will play a small roll, and I figured it probably best to get as much info as possible 

Thanks all!

Ok, I apologize. I thought you were referring to the hash rate estimation we display on our website.

Yes, you are correct, your miner will always display your "true" hash rate. And that shouldn't vary between pools unless your miner is idling a lot. I'm not sure about all the various mining software, but I know phoenix very noticeably says when it's idling.

If you are using the same flags, and you are not seeing any warnings about an empty queue or idle miner, let me know what mining app (and version if known) you are using. Also, your OS might be helpful too.

If all the settings do turn out to be the same on your end, I must say, this would be a first for me. But, I don't want to rule anything out either. 

Okay, thanks for the clarification, but I was under the impression that my client always shows the right hashrate, no? I'm not comparing the stats on different pool's sites, just on my own client. I'll need to double check that I use the same flags and options for your pools as I use on other pools when I get home.

Thanks, we will also look into yours and see if there is a correlation. However, if you had only just experienced them at apprometly the time you posted that message, just for note, we were fighting off a series of fake getwork submissions and were fiddling with out incoming traffic filters.



Thanks!

As for the hash rate on our site. Just like Deepbit or BTC Guild, the hash rate we display is simply an estimate and doesn't play a part in your earnings. Different pools are going to use different algorithms for estimating your estimated hash rate, add in some variance, and then you have a recipe for seeing different estimates no matter which pool you view.

However, I can tell you that our pool looks at your last N share submissions and calculates your hash rate based off of that. So, if you are just starting mining with us, or if there was a gap in your mining (eg, stopped your mining software to reconfigure it, etc), then your estimated hash rate will be a lot lower. After a few shares are submitted this will level out and IMHO start to show you a pretty good estimate of your hash rate.

I like the pool but my hashrate is lower here than on other pools. When I mine at BTC-Guild or Deepbit I have appr. 270Mhash, but on this pool I have 220-230. What's that all about?

I confirm that, I have the same problem.

I'm just catching up on the conversations from today. Good discussions everyone.

For what it's worth, I am not a fan of scoring systems. I hear those concerns echoed by others as well.

I am not opposed to proportional either, obviously or we wouldn't have switch to it 

I do see both sides to the pool hoppers argument, and am sensitive to both sides. On one hand they do provide real work, and as we've seen today we solved a couple of blocks under difficulty, so they (on average) will get us about half way to a block. However, I am also sensitive to the idea that during long rounds, their early efforts are not nearly as meaningful but they still walk away with some of the profits.

I completely understand both view points. I also like the idea that proportional is very simple to explain, virtually everybody does (or can easily) understand the proportional payout scheme. I've tried explaining the Meni Rosenfeld method, and it is not something that is very intuitive.

Not saying I'm opposed to other schemes, but given what I do know about the various reward schemes I'm inclined to prefer either proportional or SMPPS.

The attractive aspects of SMPPS is that it's somewhat easy to explain, not nearly as easy to explain as Prop. but still pretty simple. I also like it because it helps reward everyone of their disproportional amount of work during a long round. And, unlike scoring, does not penalize someone who might have to, legitimately, leave a round early (think power outage, internet failure, etc).

Either way, those are just my thoughts. I figured it might help the conversation if I said what my feelings on the matter were.

Here is a pretty good comparison: http://eligius.st/~luke-jr/samples/800MH/

Good job everyone, we had some good growth and luck today!