Topic: A guide for mining efficiently on P2Pool, includes FUD repellent and FAQ - page 14. (Read 174901 times)

That's my not-so-secret plan

This is great work, really.

By making clear the advantages and disadvantages of mining at p2Pool, it should attract prospective miners who are geeky and have good network connections but aren't statistically literate.

Thanks, fixed.

Automatic fee (a small tip for forrestv for his great work) is 1% from some time, not 0.5%.
It can be changed (up or down) using --give-author optional parameter.
IE:
--give-author 2
will give 2% of your reward to forrestv

Thank you

Done

Great job! Very informative! Last time I ran p2pool was when I had all gpu miners and BFL FPGA's didnt work. Not sure if thats the case anymore

Can you make cgminer in that sentence a hyperlink?

Added recommendations:

• don't use the node's wallet
• forward the P2P port to your node

Added a FAQ entry on blocksize tuning.

The wallet should not be used at all: p2pool should be started with a payment address to make sure it doesn't pick one from the bitcoin wallet.

The method described runs another bitcoind to maintain an on-disk blockchain up to date.

This is great! Thank you!

If someone tries tmpfs for the data directory, and they lose power, they will lose the blockchain (and wallet). Extra care has to be taken to make sure no important addresses are in that wallet (since p2pool will create one unless you specify another address) and that the blockchain should be backed up to disk to prevent re-downloading every boot.

Note on the post above :

this post was motivated by several questions from new users who often misunderstand P2Pool or get suboptimal performance after misconfiguring some components of a P2Pool mining setup.
There are people spreading FUD and repeating nonsense about P2Pool, I'll try to address some of the urban legends spreading about P2Pool.
Finally P2Pool isn't for everyone, there are configurations and hardware performing poorly with it: they would be better used on traditional pools.

I'm a x86/amd64 Linux user for nearly 20 years now and didn't use Microsoft software for more than 10 years, so tips and advices will have examples for Linux. I'm not sure if P2Pool can perform well with Windows (it depends on the python implementation on it). If Windows admins have experience successfully tuning a Windows P2Pool node, I'll welcome contributions. Experience on other systems are welcome too.

This guide is a work in progress and already quite large, a TL;DR; chapter is at the end of this post for a quick summary.
If you have a good or bad experience with P2Pool to report which brings new useful information, please do report it after reading this whole post to check that your problem or tip isn't already known.

Please stay on topic: this is not about current luck or unsubstantiated feelings of bad behavior from P2Pool as a whole or your node. I am looking for ways to make P2Pool efficient for as many as possible and know that there are configurations performing badly. If unfortunately you are in this case and can't find out why after reading this guide, please report or ask questions. On the other hand if your problem is already described in this guide and you don't have any solution yourself then we are sorry for you but as there's nothing to be done please don't pollute the thread.

Why P2Pool and How?

Introduction to P2Pool: why would you use it?

You can find an introduction and useful information at the P2Pool's page on the Bitcoin Wiki, its forum thread and the Github project page. P2Pool supports Bitcoin/Litecoin/Terracoin mining. Merged mining with other coins is supported too.

P2Pool is an elegant implementation of a distributed pool by forrestv. He truly deserves to be praised and rewarded for his hard work. Hint: look at his signature in the original post of the forum thread for his donation address.

Here's my own description in one of my posts in the forum thread:

Reasons to use P2Pool as your mining pool

• You are in charge.
• No single point of failure in the pool
• It's fun for geeks to learn
• There are small statistical advantages increasing income vs traditional pools

Reasons to avoid P2Pool

• You have to maintain your node (expect some sysadmin work)
• Some hardware simply can't perform well on P2Pool (less likely since July 2013)
• You have to provide the CPU/RAM/Disk/Net capacity P2Pool needs
• Currently P2Pool is between 1 and 1.4 TH/s, this relatively low hashrate means high variance, especially for low hashrate miners

P2pool's advantages for miners looking for better incomes

Fees are optional (1% is going to forrestv unless you disable it) and transactions are paid to miners. On average, if your miners have latencies comparable to the other miners on P2Pool, you should have more income on P2Pool than on any other pool. In fact you should expect as much (or more, see point below) income as you would have solo mining with reduced variance thanks to other P2Pool miners contributing their own hashrate.

