Quote from: gyverlb on May 24, 2013, 02:36:08 PM

Quote from: GrapeApe on May 24, 2013, 01:58:36 PM

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets

I did what is stated above to the latest 0.8.2rc2 (sipa changes). I had similar results with the 0.8.2rc1 as well (3.00ms).

Usually I agree to some blockmaxsize and tx fee tuning, but it's going too far here. forrestv suggested that the bitcoind latency doesn't influence your efficiency noticeably and I can confirm that below 0.2s I don't see any meaningful difference (I'm still at 110-115% efficiency).

In fact you may actually hurt your income at this point. Depending on your hashrate you will eventually hit a block and it will pay less to everyone, yourself included. If you only have hundreds of megahashes this doesn't change much for everyone as you probably won't hit a block in the foreseeable future but if you are one of the lucky few with ~100GH/s (there are at least 2 currently according to the payouts) it's 10% of the total p2pool network and nearly 10% of less fees for everyone yourself included. Fees are ~1% of the incomes currently.

This means ~0.1% less income for everyone. If you encourage others to do the same mistake, this is 1% less income for everyone.

My recommendations if you want to tune bitcoind:

compile it from git head like GrapeApe: it has the latest performance enhancements and its default mintxfee and minrelaytxfee values are better for miners (don't touch the source, modifications of constants demonstrated earlier in this thread will only make things more difficult and only touch default values that can now be changed with the mintxfee and minrelaytxfee parameters)
look at your average bitcoind latency as reported by p2pool for at least 24h
if your latency is above 0.1s and only if it is try the following tunings (from first to last) measuring the result for at least 24h each time you apply one of them and stop when you reach <0.1s latency (it will give you some margin if something slows down bitcoind later and avoid its latency raising above 0.2s, you should monitor this value and many others with monitoring software if you value your income anyway):
- give CPU and IO priority to your bitcoind and p2pool processes if your OS allows it (see the guide in my signature, I'll update it soon for Linux examples)
- move the bitcoind and p2pool data directories to SSD storage
- reduce blockmaxsize to 250000 instead of 500000
- raise mintxfee and minrelaytxfee to 0.0005
- if you are still above 0.1s, reapply the measure that had the largest impact on your getblocktemplate latency between the last 2 (blockmaxsize=125000 or mintxfee/minrelaytxfee=0.001 for example)

Note that if you reach the latest steps, you probably have CPU and IO limitations that are hurting your efficiency elsewhere anyway.

If your node is in ideal conditions (very strong CPU and SSD dedicated to bitcoind + P2Pool) and your latency still needs heavy tuning (blocksize < 100000 or fees > 0.001) to reach 0.1s, this is starting to hurt the Bitcoin network (especially if you control large hashrates): you should start discussing it with other p2pool miners to see if it's a general problem worth reporting to the Bitcoin devs.