Re: [1400GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
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.
... 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.
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 
Probably but I'm lazy...
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 ...{
"blocks" : 248451,
"currentblocksize" : 77889,
"currentblocktx" : 133,
"difficulty" : 31256960.72776893,
"errors" : "",
"generate" : false,
"genproclimit" : -1,
"hashespersec" : 0,
"pooledtx" : 1759,
"testnet" : false
}
#
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.
... 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.
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
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
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.