P2Pool blocks are quickly broadcasted to the Bitcoin network through all the bitcoind nodes used by the whole P2Pool network. If another pool finds a block at the same time than P2Pool, it probably is at a disadvantage: that's more income for P2Pool on average.

General advices on running P2Pool

Security

Don't use the node's wallet, always configure p2pool to pay an address (use the "-a" parameter) you can secure appropriately (big fat wallets on a public server are not a good idea).

Maintain up-to-date software

• Monitor the P2Pool forum thread to be aware of new developments
• Run the latest code: you can run something like the bash script I run by cron everyday to restart p2pool after updating it when there's a new version available. You'll need to know how to install p2pool from git, create a "pool.sh" script to run your node the way you want and adapt this to your environment (if you can't find out how by yourself after reading P2Pool's README, I wouldn't advise running p2pool)

Tools

• miner: always use a miner able to switch to backup pools. cgminer is my favorite, by default it will detect specific P2Pool error conditions (like a bitcoind crash) when P2Pool starts rejecting shares repeatedly, switching to the backups and saving you income. Use --failover-only to avoid leaking p2pool work to backup pools.
• home router: if your node doesn't have a public IP address, configure your router to forward the 9333 TCP port to your node: it will help you maintain a good connection with the P2P network.
• monitoring: you are hosting a pool now: use sysadmin best practices and monitor your system (send alerts when bitcoind or P2Pool are down, start them automatically when the system boots, monitor the disk space to avoid surprises, ...). You can do some of this with simple hackish scripts but I advise you to learn how to monitor and maintain a server properly (I use Zabbix for monitoring, a combination of init scripts and/or "@reboot" crontab entries for startup with tmux or screen to launch p2pool and miners).

Maximize your income

Tune bitcoind for more income by editing bitcoin.conf:
This will include more fees in the blocks you find, making more income for everyone using P2Pool, including yourself.

Study your income

Don't let your feelings about short bad luck periods cloud your judgment. Compute your expected income according to your hashrate and current difficulty, store it in a spread sheet day by day in a column (don't forget to include your downtimes), add your real income in another column, compute the accumulate theoretical income (the one you would get on a 100% PPS pool) and real one and graph them. This will help you keep a cool head and see how P2Pool really performs for you. I even went a step further and computed my own past luck on 30 and 90-days windows to check the values reported by http://p2pool.info (which by the way was surprisingly accurate, I expected the difference to be greater due to personal variance/downtime/...).

Patience

If you are beginning on P2Pool you should expect irregular payments which can be frustrating. P2Pool is attracting more and more hashrate (from a low 200GH/s in March 2013 to a high 1.4TH/s in July 2013) but its variance is still somewhat high.

