Quote

...Bad CPU performance isn't necessarily a show stopper...

upgrade from Pentium D 915 2.8Ghz (dual core) to i7 3.2Ghz reduced GBT latency by 1s on unchanged OS (linux), p2pool, and bitcoind config.

Quote from: gyverlb on July 26, 2013, 01:06:25 AM

Quote from: kano on July 26, 2013, 12:39:44 AM

... the previous block was 86 seconds before it ...

So that was a fast block, probably expected to get 86 / 600 as much transaction fees as an average block.

Quote from: kano on July 26, 2013, 12:39:44 AM

It's not empty, so got nothing to do with it ... as you can easily have seen by looking at the 3 blocks mined in the last 24 hours without having to guess which is the block I found ... even though my block is listed there in my post Tongue

Probably but I'm lazy...

Quote from: kano on July 26, 2013, 12:39:44 AM

Quote

You can check what your bitcoind includes in its coinbase with

Code:

bitcoind getmininginfo

: currentblocktx is the number of tx in the coinbase and is obviously lower than pooledtx (the number in your memory pool).

Code:

# ./bitcoind getmininginfo
{
   "blocks" : 248451,
   "currentblocksize" : 77889,
   "currentblocktx" : 133,
   "difficulty" : 31256960.72776893,
   "errors" : "",
   "generate" : false,
   "genproclimit" : -1,
   "hashespersec" : 0,
   "pooledtx" : 1759,
   "testnet" : false
}
#

Well that says something evil about bitcoind ...

Not really evil, txs that aren't included with default bitcoind settings pay below-minimum fees. Some pools obviously have more permissive settings and it probably pays off.

Quote from: kano on July 26, 2013, 12:39:44 AM

... looks like I need to decrease those 2 'min' values to at least stop bitcoind from screwing over the BTC network ...

Your bitcoind isn't really screwing anyone as it includes txs paying the minimum fees. TXs with lower fees are eventually included (older inputs get higher priority and there's provision for txs with no fees in a block), not giving a standard fee gets the expected outcome: slower processing by the Bitcoin network.

Quote from: kano on July 26, 2013, 12:39:44 AM

Someone else I was discussing this with suggested that p2pool decides to drops transactions itself based on performance, it wont use all the txns given to it by bitcoind ... is that correct?

I'll bet not. I didn't check the code but:

p2pool logs match what you would expect when modifying bitcoind settings
it's easier (and probably faster) to let bitcoind compute the coinbase instead of fiddling with it
my node has the settings given in my previous mail which includes more txs than average and it is sending more data to other p2pool nodes than it receives, which matches the expectation that it processes more transaction and need to forward them to other nodes so that they can verify its shares

Quote from: kano on July 26, 2013, 12:39:44 AM

Interestingly related to that is that python sucks badly.
On my Quad core Q9300 2.5GH/s with 8GB of RAM, that is running p2pool, it sometimes hits 9x% CPU ... ouch ... but will never go beyond that since it is single threaded ... so a low power CPU will indeed suck badly in p2pool CPU performance during e.g. block changes

python doesn't suck badly, it just isn't designed for HPC. Bad CPU performance isn't necessarily a show stopper: as long as p2pool finishes to process data before it's needed or not delay the process waiting too much (almost everything happens asynchronously in p2pool) it's fine. Recent changes have helped in this regard: p2pool can prepare work before it's needed with the new protocol. So it could be at 100% CPU for a whole second preparing work (that's assuming a slow CPU with multiple miners using a different payout address) and only delay the workbase communication to miners by ~3%.

That said I actually don't like the language itself but that's a matter of taste.