On one of my rigs, I suddenly had a lot of instability with 2.3.5 that resulted in GPUs getting SICK very quickly and often cgminer locking up completely and becoming unkillable. (even with kill -9).  I reverted to 2.3.4 and have been running smoothly for 3 hours so far. 

I haven't been able to pinpoint the problem.  Other rigs are fine (although all of the rigs are slightly different linux installs, so it's hard to know if it is a hardware difference or an OS difference or what). 

Here is the explaination forrest has given in IRC in the past...  If a share is stale/doa but still meets the current bitcoin difficulty requirements (aka it is a block), it is sent to the local p2pool node's bitcoind.  It is also sent to all of the node's peers.  Each of the peers also send the block to their own local bitcoind instances (in order to increase the speed of propagation through the bitcoin network).  However, each of the peers does not relay the stale share to any of their peers.

So it propagates partially through the p2pool p2p network and should be sent to at least 11 bitcoin nodes (1 bitcoin node from the finder of the block and the bitcoin nodes of the block finder's 10 outgoing p2pool connections).  If the block finder has any incoming p2pool connections, it will go to those p2pool peers as well.

A side effect of the fact that the stale share is not fully propagated through the p2pool network is that stale share/valid blocks are sometimes not announced on IRC because the IRC bots sometimes never hear about the stale share (because they are not a direct peer of the block finder).  We have seen this side effect several times (p2pool blocks have been found and not announced in IRC by any of the half dozen or so p2pool nodes that are connected to IRC and announcing blocks).

It would be an interesting experiment (and much easier because you can ignore the first problem by picking blocks that are shorter than 18 or so hours) to spot check.  If you want to calculate how many hashes you think went into a few blocks, I can tell you how many hashes p2pool.info thinks went into it and we can see how much variation there is in the two methods.

I don't fully understand the internals of the share chain distribution, but I think there are a couple problems that would have to be solved:

• We have a significant number of blocks where the duration was longer than the length of the share chain.  So in order to add up shares after a block is found, I would have to invent my own persistence of the the share chain that never got cleaned up.  Not trivial or fun (and fun = motivation to do it)
• The "hashes done by the pool" include hashes contained in stale shares that are not fully distributed through the p2p network.  Because those stale shares mostly could have been valid blocks, they need to be included in the luck calculation.  In fact a lot of our blocks actually were stale shares (as determined by the fact that they often aren't announced in IRC).  The current p2pool hashrate calculation handles this by counting the valid shares and then increasing the count based on the pool-wide stale rate.

That is exactly how pool hashrate is calculated, as far as I know.  p2pool does the calculation and publishes the hashrate at http://localhost:9332.  I just pull from that value and calculate an average over the duration of a block.


Agreed.  I have said basically that same thing several times in this thread.  If the hashrate reported by p2pool is too high, our luck will appear artificially lower than it actually is.  Forrest has several times reassured me that the hashrate calculation being done by p2pool is correct, but I have not validated that myself by reviewing code.



Yes.  I collect the pool's hashrate from the http://localhost:9332/rate API every 5 minutes.  Then calculate the average hashrate during the time between when blocks are found.  Then calculated # of shares exactly as you indicated (hashrate * duration / 2^32).  The only reason I use diff 1 shares instead of hashes directly is the convenience of using smaller numbers.

Raw hashrate data is here:  http://p2pool.info/stats

Note, hashrate stats are only 1 per hour for the first few months of p2pool's life because that is what forrest had available to backfill my database.  From the time p2pool.info was created forward (sometime in early Feb), hashrate data is in 5 minute increments.  The code that calculates the average hashrate actually calculates a weighted average so as to deal with mixed frequency of hashrate stats within a single block.

Raw data is here:  http://p2pool.info/blocks

For each block, you can see:

• The actual number of "difficulty 1" shares submitted before the block was found.  Note, that since we don't actually know how many "difficulty 1" shares were submitted, this is an estimate of how many difficulty 1 shares should have been submitted based on the average hashrate at the time and the duration of the round.  And so if the hashrate published by http://localhost:9332/rate is wrong, then this number of shares will also be wrong.
• The estimated number of "difficulty 1" shares theoretically needed based on the bitcoin difficulty at the time

% expected for a single block is:  actual shares / expected shares

% luck over a 30 day window is (sum of expected shares for all blocks found within 30 days) / (sum of all actual shares for all same blocks)

p2pool.info relies entirely on the number reported by p2pool, itself, at http://localhost:9332/rate   If that is wrong, then the luck calculation will be wrong.  Fixing it is not something I can do.  The fix, if there is one to be made, needs to come from forrestv.

Awesome, thanks.

The remaining two bounty payments have been sent:

To Luke: http://blockchain.info/tx/ba031cdf4efdaf4a7f6bce52442539c6a415b5c612f194c04a4a4971cfdebb9b
To Ckolivas: http://blockchain.info/tx/a11d526aa66121ed4b0bb5cf828f2ab223e83a34471dbf6020e664dc219b52b5

I paid luke 5BTC for the share log solution:

http://blockchain.info/tx/7732db071b843e378b458b447c4962b0ffb22d638da77096238cd266fc847eef

ckolivas, if you don't like the share log idea and want to do something else officially, I'm willing to still pay you the original 15 BTC since I should have anticipated the fact that someone else might have created a solution in the short time between when I posted the request and when you saw the bounty and decided to do something else.

Just let me know what you prefer.

I just used 0.999985 because that is the actual difficulty for a "diff 1" share for most pools since a diff 1 share is actually 0x00000000FFFF0000000000000000000000000000000000000000000000000000 but in practice most pool software actually uses 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF instead for simplicity of validation (they can just make sure that the hash starts with 8 zeros and don't have to do any actual large integer comparisons) and that target translates to slightly less than a difficulty of 1.0000.

So in other words, this is what I mean by difficulty:  https://en.bitcoin.it/wiki/Difficulty

Converting the target to difficulty is one of the things I didn't want to have to figure out myself in C/C++  I have code to do convert between difficulty and target and the 'bits' representation of target that is actually used in a block, just not in C/C++.  So I don't care which format is used since I can convert it as part of my analysis.  I just suggested difficulty because it was terse.  Target is equally fine with me, but it would then probably have to be in something like a seperate share log as luke was doing since there is no reasonable way to output the massive hex target in the normal output.

P.S.  Luke sharelog is mostly working now, so if you like it, you're welcome to avoid more work.   If you don't want to accept luke's solution, I'll probably still pay him an extra 5BTC for his effort since it works and is useful.

Ok.  I'm fine with either adding the difficulty to the normal output as I originally suggested or creating a share log file as luke coded it (assuming we can get it working).

And I wouldn't expect this to change the reasons why shares appear as rejected.  I expect rejected shares are shares that cgminer thinks meet the target but that the pool rejected for whatever reason (e.g. they were stale).

It compiles on linux but doesn't work.  The output is happening, but not to a file (it appears on screen no matter what I have tried to pass to the command line param) for each share there is also this error:

I have a requested enhancement (see below for the bounty).  I have a need to log all of the shares that are found by cgminer (for statistical analysis purposes) and the existing information that is output is almost enough but In order to do my calculations, I need to know the target for the work that resulted in the share since I mine on pools that don't have a fixed share difficulty.

The current output looks something like this:


My request is for some option to add in the target for the share.  To save output space, it would be preferable for it to be displayed as the equivalent difficulty and not the massively verbose hex target.  So as to not bother other cgminer users or those that are already parsing the current output, perhaps it should be optional (based on a new command line parameter, etc)?

I'm imagining something like:


Or some other equally parse-able format that includes the timestamp, accepted/rejected, the share hash (or at least as much as is currently included), the difficulty/target, which device it was, and which pool it was (for cases where there are multiple pools configured).  It's fine if it also includes the thread (as shown above), but I don't need that information, myself.

I have looked at the code and I don't think this is super difficult, but I am not a skilled enough C/C++ programmer to do the enhancement myself with any confidence, so I will put up a bounty for it instead.  I know ckolivas is busy and/or on a break, so I don't mind if someone else does it and provides a patch.  That said, I'd prefer to see it incorporated into the mainline source code so that I don't have to worry about it breaking in the future, so I'm going to include some incentive for it to be merged as well.  Here are the bounties I am willing to pay:

• 5 BTC to the author of a working patch against the current git cgminer source.
• 5 BTC to the author of the patch if and when it gets merged into the cgminer source. This obviously means the change has to be done well enough that ckolivas is comfortable merging it.
• 5 BTC to ckolivas if he merges the patch.

So that is 15 BTC to ckolivas if he does it all himself, or if it is done by someone else up to 10 BTC to the author and 5 BTC to ckolivas for merging it.

Note, the orphans that are known (the 6 on p2pool.info) are already accounted for in the luck calculations (i.e. luck is not reduced by known orphans).  The only think that could, in theory, be making the luck look lower than it should is unknown orphans, and I don't think there are many of them.  While the statement I made on p2pool.info is technically accurate, I do scan blockchain.info regularly looking for orphaned blocks and it does a pretty solid job of knowing about all orphaned blocks because it connects to 3000+ bitcoin nodes.

We have 331 total blocks and 6 of them orphaned.  That's a rate of 1.8%.

I have very high efficiency with my current p2pool setup.  Here are my current stats (it has been a week or two since I most recently restarted p2pool):


I have been consistently getting approx 3.5% stale rate for the past month or so, so this is not a fluke.  Here are some musings...

• The hardware that p2pool and bitcoind runs on matters.  I went from a VM to a fast physical machine (for just p2pool and bitcoind--no change to miners) and that dropped my stale rate by half. My assumption is that CPU speed matters more than RAM amount as long as you have enough RAM that there is no swapping.  Disk performance may also matter for bitcoind.
• The conventional wisdom on parameters for cgminer is not as relevant as people make it sound.  For example, I do not use 1 thread per GPU.  I found that to be irrelevent.  My settings vary from rig to rig (my rigs are not all identical GPU hardware or even SDK/driver version).  For each rig, I experimented with combinations of thread and intensity until I found the best hashrate and stale rate.  In all cases, I ended up with either 2 or 3 threads per GPU and intensity setting different than what people normally seem to use.
• I don't have data to back this up because I don't have a "control" to compare against, but I suspect that connected-ness of p2pool matters a lot.  My node is an old node and so almost always has 40 incoming connections.  With only a few hundred nodes total, that means I am hearing about new shares directly from about 20-25% of the nodes instead of hearing about new shares second or third hand.

In my experience over the past several months, it was the hardware change that made the most dramatic and instant impact.  I went from "average" stale rate to "consistently 2-3% better than average" stale rate over night when I changed the hardware for my primary p2pool node.

Of course, I probably should just keep my mouth shut and enjoy my extra efficiency.  If everyone improves their stale rate, my great stale rate becomes just average again

I know, right?  This totally sucks.  Bitcoin is taking up all the space on my hard drive.  I mean, I only have a 10 GB hard drive...  oh wait, no I have a 2TB hard drive and the block chain is an insignificant blip on its radar.  Nevermind.

I just have all my hardware set to automatically start after a power failure.  And I have 1 rig that has two PSUs, but both PSUs are tied into the 24 pin motherboard connector (using a splitter) so that they both turn on and off with the computer.

Fixed it.  The updated version is being deployed now.

Also, I didn't understand your question until now.  But FYI, your payout address is exposed here:  http://bitpoppool.geekgalaxy.com:9332/payout_addr

Ah, I see that something broke on p2pool.info.  I'll have to fix it.