I'm using Windows x64. I installed Python 2.7 x64, Twisted x64, unzipped Zope.Interface x64, but when I try to see the graphs I get the following "Install python-rrdtool!". Searching Google for python-rrdtool didn't help to find a compiled version. Any help would be appreciated.
Here's one binary I found, though I haven't tested it, and is really old: http://oss.oetiker.ch/rrdtool/pub/contrib/rrdtool-1.2.12-python-2.4-win32.zip You might have to install all 32-bit Python and libraries to be able to use it... Because of how annoying rrdtool-python is, I'm planning to switch to PyRRD soon, which just calls rrdtool.exe. Waiting for that might be easier.. I don't really know much about Windows services.. but it looks like you could use the other approach mentioned on that thread, also seen here: http://support.microsoft.com/kb/137890 P2Pool doesn't require any special stop procedure and won't be hurt if you kill it. Isn't making P2Pool big (let's say 50% of bitcoin total hash rate) a bad scenario? this will affect bigger variance and wait time for every miner, especially those small? With 50% of total network speed and 10 000 miners (we have 10 000 ghashes/s so its even more than 20k GPUs mining) we will have 1 block every 20 minutes - so every 120 p2pool shares if i get them right. That will give miner a chance (assuming every miner is at same speed) of finding block equal to (20mins/10sec)/10 000 = 1.2% every 2 mined blocks in network.. to hit any block he will need to wait 166.66 blocks which is more than one day (1day = 144 blocks) for average chance of payout equal to his work.
This is correct, though if what happens we can simply split P2Pool into multiple pools. A single pool has no need for more than 10% of the total hashrate, so if we reach that point, we'll begin creating new, separate P2Pools.
|
|
|
Curious about the coinbase in p2pool blocks Most I've seen have been 0000 (i.e. almost nothing) They are easy to spot though coz they pay in the coinbase txn (and don't say Eligius in the coinbase itself ) But this one: 165558 (00000000000007d5f9d3a5bd7d9d184f31df65b6c185433504452bcb0d9c8bcb) Was: coinbase (44) : fabe6d6d2184daf786691909635b7684622b478c3489abe4888195feca7274e3ae5953570100000 000000000 (..mm!....i..c[v.b+G.4........rt..YSW........) Which looks like MM - but there doesn't appear to be an NMC block at exactly 02:55:57 6-Feb-2012 UTC (0x4f2f413d) So ... out of curiosity ... what is that in the coinbase? It can't be MM coz there would be nowhere to actually pay it ... would there? (and how would it get in there anyway) That was a merged mining header and became Namecoin block http://explorer.dot-bit.org/b/2184daf786691909635b7684622b478c3489abe4888195feca7274e3ae595357 (notice how the block's hash in the url appears 4 bytes into the MM header.) The Bitcoin block header's timestamp doesn't have to match Namecoin's. So I'm running two p2pool nodes. One is on the same subnet as my miner and the other is running on my residential connection as a backup pool. They are both setup with the same versions of everything and both on the lastest git head and both are merged mining with namecoind (I like the new simpler flags btw) My main instance output this 2012-02-06 14:28:36.710654 New work for worker! Difficulty: 1.235214 Share difficulty: 357.877941 Total block value: 50.011230 BTC including 43 transactions
and at almost the same time, my backup output this 2012-02-06 14:28:35.523973 New work for worker! Difficulty: 0.999985 Share difficulty: 349.760460 Total block value: 50.010530 BTC including 29 transactions 2012-02-06 14:28:37.032823 New work for worker! Difficulty: 0.999985 Share difficulty: 357.877941 Total block value: 50.010530 BTC including 29 transactions
Any ideas why my backup pool has different numbers for everything? And why did the backup pool output 2 different lines with "New work?" The second line has the same share difficulty as my main instance, but the difficulty, block value and number of transactions aren't the same. Both nodes to show the same number of shares in the chain and the same pool hash rate and stale rate. Both bitcoind's relay are connected to eachother, so I thought the number of transactions should be very close to the same. 43 and 29 seems like a big difference. The share difficulties match, which is expected. The reason that there's two is that there was a new P2Pool share produced in between them. The local difficulty is different because it automatically changes so that P2Pool isn't swamped with shares from your miners. Total block value and transactions depends on which transactions your bitcoind has heard of.
|
|
|
What we really need is a frontend/installer for P2Pool, perhaps we need to get a bounty going.
Is that really necessary? On Windows, you can now just unzip the executable file and double-click it, and on Linux it's just ./run_p2pool.py (clicking it in a GUI might work too). However, Uukgoblin has been working on a little GUI configurator - see here: https://github.com/goblin/p2gui/blob/master/screenshot.png
|
|
|
What does that have to do it?
One block found is one block found. If the pool size is 1, 10 or 1000.
The statistics (and maybe more) is simply wrong.
The "Average time between blocks" datum is misnamed. It should be "Expected time between future blocks" or better yet "Expected time until next block". It does not average historical data, but estimates the future based on the current Bitcoin difficulty and P2Pool hash rate.
|
|
|
Should everyone be using the --submit-stale option in cgminer? The reason being, even if a share is stale, if it happens to be a winning share we definitely want it to be submitted to p2pool anyways so that it counts as a block find.
Yes. There is a pull request for CGminer that lets P2Pool enable this by default https://github.com/ckolivas/cgminer/pull/95 , and P2Pool has support for it https://github.com/forrestv/p2pool/commit/d39081784f65b , but in the meantime, everyone should use it.
|
|
|
Yea looks like my client is bugged. Pool hashrate went to zero, local hashrate is good. Strange.
Have you upgraded to the latest version? There was a problem that caused this that was fixed two weeks ago.
|
|
|
I am running the latest stable version of BTCMiner ( https://bitcointalk.org/index.php?topic=40047.0) pointed at P2Pool. After a few hours of running (I haven't been around when it fails) it throws an invalid length string exception and shuts down. After this happens whenever I try to restart the miner it seems to be ineffective and constantly reports that it detects a new block via long polling. To resolve it I have to kill and restart bitcoind, P2Pool, and BTCMiner. Is there anyone experiencing a similar error in their miners and odd P2Pool behavior? BTCMiner's exact exception would be helpful in determining the problem - can you pastebin it somewhere? I can't test it as I have no FPGA miner..
|
|
|
Does that mean I am better off just running bitcoind rather than Bitcoin-Qt?
Yes.
|
|
|
Is it possible to specify more than one merged URL and pass?
Not yet - It will be soon.
|
|
|
The first part of the output from p2pool execution is exactly similar to your output. The second part looks like this: http://pastebin.com/NVst55VWIt seems to be running fine. After a while cgminer is unable to access run_p2pool. I checked bitcoind by accessing it at port 8332. Bitcoind is working fine. That looks normal... Though it might be still downloading shares. Try running cgminer in debug mode (-D option) and checking if you see any errors saying "p2pool is downloading shares". Have you let P2Pool run for a while?
|
|
|
After I go to http://127.0.0.1:9332/graphs/ it says I need to install python-rrdtool but I can only find source distributions and I'm really too lazy to compile it myself (it never runs out of the box and just ends up costing a lot of time). Are there binary distributions of this project? Are you using Windows?
|
|
|
Its around six computers, with 12 miners (gpus) running. What would be the difference between running six local p2pool nodes and running one central p2pool "server"? As it takes quite long to do a proof-of-work-share, will my efficiency differ? Those miners run 24/7, so it should even out at the same efficiency eventually? I would love to have only one central p2pool node running, but my friend prefers more redundancy with independent computers..
I would just run one... You get combined worker statistics and have less work to do setting it up. EDIT: I can confirm that Qoheleth's summary is completely correct.
|
|
|
i had 0 rejects with the old 0.8.1
How many rejects do you have now?
|
|
|
the normal p2pool client was solving for the right difficulty ~200 the git one goes a lot faster and cgminer reports a lot of rejects p2pool reports just a few shares like before - but more of them are dead so i want to set the difficulty back to its proper value...
It going a lot faster is useful because you can see how well your miner is doing. If you a lot of rejects (>5%) on your miner, something is definitely wrong with it.
|
|
|
i am getting dead shares with the git version. which part of the code sets the difficulty lower for debugging?
The difficulty is always low whether you use --debug or not. The relevant code is on line 474 in main.py - "target = 2**256//2**32 - 1". If you want to change the minimum difficulty back to 8, you can replace it with "target = 2**256//2**32//8 - 1", though I'm not sure why you'd want to.
|
|
|
found only "users" "fee" and "rate"
Upgrade p2pool
|
|
|
Everyone needs to upgrade to either git HEAD or the py2exe snapshot in the first post, http://u.forre.st/u/rtooosfo/p2pool_win32_1685a89.zip . There has been an ongoing problem with the sharechain forking, which I believe I solved in git about a week ago. However, many miners aren't running the newer version, and it appears that they have forked off due to evidence from picchio and the sudden decrease in hashrate.
|
|
|
I just updated to git head to try and use the cool graphs that you added, and now p2pool does not work.
Older version of rrdtool apparently didn't have the --no-overwrite option. It wasn't necessary, so I removed it from the current git version of P2Pool... so git pull and try again?
|
|
|
|