First you should be prepared to mine for a couple of days to check that your configuration is good enough (study the efficiency value displayed by your node's main page). If your efficiency is near or above 100%, you can expect more income on P2Pool than in most traditional pools. The only question for you is how long you are willing to wait for variance becoming negligible. On P2Pool with the current hashrate, you should expect to be in the 80-120% luck range in a couple of weeks. I've never seen P2Pool get <80% luck during more than a month. In 6 months I've seen both near 120% luck in a month and near 80% luck in another. As I wrote elsewhere: add your hashrate by joining us and variance will go down!

Note: P2Pool's payment method is PPLNS, with its current configuration you have to wait approximately 72 hours (on Bitcoin, this changes with other coins) to get the first "full" payments. These payments are mined coins (unlike most other pools), they are usable after 120 confirmations not 6 (but you get them as soon as the block is found which makes them usable as quickly as most other pools).

What matters for good P2Pool results: low latencies

On average a miner on a classic pool needs to react to a new coinbase every 10 minutes. Every 10 minutes a miner on any pool can submit a share based on a block that isn't the last one anymore. This is wasted effort: it doesn't help generate the next block in the chain and the pool suffers from this. Most pools reject such work and ignore it when they compute miners' rewards.

Miners are often separated from their pools by long-distance networks with tens or hundreds of milliseconds of latency. This means that every 10 minutes a miner on a normal pool is wasting its efforts for at least tens or hundreds of milliseconds. This is why there are rejects even on properly tuned classic setups: for 10ms of latency between miner and pool on average you should expect 0.01/(60*10) = 0.0016%:

Latency	Expected rejects
10ms	0.0016%
100ms	0.016%
1s	0.16%

Conclusion: on a traditional pool, relatively high latencies aren't such a big deal.

On P2Pool, the tracking of the proof of work is implemented by a sharechain which mirrors several properties of the Bitcoin blockchain:

• A share is a proof of work with a given difficulty
• A share uses the previous share in its input to make a sharechain like blocks do to build the blockchain
• It builds on a block template given by a Bitcoin node: a share hitting the Bitcoin difficulty can become a block too
• It's difficulty is dynamically adjusted to maintain a fixed average rate of share generation (one every 30 seconds)

The last point means that having a low latency is more important for a P2Pool miner than a miner on a traditional pool. Pay attention to the fact that a share being submitted too late to enter the sharechain can still produce a block so it's not wasted work (high reject rates are not a problem for global income on P2Pool unlike rejects on traditional pools). This said as the rejected share isn't in the sharechain it won't count as a proof of work for the purpose of distributing the pool's income.

The important thing is: high latencies don't hurt the pool's income but they hurt the miner's income.

Let's suppose that all miners on P2Pool have an average latency with the P2Pool network of 150ms. A "slow miner" configures a P2Pool node and begins mining with a latency of 600ms with the P2Pool network.
The amount of his work not entering the sharechain is 0.6/30 = 2%. The amount of work not entering the sharechain for his peers is 0.15/30=0.5%.

For 150ms more latency, this "slow miner" efficiency is 98/99.5: ~98.5%.

No work is wasted so the pool itself will make as much as any other pool with the same hashrate. But the slow miner will see 98.5% of the income he may have expected. All the other miners will earn more than they should (how much depends of their aggregated hashrate vs the hashrate of the "slow miner").

On some setups the addition of latencies at various levels can easily add up to a whole second. Miners with such latencies can expect up to 3.3% of lost income (this isn't as much as it used to: before July 2013 the BTC share interval was only 10 seconds instead of 30 seconds now which made the lost income ~3x what it is today).

The hunt for latencies

Here's a comprehensive list of latency sources and how to reduce them.

Cause	Solution
WAN latencies	: QoS, remove superfluous trafic and tune bitcoind/P2Pool for less network usage
Miner<->node latencies	: put them on the same LAN or see above
P2Pool node latencies	: use a fast CPU for the node
Hardware latencies	: tune your miner software, don't use some hardware on P2Pool
Bitcoind latencies	: Use bitcoind 0.8.2 or later, tune bitcoin.conf
IO latencies	: Use bitcoind 0.8 or later, SSD or tmpfs/ramfs, large RAM amounts for cache

You often can pinpoint where your latencies are by studying the graphs available at http://:9332/static/graphs.html?Day or the main stats page at http://:9332/static/
P2Pool maintains statistics for your node since its start time, it's often not easy to compare them with stats for the whole P2Pool network for which you can follow the changes over time in the graphs (the 1 hour average is displayed on the main page). Tip: restart your P2Pool node and check the value you want to compare after 1 hour and then 1 day (you can get averages for the whole network on these periods in the graphs page).

WAN latencies

Wan latencies are sources of orphans. You can get your amount of orphans in the main stats page (compute the % by dividing it by your total amount of share and multiplying by 100) and the average % of the network in the graphs page.

If your orphan % is noticeably above the network one, your Internet connection needs care: unclog your pipes or use QoS!

QoS
The best way to solve the problem is QoS. Just give top priority to the bitcoind and P2Pool traffic :

• TCP port 8333 in both directions (bitcoin P2P)
• TCP port 9332 to the node (miner connections to node)
• TCP port 9333 in both directions (P2Pool P2P network)

Making room
If you can't setup QoS, your next best option is to limit the traffic used by all the bandwidth hogs (when the bandwidth usage reaches the limit, the latencies skyrocket). A good rule of thumb to start with is to leave ~100KB/s in both directions available for P2Pool + bitcoind.

Tune bitcoind and P2Pool
If you can't use the methods above or they aren't enough you can limit the number of connections used by bitcoind and P2Pool.

For bitcoind, use the parameter maxconnections in bitcoin.conf

Code:

maxconnections=10 # 125 is the default, don't go below 8

There's a compromise here: the more connections, the faster your node will be notified of new blocks and avoid wasting work, the faster it can include transactions with fees in the coinbase and the faster it will propagate a P2Pool block minimizing chances it would become orphan.
But the less connections, the less bandwidth used and the lower the latency.

More than 20 for maxconnections is probably overkill: from my experience (trying various values from 6 to 100) it seems there's not much gain to have past this value (and if you don't have enough WAN bandwidth it can hurt your latencies by queuing transfers between P2Pool nodes during peaks).
Note that this may change in the future if the behavior of bitcoind/P2Pool network changes: when in doubt, monitor your interface(s) bandwidth usage and raise this value when most peaks are below your link capacity.

If your orphan rate is fine, don't tempt the devil and try tuning maxconnections below 20: you may reduce your income more than you increase it...

Warning: P2Pool needs one connection to bitcoind and bitcoind tries to fill all the allowed connections after startup. If you start P2Pool just after bitcoind (or before, it will repeatedly try to connect), it shouldn't have problem connecting because bitcoind will still have connection slots available. If you set maxconnections too low P2Pool might not succeed connecting.

For P2Pool, you can do the same by passing parameters to P2Pool:

Code:

--max-conns 8 --outgoing-conns 4

Note: orphans will quickly rise if you have very few connections (they are the means to be notified of other shares after all). I would prefer reducing bitcoind connections before P2Pool's.

In my experience you can get as low as 6 total connections (3 in, 3 out) without noticeable efficiency changes. The default values seem overkill (6 outgoing, 40 incoming). The large number of incoming connections (--max-conns) is designed to help the whole network (some nodes are behind firewalls that don't allow incoming connections). You probably should allow more incoming connections (and check that your network setup allows incoming connections) to do your part in helping the network.

Tune the block generation to limit your bandwidth usage
Even if you have low latencies and didn't need to tune anything above, a limited upload bandwidth can slow down the transfer of your shares to other nodes resulting in more orphans. Check how much of your bandwidth is used by P2Pool in the graphs. You want most of the peaks shown in the "Hour" graphs to be below your available bandwidth.
To know your available bandwidth subtract the bandwidth used by other process from your peak bandwidth. For bitcoind an upper limit to how much bandwidth it can use should be around 2x the max blocksize (1MB) per connection with peers (1x for learning and transmitting transactions, 1x for learning and transmitting a block including them) every 10 minutes this is ~3kB/s for each connection (this is why I recommend to lower the setting from 125 to 10 above).

If lowering your number of bitcoind and P2Pool connections to the values above doesn't free enough bandwidth, you might want to setup bitcoind so that the amount of data transferred by both bitcoind and P2Pool is lower. You can do that by limiting the size of the blocks your bitcoind accepts to create, this will limit the number of transactions included in your coinbase and the amount of data transmitted to other nodes:

Code:

blockmaxsize=250000 #default is 500000

If you don't have this problem, you should raise the blockmaxsize value instead to get more income:

Code:

blockmaxsize=1000000 #default is 500000

This is the maximum value allowed by the Bitcoin protocol. There are lots of unconfirmed transactions with low fees just waiting for P2Pool users to mine them and get the benefits. You should only use lower values if all other means of saving bandwidth don't work without lowering your efficiency (lowering the number of connections from both bitcoind and P2Pool as shown above). Lowering this setting not only lowers your income, it lowers every other P2Pool user's income too.

Miner <-> node latencies and hardware latencies

These 2 sources of latencies are causes of DOA shares. Use the same method than the one described above for orphan shares to see if you are affected.

Hardware latencies

ASICMINER Block Erupter blades: they seem to work correctly according to this post.

Avalon: works fine with latest firmware. If you don't get good results, your first check should be to find out if you can upgrade your firmware.

BFL: if you have a BFL Single, an early FPGA MiniRig (cgminer has a parameter for later ones to fix them, check its documentation) you may want to avoid P2Pool, they have huge latencies and can't perform well on it (might be good enough with the current 30s share interval, you'll have to test it for yourself). Put them on a traditional pool to be safe.  If you have a BFL SC (ASIC), ckolivas and kano reported the same problem, see ckolivas post. At least two users reported around 100% efficiency: here and here. You might want to test it for yourself for at least 24h and report your results here (please include the details from cgminer's API if possible). It's likely that with the new 30 second interval they are OK.

FPGA: I only have experience with Icarus and Cairnsmore1. They are excellent for P2Pool: even better than my tuned GPUs. Most other FPGA-based miners using Spartan6 should be able to interrupt their current work to start again on a new coinbase so you probably should not have any problem with them. Note that I tried bfgminer with Cairnsmore1 to test its support for dynamic clocking and it generated more orphans than valid shares, MPBM didn't have this problem (but could only connect with longpoll, not stratum). If you have problems with bfgminer, try to switch to cgminer or MPBM with longpoll.

GPU: If you use cgminer or Luke-Jr's fork bfgminer, an example working well on sha256d coins (Bitcoin/Namecoin/...) is:

Code:

-Q 0 -g 1 --intensity d --gpu-dyninterval 50

Dyninterval sets the maximum amount of time a GPU should be blocked, it's set in milliseconds. 50ms is a good compromise because the hashrate is still good and the maximum blocked time is still less than 0.5% of the share interval of P2Pool so can't influence its efficiency much (theoretically at most 0.25%).

For scrypt coins (Litecoin/...) optimizing is kind of a black art. I've seen at least one guide on this forum. Notes: dynamic intensity with cgminer didn't work well for me on 5870/5970. "-g 1" has been reported bad on 7970 (although it works for me...).
cgminer versions before 2.11.2 created a lot of stack traces in p2pool logs. Upgrading to at least 2.11.3 is advised (you should always try the latest versions anyway).

Miner <-> node latencies
As much as you can, put the miners and the P2Pool node on the same Local network. If it isn't possible, see how to optimize for WAN latencies and apply to the network used to connect your miners to P2Pool.

Note that at least one user (zvs) reported good efficiencies with as much as 300-350ms average latency between miners and node.
Another report reported excellent efficiency with 19ms and 32ms RTT (Round-trip time) to the miners and 110-115% efficiency. Try to keep your RTT low for miner <-> node traffic by using QoS.

P2Pool node latencies

I'm not sure if the node code has been profiled to find out if there are code paths slow enough to create noticeable latencies. If you can, use a fast CPU to run the node and at least a dual-core so that bitcoind and P2Pool won't have to share a core.

Bitcoind latencies and I/O latencies

Use the latest stable bitcoind (0.7 is very slow, old 0.8 versions still have performance problems).
You should run bitcoind on the same system than p2pool for best results if you can (I don't have results for setups where bitcoind and P2Pool are on different systems).

Latest tests show that the getblocktemplate latency doesn't influence efficiency much (at least up to 0.4s). Note that one possible side effect of high latency is that your CPU is used at 100% while bitcoind is processing the request and this could slow down P2Pool, indirectly lowering efficiency. You should not notice this effect on a multi-core CPU if it's not heavily used by other processes.

If your getblocktemplate latency is really high (>0.3s) and your efficiency is <100% your low efficiency might be linked to your getblocktemplate latency, it's more likely to be linked to high bandwidth or CPU peak usage, so check that you don't have regular CPU/network peaks before trying to lower getblocktemplate latency needlessly.

You can follow these tips (especially if you have a weak CPU) ordered roughly from most to least efficient (you can skip the ones you can't do easily obviously). For each tip applied, look at your average bitcoind latency and efficiency as reported by p2pool for at least 24h starting from a p2pool restart before changing something else (or you won't know for sure if the changes you noticed are due to network fluctuations or your modification). Stop tuning as soon as an average of 0.2s latency or 100% efficiency is reached going below 0.2s will hurt your income and everyone else's on P2Pool.

Note that to do any valid comparison of impact on efficiency you must study your efficiency changes while both the whole network P2Pool's hashrate and average DOA+orphan are stable. Tuning the block size and fee limits lowers the income per block and impacts everyone including the ones doing it, don't do it unless you really need to.

• Install the latest version of bitcoind if you don't already run it
• give CPU and IO priority to your bitcoind and p2pool processes if your OS allows it. With Linux, use nice (nice -n -10 for higher CPU priority, see man nice) and ionice (by default nice gives higher IO priority too, see man ionice to override the defaults) and use the CFQ scheduler) by putting "elevator=cfq" in your boot commandline (google for grub/lilo/... examples)
• use a faster at least dual-core CPU (one core for bitcoind, one core for P2Pool)
• move the bitcoind and p2pool data directory to SSD storage
• reduce blocmaxsize to 500000 instead of 1000000
• raise mintxfee and minrelaytxfee back to defaults (0.0001)
• at this point, if you are still above 0.4s and your efficiency is <100%, reapply the measure that had the most impact between the last 2 (blockmaxsize=250000 or mintxfee/minrelaytxfee=0.0005 for example)

Did you succeed and do you have a good setup now?

Check your P2Pool node's web interface (http://:9332/static/) or logs: your efficiency should be near 100%.

If it's noticeably below after tuning, you might want to describe your setup in this thread so that we can find out if something can be done and enhance this guide. Unfortunately some configurations have inherent latencies that will put you at a disadvantage without any way to improve the situation.

Lower than 100% setups might not make P2Pool a bad solution: it depends on your other options.

Raising P2Pool income
Versions of bitcoind before 0.8.2 had trouble managing large number of transactions. Now bitcoind is more efficient and we can tune it to include more transactions in a block than the default. This will raise the income of each P2Pool miner.

First, if you don't have 0.8.2 or a later version, install the latest stable version.

Then use these parameters in your bitcoind.conf:

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

Processing transaction is now cheaper, so we can include transactions with lower fees. bitcoind automatically selects the most profitable combination of transactions, using these values allows it to select from a larger set than the default values.

Avoid restarting bitcoind when you don't need to: on each restart, the local copy of unconfirmed transaction is reset and your node must wait for peers to transmit them again (this is a very slow process). If you find a block just after a bitcoind restart, there will be almost no transaction fees in it.

Myths, urban legends and misconceptions about P2Pool

"P2Pool has bad luck"

I'll begin with a surprising introduction: there's no such thing as having bad luck. Yes, you read it right, this doesn't exist. Now everybody here and myself included have seen long periods of bad luck so how can I say that we can't have it?
This is due to the very nature of what we refers as luck: we can say that we had bad luck in the past, but not that we are having it right now. Luck is defined on a period of time, so there's no "luck" now, only luck in the past (we can't speak for the future, now can we?).

So when someone tells you that a pool, any pool, "has bad luck", what she means is that the pool had bad luck in the recent past. It could be at the beginning of a lucky period or not, there's no way to tell based on what happened before.

In the case of P2Pool, the relatively low hashrate creates high variance in income. At the date I'm writing this it just found out as many (3) blocks in 15 hours than the 5 days before. This is not a problem due to P2Pool but to the lack of hashrate on P2Pool: come join us to solve it

Statistical analysis of the P2Pool results have repeatedly shown that P2Pool doesn't exhibit any abnormal behavior and is just as lucky or unlucky one can expect it to be. The "but it feels wrong" argument is not backed by any evidence and disappears when P2Pool's recent luck remains above 100% for extended periods of time.

"P2Pool has many orphans"

In fact it did. There was a time in 2012 when the rising popularity of P2pool seemed to have hit a roadblock. After analysis it seems there was indeed a flaw that could lead to a larger proportion of orphans than other pools. P2Pool nodes took time to propagate found blocks and the local bitcoind wasn't used right away to publish the block. This didn't compare well to big pools using very well connected bitcoind nodes to publish their shares. This was a latency problem and was solved by letting the local bitcoind publish a potential block right away and by pre-transmitting the future block content between nodes in advance to avoid wasting time doing this transfer when the block is found.

In its current state, as presented above P2Pool is certainly one of the fastest pools to publish blocks, if not the fastest so it's orphan rate should be among the lowest.

"I tried P2Pool briefly and didn't get as much as I expected"

P2Pool's high variance and PPLNS might explain it: people with such experiences might very well have tried it during a period when luck was low or not waited enough to get the full payouts (although they probably did get paid after stopping to mine on P2Pool thanks to the PPLNS payout system).

At the current hashrate, P2Pool uses the average proportion of hashrate over 3 days to compute a miner's share of income in a block. With high variance P2Pool can find a block shortly after you begin to mine on it, give you a very small reward and then nothing for a while: this is expected (and won't harm your overall income in the long run).

