Grinder (OP)
Legendary
Offline
Activity: 1284
Merit: 1001
|
|
July 28, 2011, 10:53:33 PM |
|
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
|
|
|
|
MrWizard
|
|
July 28, 2011, 11:28:12 PM |
|
Very nice post. Thank you!
|
"I walked into the room dripping in Bitcoins. Yea dripping in Bitcoins." (BTC) 168DCCeGmDy3xTWRimLVhvKtK3yEWbpsSg (LTC) LbYS8VFqFSU7B9bfaHD11seQMtrtYEKpLe (BBQ) bNVZErvwLzpEG7H3kt1fycWspzRQB1MJzL
|
|
|
|
JoelKatz
Legendary
Offline
Activity: 1596
Merit: 1012
Democracy is vulnerable to a 51% attack.
|
|
July 29, 2011, 12:55:01 AM |
|
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.)
|
I am an employee of Ripple. Follow me on Twitter @JoelKatz 1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
|
|
|
|
Grinder (OP)
Legendary
Offline
Activity: 1284
Merit: 1001
|
|
July 30, 2011, 08:15:49 PM |
|
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.
|
|
|
|
chaud
Newbie
Offline
Activity: 17
Merit: 0
|
|
July 31, 2011, 08:41:30 PM |
|
Is your mtred data from the main server or the beta?
|
|
|
|
Grinder (OP)
Legendary
Offline
Activity: 1284
Merit: 1001
|
|
August 01, 2011, 08:07:26 AM |
|
|
|
|
|
BurningToad
|
|
August 02, 2011, 12:33:51 PM |
|
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?
|
|
|
|
zx9r
|
|
August 02, 2011, 12:47:18 PM |
|
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.)
Is this delay intended for something ?
|
|
|
|
iopq
|
|
August 02, 2011, 03:46:56 PM |
|
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.)
Is this delay intended for something ? to play fanfare.wav
|
|
|
|
Xephan
Newbie
Offline
Activity: 42
Merit: 0
|
|
August 02, 2011, 04:36:29 PM |
|
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.
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.
|
|
|
|
JoelKatz
Legendary
Offline
Activity: 1596
Merit: 1012
Democracy is vulnerable to a 51% attack.
|
|
August 02, 2011, 04:39:21 PM |
|
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.)
Is this delay intended for something ? to play fanfare.wav ROFL! I have no idea what the delay was for -- I can only guess.
|
I am an employee of Ripple. Follow me on Twitter @JoelKatz 1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
|
|
|
zx9r
|
|
August 02, 2011, 04:44:29 PM |
|
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.)
Is this delay intended for something ? to play fanfare.wav LOL
|
|
|
|
Grinder (OP)
Legendary
Offline
Activity: 1284
Merit: 1001
|
|
August 03, 2011, 09:27:23 AM |
|
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?
It is measured from Europe. The ping time to European servers is about 40-60 ms, and to uscentral.btcguild.com 142 ms. note: pool hashrates varies a bit so the hashrate proportions are +/- making it pretty much the same blocks per MH for the 3 pools. 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.
|
|
|
|
|