Sorry, I'm not good with names.  No offense intended.  


I wouldn't call it nitpicking.  The fact is under a week ago, 90+ day performance was < 90%.  That is awful in my book.  Is it really luck that suddenly changed this last week?  While I find that hard to believe (and I'm not convinced), I'll defer to the mathematical experts who claim it's all variance and shut up.

M

I am a mathematical expert. If your hash rate solves 2 blocks every day over 90 days, there is a 9.4% chance that in any given 90 day period you'll have < 90% "luck"

If your hash rate solves 1 block every day, there is a 19% chance that you will have less than <90% luck in a 90 day window.

So when p2pool's hash rate was low the pool was more likely to have < 90% luck over 3 months than someone throwing a 6 on a 6 sided dice.

My point is that I'm kind of surprised people think something that has between a 1/10 and 1/5 chance of occurring is a sign it is broken.

There are 2 problems with your arguments.

• I use "can be obtained" because it involves more than simply using tmpfs. If you have enough RAM, you indeed can obtain the best results. It's left to the system administrator to find out how to tune and monitor a system using tmpfs.
• tmpfs can indeed use swap, but unlike you wrote last time I checked ramfs isn't bounded. So if your RAM isn't large enough to fit your tmpfs system at least you can set a boundary and avoid unpredictable behaviour. If you use ramfs and bitcoind's data directory grows to a point where it fills your whole RAM it will put everything else in swap and eventually trigger the kernel OOM killer. What will be killed then can only be guessed.

So ramfs isn't a clear-cut better solution here: it depends on how the system admin is configuring the whole setup. Anyway this is for advanced admins: people shouldn't follow a guide for this but fully understand the implications themselves. I wouldn't recommend it but I'll add ramfs as an option in the guide.

To check what I just wrote about ramfs:
You can write 30M to a 20M ramfs (at least on a 3.7.9 kernel)...

Edit: man mount clearly shows that there's no options for the ramfs filesystem. So "-o size=20m" isn't even an initial value or a hint, it's completely ignored.

Question.. in the OP it didn't mention about setting up a stratum proxy so that miners futher away from your p2pool instance can connect via stratum. How would I do that? I know how to set up a proxy for local getworks TO a stratum receiver, but it's the setting up of a stratum receive to p2pool I don't understand yet.

This a great guide - thanks!

I have a couple of questions.

This thread, and others, have said:
I'm new to bitcoin (as my rep will tell you), but I understand the concept of luck and variance. How specifically does p2pool "out pay" others? I currently mine on a no-fee (keep trans fees) PPLNS pool. My analysis shows that the trans fees are ~1% so p2pool will out pay there. How else? Is there some sort of reduced latency bonus? Or just a "no-downtime" gain? I read somewhere that >100% efficiencies are "stealing" somehow gaining from others with low pool efficiency by getting their hash power but not always giving credit -- or something.

Also, this guide mentions using: Can you elaborate? the -g sets the miner to a single thread (opposed to 3 on my machine). Isn't that going to reduce my hashrate? the -Q 0 seems inefficient too but I assume that I'm missing something. The --gpu-dyninterval default is 7 but you recommend 50. I don't understand why. These setting seem really important so I really want to understand.

Finally, how is difficultly handled? Hosted pools can auto-adjust this "magically". How can I tell what I should set mine to (or leave it at) and how do I do it?

Eligius - It's actually CPPSRB - Capped Pay Per Share with Recent Backpay

I understand the value of p2pool but I don't think that a failing pool is all that costly. If you have a failover you shouldn't have any issues when the primary is down. Worst case is that you'd lose out on anything that wasn't distributed to you yet - hopefully < 0.2

Among p2pool users there's indeed a competition for the best efficiency. It shouldn't be a problem though: people with really bad efficiency unable to make it better shouldn't mine on p2pool leaving only the most efficient ones (which will bring them closer to 100% efficiency). This is assuming their goal is maximum rewards, you can mine on p2pool for other reasons (you like the concept or find it a better solution for Bitcoin's overall health/robustness).

The advantage of p2pool vs classic pools is stated in the guide: it should have less orphans than classic pools because it's better connected to the Bitcoin network and thus should propagate blocks faster (this is a theoretical advantage, I'm not aware of anyone having measured it).

One thing I didn't write yet is the ability of merged mining. If you have moderately high hashpower (currently ~5GH/s) it should bring you additional coins. Namecoin has been between 5 and 13% as profitable as Bitcoin recently, being able to merge-mine it (Devcoin and Ixcoin are possible too) is an additional bonus. For example I set NMC merged-mining up early just to tinker with it (it wasn't really worth my time) and found a quite nice surprise when looking at my NMC wallet last month: 1000+ NMC where waiting there...


It depends on your setup, but I didn't measure any speedup with -g 2 on mine. The higher the number of threads and the higher your latency is, so if it doesn't bring any measurable benefit, you should keep it down.

I'm not sure about --gpu-dyninterval default value but the goal is to keep the GPU latency low without sacrificing too much hashrate. I've measured a ~0.3% lower hashrate when going from 250ms to 50ms but the amount of stales/doa was much lower too. Going lower was eating too much hashrate and I believe 50ms to be much lower than most people latencies with the P2Pool network.

These are good starting point, but if you want to grab a 1% worth of Bitcoin more you might want to study the impact of modifying them by comparing the <hashrate>*<efficiency> (which is what matters for your p2pool's income) value for long runs (at least 24h).

This is what is advised by p2pool. It seemed inefficient to me too, but I couldn't measure any impact vs -Q 1.


Difficulty is auto-adjusted automatically so that your miners keep submitting ~1 share every second (to avoid too much traffic and load and still get a good estimate of your hashrate).

Note: if you use cgminer, and probably bfgminer, you don't want to mix p2pool and "conventional" pools.  They don't mix well.

M

They do. I've seen my rigs fallback to backup pools without problems when I stopped my p2pool node on numerous occasions.