"Making smaller blocks increase my income"

For most people it's the exact opposite. Smaller blocks have less fees. There are only 2 known reasons why bigger blocks could hurt your income:

• Generating larger blocks need more bandwidth for transaction pre-forwarding
• Generating larger blocks need more CPU power when calling getblocktemplate and may interfere with P2Pool's process if there are no other available core for it to use

If you don't have enough bandwidth you can lower your number of bitcoind and P2Pool connections. Up to a point (see the guide for recommended values) this won't affect your efficiency (in fact it will increase it if your system is bandwidth-constrained).
If you don't have enough CPU power because it is shared with other processes, give priority to bitcoind and P2Pool (see the guide for Linux tips).

There is some nonsense about reaching a value as low as possible for the getblocktemplate latency with people advising settings bringing it to ~1ms. There's no evidence that this latency is important for efficiency. Setups with 0.4s latency have shown efficiency levels as good as others with 0.001s. This legend most probably takes root in the fact that high getblocktemplate latency occurs when one of the two problems above occurs too but it isn't a problem by itself lowering this value doesn't address the problem efficiently, it only hurts everyone's income when done blindly.

Another inaccuracy is that generating large blocks leads to noticeably more orphans. P2Pool pre-forwards transactions betweens nodes: when a block is found, peers can build it with small bandwidth usage as they already have the nearly all the data needed locally: large blocks are broadcasted efficiently by all P2Pool nodes which makes it less likely to generate orphans.

