Bitcoin Forum

I have analysed how fast the largest pools take to send a long poll notification on new blocks. These are the numbers in seconds:
server         first tot. delay  tot.delay
deepbit          74  191   1.86    1.14
bitcoinslc       95  190   2.81    1.40
bitclockers       9  190   4.03    3.84
btcmine           4  190   4.23    4.14
btcguild         10  191   6.64    6.29
mtred             0  130   9.92    9.92
eligius           0  189  12.36   12.36
192 rounds

"first" - the number of times the pool was the first to announce the block
"tot." - total number of rounds that server has data for
"delay" - average delay on the blocks it was not the first to announce
"tot.delay" - average delay for all rounds where the server has data

Deepbit and Bitcoins.lc are very good, while Eligius lags far behind. The stats are particularly impressive for bclc, because they announce other pools blocks before the pool that solved it almost 50% of the time. Deepbit announce about 50/50 of their own and other pools blocks first.

Lag means wasted hashing which the miner usually have pay for one way or another. The exception is when the pool pays for invalid blocks. All other things being equal and with an average of 1 block/10 minutes, this means that mining at bclc will pay 2% more than at Eligius. In reality it will be a bit more, because the difficulty is increasing every time and bclc pays for stale blocks.

The numbers will be slightly skewed by network latency, but except for Deepbit and bclc the differences between the pools are too large for it change the order.


19Mmr8ZsqsQczDS7VWgphPjfgmQG1nru4k

Very nice post.  Thank you!

Cool stats, could you test http://arsbitcoin.com (my pool) for me?  Curious to see how we compare.

The default bitcoin client has a two second delay after solving a block before it will do anything else. Hopefully, all pool operators have removed it. (It's main.cpp line 2921 or so.)

+1

Ars wasn't open for registration when tried the first time, but here are some new numbers that includes them:
server         first tot. delay  tot.delay
deepbit         104  229   1.72    0.94
ars              18  231   1.77    1.64
bitcoinslc       88  233   2.93    1.83
btcmine           6  232   2.94    2.86
bitclockers       7  231   3.35    3.25
btcguild         10  230   3.92    3.75
eligius           1  232   6.94    6.91
mtred             0  228   6.92    6.92
234 rounds

Ars is very consistent but seldom first. Average is still very good, though.

Is your mtred data from the main server or the beta?

It's the main server, http://mtred.com:8337/LP.

Cool, thanks Grinder!

I guess one thing to note is that these are the results for your personal connection, correct?  Some may have a better connection to overseas servers like Eligius, etc?

Is this delay intended for something ?

to play fanfare.wav

Doesn't seem to affect the pool's effectiveness (Blocks / Hashrate) though.
For example, despite the latency, since I started tracking about 1400 blocks ago, mtred has got about 28 blocks vs deepbit's 566 or 4.95% blocks with about 4.51% of DB's hashrate.

Similarly eligius is 8.83% with 8.65% of Deepbit's hashrate.

note: pool hashrates varies a bit so the hashrate proportions are +/- making it pretty much the same blocks per MH for the 3 pools.

ROFL! I have no idea what the delay was for -- I can only guess.

LOL

It is measured from Europe. The ping time to European servers is about 40-60 ms, and to uscentral.btcguild.com 142 ms.

Not just a bit. For instance mtred varies between 150 Ghash and 400 Ghash, so I doubt you can use it to check for the 1-2% difference the long poll delay would result in. Even if you could I don't think it would be measurable this way. If the server is updated and it's just not sending the LP it might result in invalid shares which might not be counted when the pool calculates hash rate. If the bitcoind isn't updated it would result in the expected number of blocks, but a larger share of them would become invalid.