Quote from: Bitmong on May 30, 2013, 07:48:50 AM

Quote from: Bitmong on May 29, 2013, 12:44:30 AM

Quote from: gyverlb on May 25, 2013, 02:56:44 PM

I don't know the exact reason why getblocktemplate affected efficiency and even if it's still the case today as forrestv might have changed something that removes this problem. It was still the case very recently (like less than 2 months ago) when getblocktemplate took more than 0.2s. I don't check often how it affects p2pool but I'm doing it right now (in fact I'm studying how the block size and fee limits affect getblocktemplate in the current situation, checking the efficiency is just a bonus). If the behavior of p2pool changed I'll know it in the following days and will be able to update my guide. For now I still recommend to keep it under 0.2s to be safe.

Some recent findings on P2Pool efficiency on my node.

My node is directly connected to the Internet with Ethernet, 100 Mbit/s downstream and 10 Mbit/s upstream. The node is a Phenom four-core processor, with SSD disk. I have 7 mining rigs connected to the node via LAN.

All numbers below are with current (April 2013) P2Pool from Github.

When my configuration was incorrect and Bitcoind could only make outgoing connections, my efficiency was between 95% and 99%.

After fixing the configuration problem, efficiency rose to 110-115% level. I have now 30-40 connections to the Bitcoin network.

When the getblocktemplate latency started to appear, my efficiency was still between 110-115%. My getblocktemplate latency was about 30 seconds at that time.

I have now upgraded to the 0.8.2rc3 version, and the getblocktemplate latency decreased to about 0.1 seconds, but it has increased to 0.9 seconds since the upgrade (in four hours).

Current efficiency after two hours from the upgrade is 102.4%. Well, I think one cannot deduce anything from that yet, maybe the stopping and restarting of bitcoind caused some orphans.

I'll report the efficiency back to this thread after 24 hours have passed with this new bitcoind version.

So, now the pool has run for over 24 hours with the new bitcoind version and:

Code:

# default is 500000, 1000000 is the maximum allowed and will fit more transactions (more fees)
blockmaxsize=1000000
#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.00001
# Same but for relaying the tx to our peers
minrelaytxfee=0.00001

settings.

I have found 70 shares now, 7 orphan and 5 dead, for stale rate of 17.1% (10-28% interval). Pool stale rate is 20.4% now, so efficiency is 104% (90-113% interval).

One thing I remembered was that I have downclocked my CPU to 1.2 GHz from the default clock rate of 2.5 GHz or so to save a little CPU. That might affect things a bit. I might check that at some point.

bitcoind getblocklatency is 0.93 seconds now, so it is much better than the 30 seconds earlier. I think the CPU frequency affects this latency the most, and was likely the reason my latency was 30s with the old bitcoind version.

no need to downclock, thats sutpid!