FAQ

bitcoind tuning

Q: Is tuning the block sizes causing a problem with p2pool?
A: Not for the pool itself (your setting doesn't influence what other nodes do), but it may introduce latencies in your own setup which could lower your income (see the guide above on how to tune bitcoind).

Q: I don't have much memory, how can I fit p2pool and bitcoind on my server?
A: You probably can fit p2pool and bitcoind with good results in 1GB. The less RAM you have and the more compromises you'll have to make, lowering your efficiency in the process.
For p2pool, the number of open connections has an impact on memory usage, you can test --max-conns 3 --outgoing-conns 3 instead of the defaults (going lower might impact your efficiency, if you can't accept incoming connections, raise --outgoing-conns to 6 to get a total of at least 6 connections).
For bitcoind, its memory usage is more dependent on the number of transactions it maintains in its memory pool, raise mintxfee and minrelaytxfee from their default values to slim it down (note that you'll have to wait nearly 24h to see bitcoind reach a stable RAM usage: it grows at it slowly learns transactions from the network). Lowering the maxconnections value from 125 to 10 can't do much harm (you'll have to test to see if it makes any difference).

Known bugs/issues

Q: Why do I get lots of "Worker submitted share with hash > target:" in my P2Pool logs? It seems to put a large CPU load on P2Pool.
A: Your miner may not support pool-settable difficulties. It may be a problem if the rate of these messages gets very high (putting more strain on p2pool). Using stratum-proxy or the scrypt version might help.

Q: My P2Pool node can't connect to my bitcoind node but it is running fine.
A: One common cause is that your bitcoind reached its maxconnections setting. You will have to restart it to avoid waiting for a connection slot to be freed. If your P2Pool node can't connect even if you just started bitcoind, set a higher maxconnections setting.

TL;DR;

Mining on P2Pool needs more attention than traditional pools.
You should keep an eye on your efficiency as reported by P2Pool's main page.
If it's around 100% or above, you are fine and should leave the coins come in without worrying about luck.
If it isn't or you can't stop worrying take the time to read this guide.