You're welcome to believe what you want, but I'm done interacting with you.  It's an observable fact that if high hashrate miners opt in to a higher share difficulty/target, the minimum share difficulty/target will come down for everyone else. Think of it as "magic" if that makes you more comfortable.

It's really not that complicated.  p2pool adjusts the minimum required share difficulty for shares so that a share will be found once every 30 seconds.  Now, if a bunch of people start to opt-in to a share difficulty much higher minimum requirement (doing so is a feature baked into p2pool), then obviously shares are going to start to be found less often.  In order for shares to continue to be found about once per 30 seconds, everyone else has to start finding them more often.  The only way they can find shares more often (with the same hashrate) is if p2pool lowers the minimum required share difficulty, and that's exactly what it does.

It depends on the pool.  On some pools, for example p2pool, a stale share may still be a valid block and so if you don't submit stales, you risk missing out on BTC.  Historically, there have also been pools that paid for stale shares and so you always wanted to submit them.  I don't know that any current pools still do that though.

If you don't find shares very often, you won't always get a payment with every block.  When you do find a share, you'll get paid for the next several blocks (the number of blocks depends on how quickly they come, p2pool uses is PPLNS).  In the long run, it evens out, but the variability in payments (i.e. variance) can be very frustrating.  If that sort of thing seems like it would frustrate you, then don't mine on p2pool.  I, personally, wouldn't like the level of variance if my hashrate was only getting me 1 share every 12-24 hours (or worse).

p2pool can't pay fractions of a share, so the way it handles fees is that a 2% fee is that 2% of shares found by miners will be reassigned from the miner address to the node's address (randomly).  Because it is random, it will work out to 2% over the long term, but you won't see a consistent payment on a block by block basis unless you have a high enough hashrate that you're finding 100s of shares per block.

Yes. This is why the hashrate graph shown in p2pool.info is "bumpy".  Hashrate is not really changing that much--it's mostly just luck/variance.

By the way, this is a limitation of all pools.  No pool knows how much hashing is actually being done by its miners.  Pools only knows what shares are being submitted then they estimate hashrates based on those submitted shares (and then they calculate luck based on those estimated hashrates).  Over a long enough period of time, the inherent share-finding-variance evens out.  So I personally have fairly high confidence that the 90 day luck number, in particular, is reasonably accurate and that the pool really did find about 18% more blocks in the last 90 days than it "should have".  Maybe the real number is 17% or 19%, but it's pretty close.

P.S.  I have no idea how p2pool knows the global DOA/stale rate, but it clearly does (or thinks it does) since it is displayed in the console output and is directly used to calculate efficiency.

Both p2pool.info and p2pool, itself are open source, so yes, you can look at the code if you are curious. about the specifics

I don't know for sure how p2pool calculates pool hashrate for sure (forrestv will have to comment), but I generally understand it to be based on the number shares being found and I think it also includes some kind of adjustment to include DOA/orphaned shares as well.

p2pool.info collects and stores the hashrate of p2pool generally every 5 minutes. When a block is found, those 5 minute hashrate data points are used allong with the block's difficulty to calculate the luck of that "round".  Then, the luck of individual blocks are aggregated to come up with the 7, 30, and 90 day luck statistics.

A complete explaination is somewhere around page 100-120 I think

In a nutshell, the luck calculation is a comparison of the number of blocks that were actually found vs the number of blocks that should have been found (based on the pool's hashrate over time as reported by p2pool, itself).  When more blocks were found than were expected, luck is > 100% and vice versa.

Orphaned blocks are included in the count of found blocks because a block being orphaned or not has nothing to do with the mathematics of block finding probability and I wanted "100% luck" to equal "normal".  Certainly having blocks get orphaned is unlucky, but it's bad luck related to something different than the odds of finding a valid block.

You can trace the dividend payments backwards to see that the vast majority, if not all (I didn't trace every address) of the coins used to pay my dividend came from btcguild-mined blocks and btcguild payouts.  As such, I assume LRM is mining at btcguild.

Great.  I'll start looking for tiny heat sinks...  The VGA RAM heatsinks I have now are way too large for that tiny chip.

Here is a closeup look at my card a v2.2 version H-card.  I don't see anything in that spot other than the trimpot.  Is it the trimpot, itself that needs the heatsink? Or that tiny thing labeled R01F?

My cards are all stabilized and have good fans directly next to the cards (similar to yours, but without the great case (I am on the waiting list for one)).  My rig is very stable with chainminer.  Just not with bfgminer or cgminer.  My only issue with chainminer is the lack of support for failover.

I'll try heatsinks.  Which piece is the voltage regulator and are there any gotchas or risks to be aware of?

No, you need to use a proxy.

+1

That's me in a nutshell. 

Ok, then I don't understand what you're asking for. 

The my payments are always 0.2xxxxxxx.  The only case where I would receive a dust payment is if I stop mining altogether at eligius right after I had received a payment, then eventually I would get my balance (no matter how small and dusty) as a payment.

Are you asking for payments to only ever be in clean multiples of some payment threshold?  So 0.20000000 but never 0.21738261?  I guess I can see the point if when you spend bitcoins, you only ever spend them in nice round numbers.  That hasn't been typical for my purchases (via BitPay), because of exchange rates, the merchants are often asking me to send them a payment of 0.162534 or whatever, and so even if my wallet was initially full of nice clean inputs, they wouldn't stay clean for long.

Thanks.  I did find you post and I used your image for a while, but my v3 hardware is apparently even more unstable than yours and while it does mine, there are still lots of errors and observed hashrate is about 20% lower than with chainminer (presumably because so many cores are erroring instead of hashing).

I wonder how viable it is for me to adjust the trimpots to reduce the voltage and un-overclock these just a little bit to increase stability.  I'd trade a little bit of hashrate for something that was more stable and for the ability to use a miner that gave me failover capabilities for when my primary pool is acting up.  But I don't own a voltage meter and I'm hesitant to just randomly start turning the trimpot "a little bit" counterclockwise.

minimum payout can be configured here (I have mine set to 0.2):

http://eligius.st/~wizkid057/newstats/mystats.php?cmd=options

I have to correct myself.  I did a test where I pointed cgminer-tune at only eligius (not load balanced with btcguild), and in that configuration, I also see the 10% lower WU (and the 10% HW which I agree and understand are not real hardware errors, but are reported as hardware errors for some reason in cgminer).

It seems that by sending a portion of my hashing to btcguild, the problem was being masked.

P.S. That chart based on faulty data and so usually quite inaccurate.  Use this one instead:

http://blockorigin.pfoe.be/chart.php

Does anyone know if it is possible to run any variation of cgminer or bfgminer on v3 boards?  I understand it wouldn't be officially supported, but I am willing to experiment a little and/or compile my own copy, etc.  I found some old forum posts elsewhere hinting that it might be possible, but they are very old and appear to be specifically for the v1/v2 boards and maybe were specific to the European version of the hardware (is there a difference?).

For reference, my reason for wanting to do this is that I am really trying to get my rig working with multiple pools.  At least for failover, but ideally for load balancing as well.  Both are built into cgminer/bfgminer.