organofcorti, your problem is that you're assuming that the actual expected round length is supposed to be 1.0281 D. Instead, assume that it's 1.0 D. What is the probability that the measured round lengths would average to 1.0281 D by chance?

You'd like to assume the population mean to be 1xD and estimate the probability of the round lengths averaging to 1.0281? Using a similar technique to that described earlier (using code similar to this) we get a probability of 0.8801 rounds being less than 1.0281, giving a probability of rounds being 1.0281 or longer at 1-0.8801=0.1199. This is even worse than the estimate I provided earlier.

My statistics are a little rusty, but isn't that result not statistically significant?

i don't think we're testing a hypothesis here. it's just a probability.

yes, it's just based on the cdf.

Quote

...unless organofcorti wants to do a series of real-time test with a similar sized prop pool.

Can't do that either. If we assume the population mean is 1.0*D, we have to assume the distribution is similar to the Bitclockers.com distribution. Can't compare a geometrically distributed round with a bitclockers.com round - they aren't similar.

Sorry guys, I was wrong in both cases. I forgot that using the CLT a) it doesn't matter what distributions the means are from and b you can assume normality so you could consider it a non-significant p-value. It still stands as a probability though, and 0.1316 is still low.

Due to the presence of strategic miners, full time miners can expect to earn only 94% of expected round earnings,not 97% (including fee).

This loss in income means that it actually takes over 30 days (at current pool hashrate) for fulltime proportional miners to be confident of earning the same as or more than PPS miners, rather than 11 days without strategic miners present.

Interesting read Organ. I do wonder if perhaps you are not misinterpreting the data; when a round starts, you get fresh work. Even assuming zero delay from the pool, and zero network latency, only the fastest miners are going to be able to submit shares within seconds. Slower miners may take up to a minute or more before they submit their first share.

I wonder if that by itself couldnt cause both the drop at the beginning of the round, and the slow spike afterwards. After all, deepbit rounds are very short, and I wouldnt be surprised there a lot of slow and clueless miners on there.

As for the poll:

Bitclockers.com - 2 (0.6%)

Will the one person besides the pool admin who voted for bitclockers please stand up?

Interesting read Organ. I do wonder if perhaps you are not misinterpreting the data; when a round starts, you get fresh work. Even assuming zero delay from the pool, and zero network latency, only the fastest miners are going to be able to submit shares within seconds. Slower miners may take up to a minute or more before they submit their first share.

I wonder if that by itself couldnt cause both the drop at the beginning of the round, and the slow spike afterwards. After all, deepbit rounds are very short, and I wouldnt be surprised there a lot of slow and clueless miners on there.

No, I can see how you'd think that, but a group of poisson distributed variables with different means is still a poisson distributed variable with a new mean of arrivals per unit time that is the sum of the of the constituent mean arrivals per unit time.

Think of it this way. 10 miners with 1 Ghps will submit about 2.3 shares per second on average. So will one miner with 10Ghps.

The only thing I can put the slow hashrate increase from below normal is variable time to receive a long poll notice. Until such notice is received, any shares that are sent will be stale. Then there's the time taken for the trip back, which may not be the same as the trip there, due to variable servers on the way.

A log-normal distribution is a good fit for a combination of normally distributed variables that have a multiplicative effect on each other, so I chose it as a starting point for the model. It turned out to model that response pretty well. It's only the mean of ~ 0.7 seconds and deviation of ~1.7 seconds that I can't interpret.

Below is a bubble plot showing votes on the y axis and bubble size showing hashrate.

It seems that small pools vary significantly from the minimum to the maximum of the vote, and the larger pool are in the mid range. To try to account for hashrate, I divided all votes by the log of the hashrate to get a 'trust index'. I used log(hashrate) to try to account for the fact that novice miners that might not know much about trust tend to gravitate to larger pools first.

p2Pool is the clear winner, followed by EMC and Ozcoin. Well done to all in the top three pools - you've gained significantly more trust in the community than others.

Proviso: although data is accurate, it probably is not very reliable. It's self selecting: mostly english speakers and only those concerned about trust in pools. Further, sample size is small and voters could vote more than once which skew results further.