Read what I wrote again more carefully.  P2Pool hands out low difficulty shares to miners.

2012-02-13 23:49:52.854231 New work for worker! Difficulty: 3.120516 Share difficulty: 619.661413 Total block value: 50.043000 BTC including 102 transactions

So if you connect to a public p2pool node, from your miner's perspective you will see low difficulty pseudoshares.  The only way you ever know that the real shares are higher difficulty is by seeing the console output (which someone only connecting to a public p2pool node will not see).

I have successfully avoided knowing anything about Litecoin, so unfortunatly, I can't.

P2Pool already hands out work that is way less than the actual share difficulty.  It normally starts that at 1 and then adjusts it up to keep the impact of miner requests resonably low (for me, they are difficulty 3).  Maybe p2poolparty just edited the code to keep them always at 1. 

In any case, p2pool is smart enough to ignore submitted shares that don't meet the requirements of the real share difficulty.

Now, if you want to actually pay people based on diff 1 shares, then you have to make your own frontend to p2pool (a proxy pool) and deal with all overhead, etc.  But I don't think that was what ThiagoCMC was asking about.  I think he was just asking how to setup a public p2pool instance that everyone could use in "normal p2pool mode" but without having to figure out how to install it themselves. 

That's basically what p2poolparty is, but having more of them doesn't hurt.

In my experiments, reducing intensity (the -I flag) is much more important in reducing stales than adjusting overclock settings.

No.  Something is wrong.  What miner?  What miner settings?

On the other hand, the higher the pool hash rate, the sooner your found-share turns into a payment.  Currently, if you are a 200 MH/s miner and find a share (about once every 3-4 hours on average), you may have to wait 8-10 hours for the pool to find a block and turn that share into BTC.  If the pool hashrate gets up to 1TH/s, you may only find a share every 13-14 hours, but the pool will likely find a block within an hour or two and turn that share into a payment.

Variance math hurts my head and I can't wrap my brain around how to quantify how the two competing variances (pool variance interacting with miner variance) contribute to a miner's overall payment variance.  Need someone like Meni to enlighten me, I guess.

Much sooner than that.  Some might say it is already bad for small miners.  But I suppose it depends on what you consider "bad for small miners"?  If it takes a typical miner several hours to find a share, that is going to lead to painful variance.

I made a chart to illustrate what happens as the pool gets larger.  The chart is based on an overall bitcoin difficulty of 1.4 million (approx what we are now and will be for the next round).

Here is what the chart shows:

• The solid red line is the average time for the pool to find a block as the pool's hashrate grows.
• The dotted lines are the average time for miners of various sizes to find a SHARE as the pool's size increases and the share difficulty increases with it.
• The point where a dotted line crosses the solid red line is the point at which the average time for a miner to find a share becomes larger than the time for the pool to find a block.

Here is a large version: https://i.imgur.com/77zM9.png

As I understand it, higher intensity just mean "hey, GPU, run for a longer period of time before asking for new work".  The idea is to minimize time wasted by constantly asking for more work.  But with p2pool, running for a long time without asking for new work means a higher probability that the GPU will spend time working on stale work.

My setup is similar except I experimentally determined that I get the best hashrate (and the lowest stales with -I 6 -g 2).  I doubt that is making that big of a difference though.

For seperate workers, you need to configure your workers to use a special password (the VIP password).  You can find it either by looking at the p2pool log output as it starts up, or look at the contents of the file ./p2pool/data/bitcoin/vip_pass

Then there will be graphs per worker (worker name is whatever you are using for username).

Mine doesn't spike.  What miner are you using?



(sorry, it's a bit hard to see the red Dead line on top of the dark red device0 area, but it's there and essentially flat)

'GOT BLOCK FROM MINER' means you found a block.

'GOT BLOCK FROM PEER' by itself (without seeing the message above) means someone else found a block and they are just telling your node about it.

Edit: fixed

Yes, but that is just a "bug" in the bitcoin client.  The actual generation transaction does include your address.  The client just doesn't show it to you.

Ok, historical data from forrest is loaded.  It's interesting to see how quickly things have grown relative to how long the pool floated steadily at around 10-15 GH/s.

Yes, he gave me a database of old hashrate stats.  I just have to spend time getting it into my database.  We don't have old state rate data.  I'm not sure if stale rate over time is all that interesting though, so maybe it isn't important and should be replaced with something like # of active users over time.

I also want to look at luck, but I will admit that I don't yet know how I am going to calculate that with only the information I have.  But forrest's graph does it using this same data, so I probably just need to chat with him more and see what approach he is using.

I really need to also get a real backend for it because right now it is using the rrd files that the standard p2pool uses.  I'd like to move this to a real database on my web host instead of using the rrd files.

But tomorrow is my wife's birthday, so I don't know how much time I can reasonably spend on this over the weekend.  I'll probably squeeze a few hours in.

No, my page doesn't include those.  There's not a convenient centralized place to get a list of those that I can pull from.

I've been playing around with making a p2pool recent stats page.  It's not done yet, and the backend needs a lot of work, but it's done enough to give you an idea:

http://btcstats.net/p2pool/

• Includes Recent pool hash rate and stale rate
• Recent blocks are shown on the chart as vertical lines so that you can "see" variance
• Recent blocks are also listed in a table with links to the details

Litecoins use a different miner and are a different pool.  You can do both bitcoins and litecoins at the same time, but you do that by running two copies of p2pool at the same time (one in bitcoins mode and the other in litecoins mode).  The litecoins p2pool instance will be running on different ports and you point your litecoin miners at it while your bitcoin miners point at the normal p2pool instance.

Start a litecoin instance like this:

./run_p2pool.py --net litecoin -a paymentaddress rpcusername rpcpassword

Then point your litecoin miners to http://localhost:9338

He's trying to get p2pool to bind to a specific network interface (not to a specific port as your suggested solution was talking about).  But p2pool doesn't have an option to bind to a specific interface (yet) and instead it binds to all available interfaces.

That is the difficulty of the so-called pseudo share.  P2Pool lies to your miner and tells it to solve an easy share so that your miner finds shares more often than once every 20 minutes (as would happen with the real share difficulty).  P2Pool then effectively ignores (except to calculate stats) any submitted shares that are not good enough for the real share difficulty.  It was done so that you can tell more quickly if your miners are misbehaving.

Some (but not all) appear in the p2pool console output.
Some (but not all) are announced n IRC.

I personally just watch my bitcoin transaction log.  All of them appear there, and yes payments are instant.   They appear in mining or generation transactions (depending on if you are looking in the GUI or the commandline version of the bitcoin application).

If you were successfully mining (and actually found shares) for all of yesterday and did not get several payment transactions, something is wrong.