Topic: A Complete Guide to P2Pool - Merged Mining (BTC/NMC/DVC/IXC/I0C) plus LTC, Linux - page 5. (Read 198782 times)

Is bitcoind running?

I have got that:

2014-04-06 11:28:09.966482 > Failure: twisted.internet.error.ConnectionRefusedError: Connection was refused by other side: 111: Connection refused.
2014-04-06 11:28:10.048118 > Error getting work from bitcoind:
2014-04-06 11:28:10.048660 > Traceback (most recent call last):
2014-04-06 11:28:10.048970 > Failure: twisted.internet.error.ConnectionRefusedError: Connection was refused by other side: 111: Connection refused.
2014-04-06 11:28:12.968222 > Error while calling getinfo:
2014-04-06 11:28:12.968656 > Traceback (most recent call last):
2014-04-06 11:28:12.968881 > Failure: twisted.internet.error.ConnectionRefusedError: Connection was refused by other side: 111: Connection refused.
2014-04-06 11:28:13.050416 > Error getting work from bitcoind:
2014-04-06 11:28:13.050833 > Traceback (most recent call last):
2014-04-06 11:28:13.051019 > Failure: twisted.internet.error.ConnectionRefusedError: Connection was refused by other side: 111: Connection refused.
sxuea2014-04-06 11:28:15.970630 > Error while calling getinfo:
2014-04-06 11:28:15.971036 > Traceback (most recent call last):
2014-04-06 11:28:15.971226 > Failure: twisted.internet.error.ConnectionRefusedError: Connection was refused by other side: 111: Connection refused.          2014-04-06 11:28:16.052379 > Error getting work from bitcoind:
2014-04-06 11:28:16.052772 > Traceback (most recent call last):
2014-04-06 11:28:16.052933 > Failure: twisted.internet.error.ConnectionRefusedError: Connection was refused by other side: 111: Connection refused.

What should i do?

python run_p2pool.py -a xxxx --give-author 0.5 xxxx xxxx

UPDATE:

Gave up on v0.9.0 - went back to v0.8.6 & everything is funky again 

I have not upgraded to 0.9, and I see increased GBT latency (similar in magnitude) as well. My guess would be more transactions in the mempool since the relay rules were changed. My efficiency is still good though. I think if everyone has the same increase it doesn't hurt you.

looks like a classic case of too many transactions in memory... but i'm not seeing some unusual amount on blockchain.info...

I used to hover around 0.2 with the older client, but since updating it would gradually rise over a few hours until I restarted it, then it would gradually rise again:



I done some digging around on da webz, looking at ways to reduce latency on SSD's (I have my Xubuntu 12.04 64bit OS on one SSD & my wallet data for 6 coins on a separate, faster SSD) & came across this excellent article:

https://sites.google.com/site/easylinuxtipsproject/ssd#TOC-After-the-installation:-noatime

I added the noatime to both SSD's, enabled trim using cron (RIG is always on - of course ), changed scheduler to deadline, updated grub then rebooted as instructed. The results were a slight improvement after about 20 hours of running, but still gradually rising with high peaks. I then noticed the note at the bottom of the article "Ubuntu 12.04: change the scheduler to deadline" which states: "Note: when you have only an SSD in your computer and no platter disk as well, then you may experience a slight performance benefit by choosing noop for scheduler, instead of deadline."  So, I then changed the scheduler to noop, updated grub & rebooted again - here are the results:



Not brilliant, but much better. This is a work in progress & I'm still tweaking, but hopefully this will help you guys out if you're having similar issues as me with the new bitcoin client. If I get it any better I'll post here with what I done  

If it helps anyone - have a spliff  

GetBlockTemplate latency is much higher with bitcoin v0.9 final.  It is higher than it was on the last few RCs too.  I had been running the RCs since January and with the 0.9.0 final, latency spiked.

Me too, I thought it was the fact that the machine was a slower Core 2 duo that I was only using for myself but since I installed V9 it's lagging. Didn't even bother to diagnose just pointed my miners to someplace else for now. Won't have time to take a look for a few days.

-Dave

They're old (as is the p2pool software) but still current. I'm using the new bitcoin client with my setup no problem, a list of ports are a bit further back in the thread  

EDIT: strike that - having all sorts of latency issues since upgrading to Bitcoin v9 & getting regular cpu spikes up to 60% - anyone else having problems? Done the right thing, uninstalled old, installed new from ppa, etc.........tried reinstalling........strange

Are the instructions here current or do they need to be updated for the latest Bitcoin version?

I am running 4 coind servers on one virtual machine running Ubuntu Server 12.04 LTS. Each coin I add, adds about 80-100mb or RAM usage. My bandwidth is 50 down, 25 up, so I don't see any issues with bandwidth at all. P2pool does measure network usage, but it is very low in the kbps. I am allocating 2GB of RAM to the VM, 40GB disk, and 2 of my CPU cores dedicated to the VM. I am using VMWare Workstation v5. They have been running solid for a week now with no hiccups, errors, or issues. Performing 25% better than my mpos pool. which is weird.

Much will depend on various factors.  For example, is this a p2pool for only bitcoin or many other alts too?  How many people do you hope to attract to mine on it?  How many incoming/outgoing connections for each *coind server?  The more instances of p2pool and *coind you are running the more memory, bandwidth, and CPUs (or cores) you'll need.  

I read this guide. I have question

minimum system requirement computer or server to install this P2pool?
minimum bandwidth internet connection to run public p2pool?

which server rent to run public p2pool? caused I have plan to make public p2pool.

most blocks you get 0

the blocks p2pool solves you get quite a bit

I can't seem to find in the json output, logs, or in the code where I can find out what block number my users are working on. Basically I want to know who is working on what block during what time frame.

In the web/log aside from hashrates, miners, shares, there is BLOCK_VALUE and Attempts_to_share.

In local stats, mostly same information.

In recent_blocks, I have a list of all the block numbers, share hash, and block hash.

In current_payouts I have the block hash and payout addresses and timestamps.

The missing piece of the puzzle here is "what block is my node currently working on?".

Is there any way to find out what block is being worked on and during which time? Don't you guys find payments a bit spontaneous? Some blocks we work but don't get paid. Other blocks we get paid quite a bit? I want to be able to connect all the data points.

You can specify an address for the main pool, but when you use a merged parameter, you can't specify the address that any coins mined on the merged pool go to - they go to an address in the *coind wallet.  So if you are merge mining namecoin with bitcoin, you can specify the address that any bitcoins go to, but not where the namecoins do.

:-)

I thought that you could specify in the command line for running p2pool the wallet that payments will go to:
  -a ADDRESS, --address ADDRESS
                        generate payouts to this address (default:                         requested from bitcoind>)
source:
https://en.bitcoin.it/wiki/P2Pool

I plan on using a windows wallet on another computer that I would like payments to go to. My goal would be to seperate the pool and the wallet.

When you launch p2pool, to see if this is working, one of the first checks it will do is determine the default payment address. The address specified should show up there. I haven't tried it myself, but I'm assuming this is how it will work.

i agree with you , except in the case of namecoins (err, well, if you have a "decent" speed, anyway... which I'd say would be about a 1 in 200 chance per day of finding a namecoin,  one block of namecoins is worth around $200 at current prices)

They go to the coind wallet unfortunately. There's no easy way to adjust that on the fly since the wallets themselves don't support it.

One could perhaps hack the wallet's API call for getblocktemplate to take an extra "payment address" parameter, and block that into the template returned. This way different miners could get different merged work.

Can you specify the address that any coins should be sent to or are they just sent to an address generated in your *coind?